Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negociation
Respond to change over following a plan.
Notice the word “over”, not “instead of”
At its core:
1) Plan and release small iterations.
2) At the end of each iteration cycle, there should be a full set of testing and verification of what was released. Ideally continuous integration and automated testing.
3) Every day progress is measure to see if small iteration goals are to be made.
4) Your product manager should be the coordinator / director / bottleneck. He must be constantly checking progress / resources / trends / grooming the backlog / re-prioritization / leading in the right direction
5) Plan / Do / Check / Act. Imagine a cannon arm, where you have to constantly adjust the angle until you hit the target.
6) Always organize a retrospective at the end of each cycle: it is important to evaluate the work done / take corrective action / adjust.
7) Project division:
Phase 1: Build the simplest system span of neccesary, barebone features first
Phase 2: Corner cases / security / flexibility / other important things on top of bare bone features
Phase 3: Refine UI / bells and whistles, secondary features, nice to haves, etc
8) Release objectives: Quality, Speed to Market, Features (number of), Brand, Reputation. Unfortunately, each one of those areas takes time and sometimes cancel each other out, so you have to balance out which ones you are to pursue first in the time given. Or if you want it all, plan a high amount of time accordingly. Or make a plan B for the ones you won’t meet.
9) Constantly prune and groom your backlog, with the following (changing) dimension in consideration at all times:
– Vision (the grandiose high level idea that will deliver you to the promised land)
– Themes (formalizing the direction towards the vision, you may have more than one theme / path to make it happen)
– Narratives (Describe your theme. high level summary of your product or service, and how it will “get you there”)
– Epics (The narrative, translated to high level features)
– Stories (Breaking down the high level features in small increment tasks and sub-features. Must be doable within one sprint, or broken down further if they don’t fit)
Type of sprints:
Push sprints: points to be burned are pre-planned and preset. They can be checked against a burn chart at the end of the sprint.
Pull sprits: kanban. The back log is maintained to have the highest items that need to be taken care of on top of the list. Developers pull the items from the top as they become available to work on them. Items sit on the following categories: Ready, In Progress, Ready for Verification, Done
Incremental vs Iterative approaches.
– Incremental: you add complete features to the product, one a a time. Riskier because you may get too close to release date with a few key features not even started.
– Iterative: you work mostly in the most important features, but make sure you also build the secondary stories, enough to reduce the risk of an entire section of your product becoming all of a sudden a must-have and you haven’t start it. Or spending a lot of time in a section where at the end won’t be as important as expected at the beginning, in which case, abandoning it won’t be such a loss
– Collective wisdom: at estimation time, the more input you have, the more accurate the estimate is (bell curve, mean indicates the best approximation to the right answer)
– Failure does not mean bad resource / employees, but inability to lead them in the right direction. As long as there is the trust where they are willing to succeed, it should be a matter of coaching them and leading them into that. At the end of the day, who really wants to fail?
– In software development, there will always be a high amount of uncertainty about how long the project will take. Which will be reduced as you work along. Have that into consideration, and plan accordingly
– You don’t have to finish a product through to validate if it will deliver you to your company vision and objectives. Try to validate your vision / themes / epics / features as fast as possible, way ahead of release date. Sometimes you don’t have to build a complete finish product to see nobody will use it. Get early feedback. Put out alphas and betas. Mock features and measure the click-through rates to them. Validate your vision before it is too costly to readjust it or abandon it.