Stop the production line! There is no need to cook slices of cake or build skate boards. The answer is here.
I guess most of the readers have seen the various examples when trying to explain what iterative and incremental development means. Guess what: They are all wrong.
Slicing the cake in vertical slices is wrong. Whi on earth would cook only a fraction of the cake and still go through all the steps?
If your customer want to commute from A to B and you start out building a skate board when they really need a 4-seated car; then you’re doing it wrong.
In both cases you have missed the point of user feedback to get to the real user need. You have gone straight from a one liner and directly into solution mode. Stop doing that.
Imagine the following user stories:
- “As a cake customer I would like a layered cake so that I entertain my guests at my party”
- “As a commuter I would like means of transportation from A to B”
If we follow the cake slicing and skate board metaphores, we will go straight into solution mode and build a slice of layered cake and a skate board to be presented to our users. Guess what: It doesn’t fit their need. The cake is too small and the skate board is too slow.
Start asking questions before accepting vague stories. Document these as acceptance criteria:
- “As a cake customer I would like a layered cake so that I can entertain my guests at my party. I like red berries, chocolate layers and vanilla cream.”
- “As a commuter I would like means of transportation from A to B. I commute 40 km to work each day and have to pick up the kids from school after work.”
Ah, ok.
Putting a few acceptance criteria on the stories narrows the scope down. How do we proceed from here?
- Start with the absolute minimum development of a potential solution
Make a small batch of cake to build a walking skeleton. Draw a wireframe or similiar of a transportation unit that will allow for the commute to happen with ease with room for the kids. In the first steps the aim is to figure out what kind of transportation unit could be used, next will be the actual unit.
In product development the outcome of each iteration needs to be integrated into the existing product. In software development this means that the produced code must be integrated with other pieces of software around. - Get feedback on the first iteration
Is this the taste that you like in the cake? Should we add/remove anything? Is this the kind of tranportation unit that would live up to your needs?
In product development the outcome of each iteration needs to be deployed to be able to get feedback through either a Sprint Review or Accept Test with stakeholders and users. - Deploy the solution when accepted or create new stories based on the feedback to the solution and iterate
New ideas will arise at any give time in the proces. Make sure to note them down and prioritize them before working on them.
Integration
| Who | Developers |
| Why | All developed products should be integrated often to reduce the risk of single pieces not working when assembled in a larger puzzle. |
| What | Compile, Validate, Review, Unit Test, System Test and Integration Test |
Deployment
| Who | Developers |
| Why | To deliver the developed products as fast as possible to start harvesting the benefits |
| What | Deploy to test servers, Deploy to product servers, Configuration management and Containerization |
Accept Test
| Who | Customers, Developers and Product Owner |
| Why | To confirm that the developed products fits the purpose of the customer |
| What | Customer test the product, Developers fixes issues and Product Owner records any new ideas |
New Ideas
| Who | Customers, Developers and Product Owner |
| Why | To capture any relevant ideas to the enhance the product |
| What | Through out the whole process everyone be creative and enable idea generation. All ideas could turn into new pieces of work. New ideas are added to the Portfolio Kanban Board and ignites the flow starting with the Idea activities. |