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:

1. 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.
2. 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.
3. 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.
4. 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.

7 Ways to Fail to Deliver Potentially Shippable Code at end of Sprint

Before we address the question of how to *not* deliver “potentially shippable code” at the end of the sprint, it would be interesting to define what is “potentially shippable code“. I don’t know where I read this definition – “potentially shippable code” is only a sprint away from release. Whether or not the code is actually shipped or not would of course depend on does it make *business sense* to ship the code right now or after doing another sprint or two. As you are developing based on prioritized set of features and delivering “potentially shippable code”, you are never far from release. However, you are not reading this blog to find out how to produce “potentially shippable code” at the end of each sprint. Rather, we will discuss how you can through lot of “painful, slow and planned” effort not deliver “potentially shippable code“.

1. Step 1: Do not define Done – Let everyone define what “done” means without communicating on it
   Customer expects to see a tip top UI that functions perfect
   Team is busy building backend and code behind files with lousy UI
   Management thinks the team is building the code that can be supported
2. Step 2: Departmentalize and Compartmentalize work to be done – You have to make sure that work is divided in various departments who can blame each other at the end for a job not done. Here are some steps you can take to ensure that:
   Take Quality out and place them in another department with procedural barriers to collaboration among the two teams
   Do the exact thing with UI designers
   If you can do it, divide the work along horizontal layers like database design, business logic design, interface coding etc – the more you can, the better it is
   Do not forget to add ceremony and processes on how different departments should communicate with each other
   You don’t need to include technical writers, UI review surveyors and other support functions in each sprint – have them learn about your months long project in 10 days and churn up some documentation and reviews
   Doing it last minute and hurriedly without a review is the most important thing here
3. Step 3: Insist on elaborate upfront design documents and architecture designs – Ensure that team worries more about “how they will achieve goals” rather than goals themselves. You can do that pretty easily. Think of the latest modeling techniques and use it to model. Other steps you can try:
   Define all the tasks and their dependencies upfront
   Think about the design rather than what the design should help achieve
   It will help if you can spend a lot of time defining the architecture
   Make developers just Architecture to Code converting units
4. Step 4: Write crappiest possible code that no one would dare to touch in future – This one take special art, after all by the time anyone will touch the code you wrote, you would be in your third job already. Still, you must plan out in great detail processes which help you write the crappiest code possible:
   To ship potentially shippable code, the team not only needs to work on prioritized features, but also maintain a good velocity – so do everything to ruin it
   Write crappiest possible code [no comments, no standards, no reviews]
   Drive developers to guard their code like treasure
   Make developers horrified of others code [success: this was not my code, why should I fix these bugs]
   Make sure your code breaks the build when you check that in and try doing that the last thing in the day
   Make sure your code has low cohesion and high coupling so that any change in any part of code goes and affects totally unrelated part of the code
5. Step 5: Code first and test later and if possible leave testing for another sprint – Who wants to do any testing, thats the lowest possible denomination of tasks in a project. Testing is not as sexy as design, analysis, coding and processes. Also, what value does testing provide to the organization or project. Hence, you should make sure your team treats testing as just a necessary evil that has to be done because processes say so. You should try the following to keep this evil as away and as low as possible:
   Testing should be done at the end of the sprint or if possible in the next sprint
   Make sure you don’t write any test cases so that testers have to go through the code and functionality manually each time they do the testing
   Ask testers to test even the smallest change you make to any functionality
   Make responsibility of testing only the QC departments – you are here only to code
6. Step 6: Change and chop team/ developers – Who wants stability? Management wants flexibility and pre-sales team wants to show developers for new projects. Hence, take as many developers as possible and get new work or shouting customers out of the way. The silent and steady projects mean that they are just too easy to manage and can do with resource snatching. Hence, its important that your developers are constantly changed and chopped between projects between sprints if you want to fail. Additionally, make sure testers, designers etc are changed as well. If you can manage to change SCRUM Masters and Product Owners between the sprint as well, nothing like it
7. Step 7: Make the same mistakes over and over again – This is important. It’s going to be no use if you make the carefully planned mistakes outlined above and then go about fixing them. Make sure you only discuss what’s going to be served in next sprint retrospective and blame every one else but yourself in Sprint Retrospectives. Do not focus on above issues.

If after trying all of the above, you can still produce “potentially shippable code” at the end of each sprint, then please call me. We will create a new software development methodology 🙂