...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.
Thursday, September 25, 2008
Wednesday, September 17, 2008
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.
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.
Thursday, September 11, 2008
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.
Subscribe to:
Posts (Atom)
Posts
