Joe Cincotta: Thoughts and such…

[37 Signals recently updated some great features on BaseCamp which fundamentally affect how we do Agile with our team, so I thought I would update this article as it still seems to get a lot of traffic.] 

After a lot of agony, I have found that there are really two ways of approaching a small lightweight agile development team with management tools. Rigid structure tools which try to implement a flavour of an agile methodology or loose structure tools which allow for your own approach to agility. There are actually plusses and minuses against each approach; so this statement is not about taking the steam out of Version One or Tackle by any means, but it is about our journey of discovery in dealing with non-technical customers and LOTS of disparate development tasks using only a thin veneer of project management on top.

We spent a lot of time looking at PMM tools like ProjectNet (which has a SCRUM module) and also dedicated agile management tools. We used Version One  for some time and whilst it was a JOY to use it really was focussed on a small area of scrum whilst overall project management was still left hanging. We just didn’t have enough management resource to deal with this upkeep of a micromanagement approach as well as all the project based high level demands of customers. We were also growing a lot (people and client wise) and V1 charge by user seat and it aint cheap for a company like mine – so with some regret we moved…

I tried in earnest to use Tackle, an open source alternative which is nice, but pretty immature. It shows in its lack of usability and it is still trying to enforce these approaches to Agile which we felt were hard to deal with.

After a brief attempt at using ProjectNet – which was inordinately complex to configure – we settled on BaseCamp. Its fees are not based on ‘per seat’ so the bigger you get the more cost effective it becomes. Its also very very flexible. Its not trying to impose a methodology on you, instead its got a very freeform approach to the architecture of a PMM tool and allows you to create the framework and the procedural rules to an extent.

Below is an introduction to how we use BaseCamp as a parrallel management tool for dealing with high level project mangement needs whilst also giving our developers the toosl they need to manage burn downs and stay agile…

1. Using MESSAGES for briefs (stories), bugs and support requests:
A brief for functionality, a bug request or a support ticket should be a MESSAGE entered in to BaseCamp with the appropriate category assigned to it. Once the brief is processed or completed we can change its state to completed by changing the category under which the item is filed. Just make sure that Admins set the MESSAGE status when you complete work. (ie: you need to have project managers or account directors or scrum masters with ADMIN access)

2. Using TODO Lists:
Each MILESTONE can have a TODO LIST. This TODO LIST should be set up to allow you to track time against it. By having a single goal with trackable time you can then start making the actual TODO ITEMS. Think of the TODO ITEMS for a goal as being like BurnDown chart for a scrum-oriented team goal. This allows an individual or mini team to manage their own development specific goals without making the high level project plan dirty.

This approach to using TODO LISTS also means that you can track your TODO LIST progress against a single Milestone which means no ‘Punting’ or moving all your tasks from week-to-week. Milestones can be set up like a sprint yet they can move if other demands come in without having to micromanage a shopping list of items you thought you could get done this week and now can’t.

3. Using MILESTONES:
MILESTONES give us the ability to create project goals and timings for our clients. Generally an Admin (Project Manager / Account Manager / Scrum Master) will create the MILESTONE after conference with developers regarding time and availability subject to customer priorities.

MILESTONES are the glue which bind together User Stories (MESSAGES) and Burn-Downs (TODO LISTS); once you create a MILESTONE for a User Story you can now bind the written brief (MESSAGE) to it. The TODO LIST allows the same function of selecting a MILESTONE and therefore viewing a MILESTONE will give the user visibility in to both the customer facing aspect and the developer facing aspect.

Depending on the technical ability of the customer, they can browse the TODO burndown or stay at the high level of MILESTONES and MESSAGES. They are connected yet (as mentioned above) they do not interfere with a simple high level understanding of a project.

Filed under: agile development, Software Development