Agile Estimating and Planning with TargetProcess - RCC4

On Saturday, the Thycotic crew (well, only three of us this time) went down to Richmond to the forth Richmond Code Camp.  It is a 2 hour drive but my new handy TomTom GPS did well - asides from one occasion where it decided to re-route us back through Washington DC when we were only 30 minutes from the event!

Kevin presented on "C# 3.0" and the audience seemed very pleased with the content.  We had seen the presentation the day before at an internal Thycotic meeting so we knew it would be interesting - there are lots of new interesting language constructs coming in 3.0.  As many on our team pointed out, it seems that C# is starting to look a little more like Javascript and Perl these days.

I presented at the very end of the day on "Agile Estimating and Planning with TargetProcess".  This is a new presentation for me - we have been using TargetProcess for about 6 months now and I wanted to share our experiences with the community.  Mike Cohn's book was invaluable in my preparation for the topic - a definite must read.

TargetProcess has been used to manage the last two releases of Secret Server.  It has taken a little time to get accustomed to the user interface and the location of various features (there is a lot of functionality in the product!).

My favorite things so far:

• The iteration planner - as product owner of Secret Server, this is the screen where I can prioritize and make tradeoffs so it is definitely my favorite.
• Assigning tasks to a pair (we actually used TargetProcess back at version 0.9 - about 3 years ago but it didn't support pair assignments which was a big deal for us)
• The burn down chart - this let's me easily see that we are on track to release Secret Servrer 3.2 on 22nd of October 2007.

There are more things I like but those are the most obvious ...

The presentation seemed to be received well (download presentation) and there were quite a few questions.

Here are some of those that I can remember:

• Q: How do you account for one developer being more productive than another when planning?
  A: Simply track velocity at the team level. Then it is all leveled out.  If the team does 30 points per iteration then it does not matter if one individual contributes more than another.  By knowing the team's velocity you can plan your release.
• Q: How do you assign tasks to individuals and fit that within your plan?
  A: Agile teams should strive to be self organizing - this encourages team "buy in" to project goals and ultimately responsibility for the success of the project (the most important outcome, right?).  A self organizing team can assign tasks through discussion.  The collective decisions of those who know the software, tasks and skills available should be the best.  Note that this may take some work, especially if they are accustomed to being told what to do ... but the empowerment with a little coaching should be good for the team.
• Q: How do you plan when an individual is only available to a project for a portion of their time?
  A: I recognize that this is a valid concern for many people in their environments.  In our environment it is less of an issue.  Why?  Because we don't specialize ... anyone on the team can do more or less anything that needs doing.  This makes it easier to assign resources completely to a project.  Example:  If I need two developers to finish a project ... is it better to have 50% of four developers or 100% of two developers?  Many choose the four since the available skill set is larger.  The problem is that those four will have to context switch frequently between their various tasks.  Obviously this idea will not work for everyone but in my experience agile teams tend to be less specialized in their individual tasks.