Agile antipattern: Moving work from one iteration to the next
All agile teams start at something less than the completely proficient level. Nearly all of those teams do not successfully complete their very first iteration. As a result, they move the remaining work to the next iteration and move on with the process. At this critical point some teams make a mistake which is nearly always fatal (this is a timely topic today since I just completed a session at the Mile Hi PMI Symposium on Failing with Agile).
The death spiral starts with a statement along the lines of “we did pretty well for our first iteration.” Another favorite is “if we get that close to finishing every iteration we will be way better than we used to be!” And finally, the grand-daddy of them all is “we didn’t finish, but we sure learned a lot so that makes it ok!” Please be very clear that none of these statements is acceptable. The team DID NOT complete the iteration, making the iteration a failure, not a success of any sort regardless of how new the team is to the agile process. I have a very strongly held belief which says bad habits cannot be tolerated or they will become the new normal. If we tolerate an “almost made it” iteration and give it any credibility as a success we are going to be breeding a bad habit. Unfortunately, bad habits breed faster than rabbits. Before you know it, you will have 10 more bad habits that need to be broken.
What are the potential issues with accepting not quite finished iterations? For starters, if a team cannot meet commitments they make then executives need to take a hard look at that particular team. We can’t hold a team very accountable if we give them the scope and date and say hit it. We can hold them very accountable when we ask what can you accomplish in this iteration and they tell us. If a team continuously misses on their iterations the team is not realiable, and with the current economy members of an unreliable team are definitely at risk. Second, when a team continually misses its commitment it hurts morale on the team. Being labeled a failure every iteration becomes mentally draining which is why many teams take the “we almost made it so that’s a success” approach. Third, as the team continues to miss they start to take shortcuts which lead to long term sustainability issues (hacking code in, cut/paste coding, not adhering to standards, etc.). Obviously none of these three things help the team be successful.
On the other hand, when a team is successfully meeting their commitments they are likely to maintain a steady velocity. Having a steady velocity is worth a lot. A team that can be counted on to deliver a specific amount of functionality each iteration will be very accurate on predictions for potential release dates. Moreover they will be accurate much earlier in the project. Second, morale will improve substantially. Knowing that every iteration has been a success helps people fell good about their work and the job they do.
So how do we install a sense of urgency about completing iterations successfully? We start by making it clear the first time an iteration fails. Failure is not success no matter how you spin it. We follow this up by helping the team understand the concept of using “yesterday’s weather” for making their next commitment. Using yesterday’s weather means the commitment for the next iteration needs to be equal to or less than the amount actually completed in the prior iteration. This should mean the team will ratchet down their commitment each iteration until they can be successful on a regular basis.
If we handle things as suggested we will find the team getting the benefits of success in short order. I can see your hand in the air to ask a question, so let me answer it. Yes, this does mean the team may end up performing at a level that won’t complete the project in time. Would hiding that fact for a longer period of time be better? Remember my blog from a couple of days about about agile exposing the elephant in the room. In this case the elephant is a lack of resources or knowledge or both. Agile will expose this shortcoming very early in the process. This could be a problem because as an attendee in my workshop today pointed out, even though many stakeholders SAY they want to know about problems early, they really don’t want to hear about problems at all. Agile requires open, honest, reality-based communication. If that isn’t occurring that would be another agile antipattern (hmm, perhaps another blog entry for the future). We need to expose the problem early so we have maximum time to mitigate the risk.
In the long run helping the team be successful by limiting their commitment to reality and making them aware of bad habits will make the team better. In the short run it is likely to be frustrating. In those cases send them to this blog entry 🙂
Now, let me give you a a bit of practical advice – in the very first iteration don’t be too hard on the team. MOST agile teams will fail the first iteration and many will fail the second as well. Be firm in recognizing the failure, but do everything possible to point out the need for future improvement in a non-threatening fashion. From the 3rd iteration on things need to be working much better and the message needs to get harsher. Again, continually failing to deliver on iteration commitments will put a team at risk faster than almost anything else they could be doing. Don’t allow that too happen!
Until next time work on breaking bad habits before they become ingrained. Doing so will help you in Making Agile a Reality™.