Category Archives: Rally

New Team – First Retrospective

Rally recently held a “success tour” event in Boston. I have been using Rally for about 18 months, but recently began using it on a team that is new to Agile, so I was interested in seeing if I could pick up anything that would help ease the transition. The event started with a roundtable of executives who have successfully used Rally, and a quote that hit home for me was from Jochen Krebs who said “every team needs to find its own unique path within the Scrum framework”. Joechen’s presentation at the Boston event can be found here (you have to hit the “older” button a few times to get to his presentation).

An interesting follow-up to Jochen’s presentation was given by Heather Kanser who pointed out the danger of teams “cherry-picking” the parts of Agile that they wanted. Their talks were complimentary as Jochen’s comment about teams finding their own path was “within the Scrum framework”.

I came from a team that has had good success using Rally and Agile in a particular way, and one of the challenges for me has been to tailor the approach for a new team. We’ve been introducing some new processes and adoption has been a challenge for both sides. We introduced some new processes about how we do releases and validation, and recently pushed out a new release of the software. It seemed like a good time for a retrospective. Of course, if I read my own posts, I would have remembered that the right time for the first retrospective may have been right when I first joined the team.

The comments for “what did we do well” were very encouraging. Collaboration, better testing, delivering what we promised, fixing architectural issues were all mentioned. I was particularly pleased that delivery of promised features and improved testing were included. These were areas that I pushed hard for and it was gratifying for the team to see the value. It is always nice too when you hear team members say “that can wait for the next release”. I think one of the hardest parts of initially adopting Agile is having faith that regular releases will provide an opportunity for more incremental improvements down the road. Delivering what you promised is more important than trying to add more features near the end of the development cycle.

There was some good discussion about what we could do better. This was one of those times where as I heard at the Rally event, the team needed to find its own flavor. I tried to stay back a bit from the technical aspects and work more to facilitate the discussion. It was very interesting to see how what we thought were the most important items to address evolved over the meeting. We have some actions and a follow-up meeting scheduled. Should be interesting.


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.