The Career OnDemand team works out of three countries. Germany, Hungary and USA. The development team does 4 week sprints. The user experience team does weekly updates to the entire team on their progress. Their work almost feels like a weekly sprint to me. Both the teams record the presentation and conversation using Adobe Connect and share it with those who could not make it. Since the teams works out of Germany, Hungary and California, the recordings are very important assets to share, review and discuss. All conversations, both intelligent and not so intelligent are recorded and preserved for everyone to listen to. It is sometimes shared with people outside the team.
Prototyping
Use experience teams create html prototypes in a tool called ForeUI to convey the detailed design and flow of the various product stories. The product owners who work with co-innovation customers build prototypes using a tool called Axure so that they can convey concepts as tangible experiences. They update the prototypes at least twice a month and share the concepts and flow of the story via video with other product owners, user experience designers and development architects.
Storytelling
Concepts are directly built into html prototypes and conveyed in person or via video. Very little is captured in PowerPoint. No market requirements document was written. The concepts are conveyed via story telling, in person, via web conferencing or via video. For example, the employee stories was repeated more than 175 times to customers over 12 months to refine the story and prototype.
Radical Transparency within the team and for customers
Almost every week, team members and customers get to see the current concept and latest screen designs. Every month everyone in the team gets to see an update of the functioning product. There are some use cases and spec documents. But mostly teams rely on what they see. Not what they read. There is one exception. There is a wiki page where decisions are captured.
The design specification is not a contract between product owners and developers
The good thing is that there is no design specification that is treated like a contract. A poor idea, even if it is written down, is not implemented if product owners are not convinced. Almost every feature can be tracked back to a customer conversation. No feature gets developed before a customer has a chance to review the screens and flow of the story. This is very different from how SAP traditionally develops software. There are some problems here and there. It sure requires a high level of trust and personal accountability. Sometimes it feels like no one is in control. But, so far so good.
Prototyping
Use experience teams create html prototypes in a tool called ForeUI to convey the detailed design and flow of the various product stories. The product owners who work with co-innovation customers build prototypes using a tool called Axure so that they can convey concepts as tangible experiences. They update the prototypes at least twice a month and share the concepts and flow of the story via video with other product owners, user experience designers and development architects.
Storytelling
Concepts are directly built into html prototypes and conveyed in person or via video. Very little is captured in PowerPoint. No market requirements document was written. The concepts are conveyed via story telling, in person, via web conferencing or via video. For example, the employee stories was repeated more than 175 times to customers over 12 months to refine the story and prototype.
Radical Transparency within the team and for customers
Almost every week, team members and customers get to see the current concept and latest screen designs. Every month everyone in the team gets to see an update of the functioning product. There are some use cases and spec documents. But mostly teams rely on what they see. Not what they read. There is one exception. There is a wiki page where decisions are captured.
The design specification is not a contract between product owners and developers
The good thing is that there is no design specification that is treated like a contract. A poor idea, even if it is written down, is not implemented if product owners are not convinced. Almost every feature can be tracked back to a customer conversation. No feature gets developed before a customer has a chance to review the screens and flow of the story. This is very different from how SAP traditionally develops software. There are some problems here and there. It sure requires a high level of trust and personal accountability. Sometimes it feels like no one is in control. But, so far so good.
No comments:
Post a Comment