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 DoneLet 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 doneYou 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 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: