We just added the ability for people to share all the rich information on their pages — “save as .ript file”
Tag Archives: Ript
Nice Ript Post
Nice post from Frank Arrigo, the Microsoft evangelist responsible for all Technical Communities in Australia.
“Since I am always on the lookout for WPF apps, I had to download it and it is really really sweet…“
I’m very proud of our application and our team. Now we need to get Ript™ in the hands of more users.
Microsoft and Ript
Gerry spoke at the Microsoft Women’s Conference this week.
I joined her so that we could meet with some key players at Microsoft to talk about Ript™, our WPF application.
Attending were Henry Hahn, WPF Program Manager, Darren Mc Cormick, Worldwide UX Role Owner, and Katherine Westgate, a Marketing Officer from Microsoft’s NY office.
The conversation ranged over the whole history of our project: our Scrum/XP practices, how our team collaborates on user experience, how we created our product vision and our plan to monetize the product.
The three of them were entirely approachable, engaged and enthusiastic. They also came prepared. They’d all downloaded and worked with our application. Henry actually submitted feature suggestions from his team he knows are easy to implement given what we’ve already created.
Katherine helped pull the attendees together and lined up our hands on demo of Surface™. She was interested in figuring how our experiences with Ript™, agile software development and collaborative product ownership might help her enterprise clients. She also asked Gerry how Oxygen approaches advocacy for women, corporate good will and citizenship. Katherine is sharp and conscientious. I could tell Gerry hit it off with her.
Darren described the Developer Platform Evangelists (DPE) programs for joint marketing and developer assistance around products built in WPF and Silverlight. We discussed some of Microsoft’s goals for Silverlight distribution and what Oxygen’s next steps are to engage these resources. Darren is clearly passionate about user experience at the level of product, brand and within an organization. Yet another example of Microsoft going outside its organization to bring in new thinking.
Gerry’s main points were that women are the principle market for consumer technology, that usability testing with women provides valuable insight, how software should playful, purposeful, simple and accessible and how product development should not focus on early adopters but the people who will make up the vast majority of end users should the product be successful.
The conversation also ranged over tech issues. Henry is a fan of our application and left an open door for further communication. He said the .NET team is working on some of our core concerns:
- breaking up the .NET 3 installer into server and client modules making the package smaller
- improving the experience of their default install (it plays out like a windows update, hiding itself in the system tray – this is very confusing in an application install process)
- making it easier for ISV’s to run a silent install and wrap their own UI around the install
- improving cold start time
- providing more expressive API’s for automated UI testing
Don’t expect any of this soon unfortunately.
Clearly there are employees at Microsoft in leadership roles determined to engage with and support, not simply consume, innovative work originating outside the company. I had the same impression at the ALT.NET conference earlier this month.
This bodes well for both Microsoft’s future as well as for those of us looking to innovate in the marketplace using their tools and platforms.
Why Is Oxygen Building Software?
Early in our Ript™ project, we met with reps of a large, northwest software company.
We had asked them, “what does you’re company think of women?”
They showed up with a stack of e-mail and no answer. Realizing they hadn’t managed a coherent response, one of them said:
“we build software for people and we believe women are people.”
- (they) build for people
- women are people
- therefore (they) build for women
This is analogous to saying, “all cats have four legs, my dog has four legs. Therefore my dog is a cat.”
The statement is packed with generic assumptions. At it’s worst, such assumptions can cause harm. At the least, they speak to an insensitivity to the needs and desires of women consumers.
Oxygen’s research confirms women are men’s digital peers and dominant influencers of purchasing decisions.
Businesses in other industries have found their women customers provide original insights into their products. Responding to those insights has lead to better solutions for both women and men.
“… women consider a longer list of criteria when selecting consumer products and stores than men do. …If a brand takes the time to understand her list, they’re going to over-deliver to men and still reach women” — Lisa Johnson, author of Don’t Think Pink
So, a better answer would have been, “we build software for women and we believe that leads to better software for people.” Still a little glib but it would definitely result in better software for those women!
We aspire to create playful & purposeful tools that:
- address real needs in the lives of women
- go beyond user interface conventions
- support collaboration between friends and family
- are accessible on whatever platform best serves the user
Our CEO is a visionary with a love of audacious challenges. We share her belief that we can be of service to women and create an opportunity for our company if we improve the software they use.
We acknowledge the pride of place women hold as our customers and seek to innovate by listening to them.
That’s my answer to why Oxygen is building software.
Trust, the Product Owner, and the Team
We are currently working on a consumer software product named Ript. I feel extremely lucky to be a part of this project as does every member of my team.
If there is a single reason for this sentiment it is the deep collaboration between our product owner and the development team.
The Manifesto for Agile Software Development asks us to value:
Customer collaboration over contract negotiation
Contract negotiation within a single organization arises in conditions of low trust. One or both parties feel they need to explicitly document expectations to protect themselves.
A low trust environment is Hobbes state of nature as practiced by the software industry. Promises are prized more than outcomes. Authority and responsibility don’t reside in the same person. Incentives are not linked to outcomes. Blame brings more consequences than failure. Success is virtually impossible. Agile practices if they can be adopted at all are simply a mechanism for failing fast which has the virtue of saving the company money and sending talented people off to hopefully more rewarding jobs at other organizations.
Rising above this coding purgatory is an organization with some mutuality of sentiment and interest. A capable development team exists and business owners are both empowered and accountable. Here the organization can aspire to partnership.
But not all collaboration is equal.
In What’s Worth Fighting for Out There?
, Andy Hargreaves and Michael Fullan describe the concept of bounded collaboration:
Bounded collaboration rarely reaches deep down to the grounds, the principles or the ethics of practice. It can get stuck with the more comfortable business of advice giving, trick trading and material sharing of a more immediate, specific and technical nature. Such collaboration does not extend beyond particular units of work or subjects of study to the wider purpose and value of what is taught and how. It is collaboration, which focuses on the immediate, the short-term and the practical to the exclusion of longer term planning concern.
This concept is applicable to the software setting which, like learning, is fundamentally about knowledge creation and sharing.
Bounded collaboration exists in software when the developers do not invest themselves in the business outcome of a project. This can occur through no fault of their own if the plan is vague, not shared with them, or if their input is not invited or listened to. Some managers simply don’t consider it important that technical staff buy into the vision or features of the software they’re building.
In such situations, developers shut off part of their brains. (for those of us who love our craft, a more apt description is cauterize part of our brains)
“I’m not personally invested in the business plan or priorities but I will execute on them as you (product owner) define it. Since I have no authority or meaningful influence on the plan or priorities, as long as I produce reasonably error-free code I refuse to be judged by how the product fairs in the marketplace.”
Scrum allows for success on these terms by assigning responsibility for the business outcome to the product owner and technical execution to the team. If the product owner has a thoughtful strategy and deep insight into their customers a well-executed piece of software stands a chance.
But what price does an organization pay for bounded collaboration?
Innovation – A company that does not engage fully with its workers diminishes its ability to think deeply about a problem and to surprise itself with unexpected solutions. It therefore fails to be what Ikujiro Nonaka and Hirotaka Takeuchi describe as a Knowledge Creating Company that can sustain success through its own invention.
A television company building consumer software – that’s audacious!
Our product owner is our CEO, Gerry Laybourne. This initiative is her idea but she partnered with the development team to craft the concept and feature set for our first consumer product, Ript.
Gerry has allowed us to fall in love with the project by leading us while listening to us. She’s given us the gift of high expectations demanding that the product be original, useful, and fun. She’s treated us as peers despite the fact she holds much more authority than we do. She’s shared her excitement for the product while sharing credit for it. She’s championed her priorities while allowing us to question any and all aspects of the product. We’ve both had the pleasant experience of disagreeing and realizing the other was right.
Yes, the product owner is the single wringable neck – she’s championing an entirely new line of business at her company – but I’ve never seen a team fight so hard to get in the noose with her. That’s trust.
To quote Jeff Sutherland, “Great scrums require great product owners.”