Monthly Archives: October 2008

Getting Started with Rally

I have been using Agile techniques on a regular basis for about 3 years now.  The team I work in has gone through some interesting evolutions with our iteration and release planning, and at the moment we are using Rally as our planning tool.

A little history first might be helpful in how we got here.  Early in the project it was just 2-3 developers and we were all developing C# code, using Visual Studio Team System.  Team System has a pretty good work item and defect tracking system.  You can enter defects, tasks, provide time estimates, and have dependencies between tasks.  Another really nice feature was that your check-ins could be linked to a task/defect, so to go back and see what changes were made in the code against the work item was pretty easy to do.

When the team was smaller this approach worked pretty well.  Our iteration planning meeting involved going through the open defects and work items (tasks, essentially).  Most of what had to be done was implicitly understood by the stakeholders, so priorities were typically pretty clear and mostly it came down to a scheduling exercise.  Team System did not seem to have any good mechanism for defining user stories and linking them to tasks, but with a smaller group of stakeholders and developers we were able to get by without a lot of user stories.  Was it a mistake to not put more effort into user stories?  Maybe, but that was the world we lived in.

All this worked pretty well while the team was small, but as the team grew it became more unwieldy.  There was no mechanism to graphically display the tasks and do any long term planning.  It was just a big task list.  You could sort it, but being able to lay it out graphically was not supported.  For a time we used a manual process where major tasks were put into a Visio diagram and grouped into iterations.  That allowed the team to see how functionality would be rolled out, but keeping it in sync with the work item system was a manual process and difficult and time consuming at best.  There was also no automated way to see if we were overloaded.

As the size of the team grew both in terms of developers and other stakeholders, we needed to find another solution.  We looked at several tools and decided to try out Rally.  Rally’s Community edition is free for up to 10 developers.  It also has some of the features that I found were missing in our previous process.

  • Graphical- Easy to drag and drop stories into different iterations and see when new  functionality will come online
  • Supports resource loading, so we can see how our iteration and release plans measure up against available resources
  • Hierarchical – Everything starts with a user story or a defect.  Tasks are grouped under the user story or defect.  It is also possible to have a hierarchy of user stories to group and plan related functionality.
  • Supports releases and iterations, so I can plan when formal releases will be available and easily see what feature sets (user stories and defects) will be in them.
  • Built in reporting tools for defects, and iteration burn down rate.

Like any tool it has a few warts, and I am sure I will get around to posting about them.  But in the two months I have been using it I am pretty pleased.


Project Retrospective

I held my first project retrospective this week. It was probably overdue, but there is no time like the present right?

I found Peter Steven’s blog and Boris Gloger’s paper on Heartbeat Retrospectives helpful in setting the format. I decided to cover the following topics in our retrospective

  • What did we do well?
  • What can we improve on?
  • Who has ownership of the things that can be improved?
  • What are the priorities?

We used sticky notes and a white board. You need to be succinct to state your point on a sticky note. Plus once they go up on the whiteboard they tend to lose ownership and they become the team’s ideas. There were only a few times when we had to ask who wrote something and that was only to clarify an idea. The group ownership of ideas keeps things flowing and prevents the meeting from being driven by one or two strong personalities.

Starting with “what went well” set the tone that the meeting is going to be positive and constructive. At other companies I have been at these type of meetings often turned into a finger pointing exercise and went downhill rapidly. Our team has a lot to be proud of, and it was great to reflect on the things we did well. And if it ain’t broke…..

The things we thought we did well broke down into 3 catgories: Team, Process, and Technology. I am not sure if that categorization was planned or an impromptu decision. Grouping them into categories didn’t really serve any purpose other than it allowed us to acknowledge each point as we decided where it belonged.

Like any project there are things that we can do better. We purposely did not put any limits on what people thought we could do better. Once we put everything up on the board we broke it down into two groups: Team and Organization. Team means we can do it within the framework of our own team structure. Organization meant we had to bring others (HR, management, etc) into the mix to help address the problem.

Once we had things broken down into 2 categories, it was time to prioritize the lists. There are a couple of different schemes you can use here. Seeing the same issue raised by multiple people may indicate something that is important. Ultimately we decided to do a simple voting scheme where everyone got one vote, and that seemed to work pretty well. Next time we may try giving everyone three votes, but that’s for next time. We have a small team, so there were only a few items in each category that got votes, but even that tells you something, and we were able to prioritize those items. The reality is you can’t fix everything, so you focus on what is most important.

Probably the most important part of a retrospective is that you take action on the high priority things to improve. I am anxious to seize the momentum and teamwork of the meeting. That is the challenge for me and the team in the very near future.