Imagine a car with state of the art navigation system, aerodynamic body and fantastic ceramic brakes, doing 0-60 mph in 4 seconds - but lacks the capability of putting the car into reverse. Now, imagine a smartphone that has fantastic new features, slick design and innovative human-computer interaction via touch screen - but lacks the capability to copy and paste text.
My guess is that you wouldn’t buy a car that you can’t reverse but clearly when apple launched their iPhone without copy and paste capability, people bought it. The Apple team made well thought thru decisions to launch a product before all the details were fully implemented and i can smell Agile development behind the scenes.
The goals of Agile development is efficiency and velocity. Allowing a product to fail quickly if that is its ultimate destiny or to adapt and include customer requirements, new or previously known but at the same time get features and functionality quickly in the hands of customers. Either to solve business problems they might have and/or get more feedback to improve the software on implemented features.
In my mind the “release early, release often” is critical to a young products success. A software development philosophy that was popularized by Eric S. Raymond in his
The Cathedral and the Bazaar, where Raymond stated "Release early. Release often. And listen to your customers”. This model is of course ideal for companies providing Open Source software such as ForgeRock, where i work.
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
Each individual sprint should provide viable features solving real problems and capturing the feedback from customers. Evolving the product is what makes the product ultimately successful, and of course that is done by interacting with the customers. Having said all of the above, i do believe its important not to neglect the details.
Agile development should never be an excuse for a lazy product manager (or owner if you wish) not scribbling down the details and explaining the requirements part of a user story. The balance is to understand as a Product Manager and dev team, that not all details are necessary to be implemented in order for the software to work and to stick true to the Release early and release often philosophy.
Inga kommentarer:
Skicka en kommentar