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

Should managers worry about extended coffee breaks?

I firmly believe that most organizations would run better if managers managed a bit less. The problem is that most managers do such a horrendous job themselves and drive others to do horrendous job as well, that if they did not manage at all, things would be better themselves. And they should definitely try and keep themselves away from SCRUM teams or should I say “fully functional teams.” And this means doing these [and much more]:

• Not keeping a count of how many coffee breaks a person takes
• Not keeping a count of how much time ABC spends on phone
• Not raising an eyebrow seeing an employee sleeping on the desk

Its sometimes also called reactive management. In fact I dont call it reactive or proactive. Its just another style of management and pretty effective one IMO for you can focus only on results and the behavior which drove the results. In case you use Agile, you can ruthlessely focus on results every two weeks or so. This allows for self correction in teams. Self correction driven through self introspection and committment to try out new things for better results seems to be a better driver for well, better results. Is that not what the management wants in the first place?

Here is why focusing on behavior first is harmful. Lets take the example of server administration teams. Lets say the server administration team [they do a great job and thats probably why] sit idle most of the day and only mostly answer email or do jobs which are completed in 15 minutes flat. Once in a while they are busy like hell, taking back ups and what not, but mostly you find them reading hacking articles, blogging, networking and boasting. There is another team with 3 developers [who do more than some 6 member teams]. However, you find most of them in canteen, laughing, blogging and in passionate discussions. CTO just passes by and after three such sightings can not control and makes this sarcastic mark “So you guys have outsourced your work too?” Managers wandering by and making sarcastic remarks about outsourcing, or whatever half-assed other smart comments they may make, demonstrates management inability and lack of awareness. Frankly, the manager should hope to see those ’slackers’ always ’slacking’, because that implies there are no server administration problems happening, which has to be a good thing.

IMO you need to avoid looking at the slacking [for instance] even if it is in your face. If you are doing Agile, what you need to look at it is what was committed [and assuming this was reasonable commitment] and what was delivered. You can obviously ask question like “What made you miss the commitment?” Slacking can be one answer and Low Morale [because of a manager just walking past and seeing team engaged in tea 5 times a day and remarking sarcastically, have you outsourced your work] can be another too. The managers job is to unearth the behavior for poor performance and not “seemingly” poor behavior itself. However, day after day we see poor management results [sliding profits, non paying customers demanding bug fixes and holding teams hostage, poorly trained teams] due to management proclivity to focus on trivial and urgent but not on important but not so seemingly urgent. It makes you realize how ingrained “command and control” is in our mindset as managers. The notion of a self functioning team just does not exist. The underlying assumption is that they will surely do something wrong and when that something wrong does not happen [well obviously because they would not commit to a 45 man months of work in 5 months, which management wont have any qualms over committing to by the way], issues like longer tea breaks, too many training sessions, not pushing too hard, there is an easier way to do this work, bottom 10% need to go, appear.

CSM Course by Pete Deemer at Hyderabad

I recently attended the CSM course by Pete Deemer [Hyderabad - September 7 and 8].

I have been practising SCRUM for a year now. However, I wanted to be formally trained in SCRUM through an experienced practitioner and meet other people in a live audience. Needless to say, I enjoyed every bit of the 2 days spent at the course. Most of all I enjoyed interacting with cross spectrum of participants - from Noida to Pune to Bangalore to Hyderabad itself. The participants comprised of people in their 20s, 30s, 40s and might be 50s as well, although not really sure on the last one. There were about 5 female participants which is a ratio of 16-17% and seemed very bad. This is something the Agile Community could focus on, special promotion drive for female employees. Come to think of it, other than Mary Poppendick, there does not seem to be any female authority in Agile/ Lean world either [Mary is also more Lean than Agile]. Anyways, focusing on the actual course itself, the lunch on both the days was delicious. A delightful mix of Punjabi and Hyderabadi, the cuisine had variety and flavour galore. Overall very enjoyable 2 days.

A word about Pete - really impressed, very calm, very focused and punctual. He does great role play exercises and mixes theory with practicals very nicely. He encourages questions, counter views and never chides people for obvious anti-common sense thinking they come with to the course.

I have a simple test for a good thing. When it ends, you want more of it. When the course did end, I wanted it to last a bit more. So did other participants.

Penalities and Agile/ SCRUM - Part II

In the follow up articles to the original article on Penalities and Agile/ SCRUM, I discuss some clauses that can be added to contracts to make it reasonable for both the sides.

• The first thing you would want to do is commit to as less as possible - possibly even just a sprint or a release. Hence, if you do incur a penalty, it is not for much. So draft something like “This deadline would be applicable for only Release 1 and deadline for Release 2 would be provided after Release 1.”
• Approval of all artifacts [including wireframes/ UI and any sprint backlog but not any UML diagrams or architecture] must be done by these dates from the client. To facilitate rapid approval a limit would be kept on the number of revisions for each wireframe and UI. The clients like to add another clause here “If wireframe or UI is rejected, it should not be counted as revision.” This is reasonable as long as the rejections happens in first draft. Any change from xth revision [what so ever you keep] or so - record kept, might be billable at end of project as additional item but not at the end of sprint. Similarly, for any change in approval UI/ Wireframe/ Flow/ Requirement of already delivered/ developed functionality - record kept, might be billable at end of project but not at the end of sprint
• Offer for co-location: It might be useful to bring on this offer [a central Agile principle] to ask the client to depute someone to sit with the team 8 hours a day, 5 days a week and see if we are doing well enough. This is especially useful for large projects with quick deadline.
• You can try committing to the deadline as late as possible. This is useful but rarely practical. However, all contracts are negotiation points and you can bring it to at least Sprint 3 or 4 if not second last sprint. You will have better idea of where the project is going in this case.
• A cap on story points - we will deliver working software by December end as long as total story points for stories remain plus minus 5 percent of 400 story points.

In case anyone has any more ideas, please fire them. We are all ears.

Agile vs. Waterfall - Convincing Clients

Dave Barrett, Lawyers’ Professional Indemnity Company provided this delicious recipe on how to convince clients for Agile.

“We can set a deadline if you like. In that case, we’ll spend the first month of the project working up a scope document and bouncing it back and forth between our two companies making revisions and additions until we hate each other. After that we’ll treat the SOW as gospel and fight like hell against any changes. Any additions to the scope will push the deadline back weeks at a time. Since you’re almost certain to add to the scope, this means that you’re doomed to miss the deadline even before you start. You won’t actually see any results until a day or two before the(revised) deadline, at which point you’ll almost certainly be disappointed because certain features won’t work the way you envisioned, or won’t be included because you never told us about them or didn’t know that you’d need them. We’ll then work up a new SOW for phase two of the project and rinse and repeat.”

“On the other hand, we can have short meeting tomorrow, identify the couple of features that seem to be the most important right now. Then we’ll get the Team going on it and show you what it looks like in a couple of weeks.Then you can pick the most important things that need to be done next and we’ll work on them right away. It may or may not be possible to get the system finished by your deadline, but the Team will always be focused on what you’ve determined are the most important aspects of the software all the way through the project. Our experience is that you’ll have working software faster with this process, you’ll waste less time and money building features that you don’t need, the features that you do get will work just the way you want them to and you’ll still like us at the end of the project.”

What do you think the customer will choose?