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™.
Awesome! Great points! And I do understand the desire to declare victory on a sprint. After all, everyone Tried Real Hard. And it’s human nature to want to reward that effort. But the discipline of knowing what you can and cannot get done in a sprint, and only committing to a feasible amount of work, is essential to both productivity and trust. (Perhaps counter-intuitively, I find that over-committing in a sprint results in so much thrash and churn that we get *less* done than we would have if we under-committed. When a team is over-committed, increasing pressure does not increase throughput.)
I have been happily reading your blog for awhile, but was surprised to find that I have a beef with this post. Although maybe I just misunderstood which is totally possible.
To me, failing an iteration is not completing it. I know you recently posted about it and I agree that a team should never ever quit an iteration. Ever. The only reason to do that is to make yourselves look better than you are and that’s called ego, not agile.
I think in this case you are using the phrase “fail an iteration” to describe a team that plans to do 100 story points and then at the end of the iteration has only completed 80 story points. If so, I totally disagree with the qualification of failure and more than that, I think it’s a harmful mindset (regardless of the exact wording).
To call it a failure implies that they screwed up (even if they did everything right). No one likesto be a screw up, so this leads to shirking on other stuff. Important stuff that you can get away with not doing, like adequate testing and fixing TODOs in the code and refactoring ugly design. And people start padding their user stories and underestimating their iteration velocity and thens screwing around in the last couple days so it’s not obvious they did that, and yuck!
Instead, what’s really important and valuable is having a steady velocity (as you mentioned). However, we should not unnaturally force a steady velocity by insisting that one velocity is success and another is failure. If they continue to focus on quality and good story estimates and general good practices, a steady velocity will follow organically. Then it will become easier and easier to predict how many story points we can do in the next iteration, or the next 5 iterations, etc. A steady velocity (and all the benefits it provides) is a result of successfully implementing agile, not a requirement to begin using agile.
Amber, to me failing an iteration is not completing what the team committed to complete. The commitment is more than just the story points associated with the iteration. It includes getting each story to a state which matches the definition of “done” the team is using. It includes creating sufficient artifacts to match any rules the team has in place in that area (I personally like using a Rules of Engagement document the team agrees to at release planning for this sort of thing). It also includes working in a way that shows pride and professionalism. If these things aren’t being done, then it is yuck, not agile. I do make exceptions for teams that had exceptional circumstances, but they have to be unique, not common circumstances.
The point of my blog post was not to point out the failure, but rather to say don’t get in the habit of moving work to the next iteration as though it wasn’t a failure. I think we can both agree that a team moving work from one iteration to the next on a regular basis is an unhealthy situation. I don’t want teams to think they are “close enough” so it is ok. That’s really what irks me. I’d rather have the team admit there was an issue (whether they call it a failure or not, they did not meet the commitment they made at the start of the iteration), and go about fixing it than have them say it was almost good enough so don’t worry about it.
In your example, if the team had an expected velocity of 100 and only delivered 95 (whether their fault or not), I want them to commit to only 95 next iteration (yesterday’s weather) and get it completed, or even pull more from the backlog. I don’t think it is healthy for them to say “good enough” put these 5 points in the next iteration and then add 95 new ones and again miss by 5 points. It becomes habit forming and that is a bad habit or antipattern. Unfortunately, too often I see the 2nd way of solving the problem (5 from last iteration and 95 new) instead of the 1st way (5 from last iteration and 90 new for a total of 95).
I hope that makes more sense and gives you the context of what I was trying to write.
Oh, and I agree 100% with your final paragraph. Well put!
Thanks for the super fast response and I think we’re on the same page now!
I’m still a little bit nervous about making a team feel bad if they come under. After all they may do everything right and still have a flailing velocity for awhile. I would hate for them to get discouraged or resort to bad practices to make their agile adoption a “success”.
But now I understand the situation you’re trying to avoid. At the beginning of a project our estimate would change every single iteration (I used standard deviation but certainly last-time’s works too). However, once we got into our groove and got a steady velocity going, we would get to use the same value and hit it every time.
So you’re totally right to point out how we need to be adapting our planned velocity as needed.
[…] blog post about stopping an iteration and how it was a really bad idea. Another blog post was about moving work from one iteration to the next and again it mentioned how this is a bad idea. This post looks at the problem which is similar to […]
Very Nice points made…Thank You very much, Bob.