Thoughts on adding "stabilization" to the end of your project plan

It's a pretty common practice to add time to the end of your project plan in between the end of the last development iteration and production deployment. There are a number of activities that may have to happen prior to going to production, including:
- Final QA signoff of cards from the final dev iteration
- Any remaining defect fixes as a result of that testing
- Final user acceptance testing
- Preparation of the system for production

This period is often generically referred to as "stabilization". The issue I have is that this term implies that the system is not going to be stable at that point in the project, and this may even become a self-fulfilling prophecy.

The ideal in an agile project is that there are no defects at all at the end of each iteration. While this is not an impossible goal, in reality teams will usually strive to ensure there are no defects that would fit in the category of "critical", "high" or "medium", and more than likely a few "low" defects will escape the iteration. They will catch up on these in subsequent iterations, but following the logic you will still have some at the end of the last iteration.

So instead of referring to that final stage as "stabilization", I would probably prefer something like "wrapup" or maybe even "polishing".

Agile is not a magic "change" vacuum

One statement about Agile that seems to haunt a number of projects is "Change is expected and welcome" during the project. This is true, but with conditions, and if expectations are not managed properly things can get out of control.

I've seen more than a few cases where customers think this means they can keep changing their mind with no impact to the project. When we explain that it is fine to change your mind, or ask for more changes, but something else has to go, they act as if we just performed some kind of bait-and-switch. The "problem" is especially prevalent because with short iterations we give the customer plenty of opportunities to review the finished features and make comments.

The essence of welcoming change has to do with making adjustments before the story card has been finished. If you are in an iteration and the developers are working on a story card, and in the process of discussing the requirements with the product owner (or bringing up an issue they have discovered) it is determined that things need to change, that is generally going to be ok as long as the spirit of the story does change dramatically and the estimate for the change is still in line with the original estimate. We want the finished product to be what the product owner really wants and needs.

But in terms of managing change once story cards are completed, it is important to explain the dynamics to your product owner/customer up front. The team will establish a velocity throughout the iterations, and for the purposes of planning, that velocity will guide what goes into the iterations. If you want to put something else into that iteration, then something else has to go. So if you are in the iteration showcase and the stakeholders make some comments about changing/adding something, then you need to decide number one whether it is worth it or not, but number two when it should be scheduled and what else is going to move as a result.

Retrospectives are great, but...

...they're not worth much if no action is taken afterwards. I haven't met many people who disagree that retrospectives provide a lot of value to the team. But without follow-up that value is often not realized, and if identified issues persist they can actually have a negative impact on the team.

In general, items that require follow-up need to be captured in a manner that will allow them to be followed up on. One method is to turn these items into new stories. I'm not always keen on this approach, since the items don't usually follow the spirit of the user story, which is to provide direct business value. Making the items technical stories often makes sense, as they can be factored into the iterations but don't meet the definition of providing business value.

A lot of the items that get brought up during retrospectives aren't related directly to development, which makes it hard to figure out where to put them. The issues list is a likely candidate. Another approach I've taken on some projects is to create a wall (like a story wall) which shows the retrospective action items and where they are in their lifecycle. Seeing a number of untouched items on the wall is a good indicator that the value is not being realized.

Another technique is to start future retrospectives with a recap of issues that came up in previous retrospectives, and where those issues stand. If the team sees that items are getting addressed, it could encourage them to participate in the retrospectives even more.

Lastly I just wanted to comment that the best situation is when you can get the team to decide on a resolution and take action right then at the retrospective. Not always possible (or advisable in some cases) but is a great example of realizing the value that retrospectives can bring.

Just in Time Tasking vs Upfront Tasking vs No Tasking

This topic seems to come up all the time and the answer seems to change based on your situation. For the uninitiated let me give you some background on what I'm talking about.

If you are following the rules of good user story writing, then your stories should be business focused and represent what needs to be delivered. What it doesn't cover is "how" the story is going to get implemented. To cover this we usually create task cards which describe the technical tasks required to complete the development of the story. Some examples might be "Create a new database table to store the customer info", "Modify the x screen to include the new fields", etc.

There are essentially three main variations to tasking:
- Just in Time Tasking - when a story is ready to be picked up and worked on, the dev pair that picks it up sits down with the business analyst to review it, and then they brainstorm the list of technical tasks that will be required to finish it. Usually they will write each task down on index cards, but I have also seen cases where they are listed in the online tool which the team uses to manage the stories and iterations.
- Upfront Tasking - at some point in the very beginning of the iteration the entire team gets together and essentially does what the individual pair did above. This often takes place at the end of the planning meeting, and the team goes through all of the story cards for the iteration.
- No Tasking - the developers don't write down tasks at all. They probably will do some upfront thinking on the design, but in some cases they dive right in.

Let me start by saying that I'm no fan of No Tasking. This may work in situations where the story is very simple and the duration is very short, but in most real life situations this is asking for trouble.

The main benefits of doing the tasking session is to do the upfront design, and have some means of documenting it so others can understand the thought process behind it. We encourage frequent pair switching on my teams and the cards, while not useful by themselves for understanding the design, serve as a good outline to explain what's going on to a new person. The task cards can also be used by the dev pair and others to judge how complete the story is - as tasks are completed the task cards are marked completed.

Upfront tasking is often favorable because it enables the entire team to participate and become knowledgeable in the high level design. If there are going to be issues the team will know at that point and there should be enough time in the iteration to either resolve those issues, or if they are insurmountable then other stories can be swapped in instead. The downside in most cases is that it can be a very time consuming exercise. If your team is large there will probably be a lot of stories to discuss, and some developers may tune out after sitting in the meeting for a long time, thus negating the participation and knowledge sharing aspect. There's also the possibility that the developers won't fully remember the details when it come time to work on the story, even if they have the tasks written out.

Just in Time tasking is often a response to the issues mentioned above. After sitting through a couple of very long up front tasking sessions, the developers rebel and demand to switch to Just in Time. The developers are happy that they don't have to sit in a long meeting, and the managers are happy because the work gets started. The downside is of course the opposite of the upsides of upfront - only the pair that picks up the card is involved in the design decisions, when new members join the pair they have to be brought up to speed, etc.

I've tried a couple of variations to find a happy medium to all this. On my last project we did the upfront tasking, but timeboxed it at an hour and a half. Any stories that didn't get addressed in that session reverted to Just in Time tasking. We prioritized the stories based on a feel for how complex they were going to be, so that we usually addressed the most complex stories during this session.

Another variation was used when I had a team of about 20 developers. Because of the team size there were a lot of stories each iteration. Upfront tasking with the entire team was a painful affair, but issues arose as a result of Just in Time. So the solution we settled on involved the team breaking into smaller subteams right after the planning meeting. These subteams took a subset of the cards and did the tasking for those. The team was pretty good at breaking themselves up into these subteams, often switching people around mid-stream if other people were needed.

So, the answer to the question is that it depends on the situation. If you keep the issues above in mind, and are willing to try a variety of approaches, you should arrive at a method that works best for your project situation.

Resistance is futile

Well, I finally went and created a blog. Never really had much time to spend blogging (and still really don't), but I've given the same advice over and over so many times that this seems like the best way to get it down once and share it with everybody. So now that it is here I hope to be able to capture my insights and experiences with Agile methods on my projects.