Potentially shippable code – continued
In the last post, we discussed how not to meet potentially shippable code. However, we never really addressed the question as to why is the potentially shippable code that important anyways. It is often argued that the relentless focus on getting to potentially shippable code, is what sets Agile apart from other incremental and iterative processes. This is partly correct. Partly, because there are certain values which Agile stands for and if those are not used for the development, you are not really doing Agile.
Potentially shippable code as discussed in the previous post is always just one sprint away from shipping. Why this is important is because:
- It keeps the focus on priorities for the customer. She knows that all she needs to do to get the product to the market is announce a pre-release sprint and she will get it. After the first few sprints are done, the incentive to organize the product backlog to develop the product in a manner where it could be released any time focuses product owner to provide value to the project by prioritizing the items based on importance, ROI and risk.
- The team can think of an iterative and incremental mode of development – with preference to get to overall product structure as soon as possible. In fact is the product backlog has been priorotized well enough, enough value would be got early in the development rather than later, and actually the value added in future sprints could be much less. This provides tremendous ROI for the product owner and again – focuses them on considering priorities on an incremental and iterative level as well.
- It focuses the team to install engineering practices which will help them get to really done. Some of XP practices like refactoring, unit testing and code sharing help the teams really perform extremely as well as at a sustained pace.
- Overall, it provides an opportunity to get feedback and adjustment.
One of the tests of whether teams are doing Scrum in Nokia, include reference to “do you provide potentially shippable code at the end of the sprint?”. I have found focus on potentially shippable code really good way to help provide focus for all concerned on product success.