Thursday, June 19, 2008

Managing Scrum with Dedicated Tools

...So we started hitting limitations using spreadsheets to manage the Scrum process. What did we look for in a dedicated tool?

First we wanted to manage user stories, the product backlog, the sprint backlog. We wanted to record the conversations with the customer about stories. We wanted to keep information about a story (e.g. the results of an analysis, draft screen designs, test results etc.) together with the story. We wanted to be able to access the information from our office, but also from our customer site or while sitting in the train between sites.

I think the integration of the entire planning and development process is the major arguement for a dedicated tool. You enter stories, maybe group them into Features, Projects or Releases. Then you estimate and prioritize them. Then they are assigned to a Sprint (maybe a team member too) in the course of the Sprint Planing. The team (or a developer) breaks the stories down into tasks.

A virtual Task Board let's you see at a glance how work is progressing on the sprint. The team members' dashboards tell them what their top priority tasks and stories are.

Test features let you create tests which can be associated with one or more stories. Combine test cases into test suites, then peform test runs against a particular release or version. Record and report the success or failures (you did define the tests before starting to develop, didn't you?). Integration with Subversion or other source code control mechanism let's you associate modified files with particular stories or bugs. So if you 'fix' something, but something else breaks, it is relatively easy to identify what could have caused the problem.

Help Desk functionality lets you take requests from your customers or users, convert them into bugs or stories (or just send a response back to the originator).

In short, you get support for an integrated process (Lean Principle At Work: Eliminate Waste, in particular, searching for information), starting from preparation through deployment and operations.

What is the downside of an online tool? Mostly reduced flexibility compared to cards. A physical taskboard is a much effective Information Radiator than a web page. And cards are extremely productive for the kind of group work that occurs in Scrum - brainstorming stories, sprint planing and the retrospectives. A program structures information the way it was designed to. If your needs are different or simply not envisioned by the tool, then you have to figure out a work around. With cards, just write what you want and pin it on the wall where it goes.

Home Grown Tools

By the way, we did consider home grown tools. If you buy something, you invest money to save time. If you have more time than money (or if the products out there really don't do what you want), you invest time.

My team decided that this was not a good trade off. We would not be able to invoice the time to build the tool. The author is a single point of know-how loss (This point was confirmed when the author of the home grown tool we decided not to use decided to leave the company). The tool will do exactly what we want, but if we want it to do more, we have to invest more time to make it do more.

An active community or a support contract means (or at least should mean) the product will do more next year than it does today, without your having to do something (except install the upgrade). If your development effort is trivial, then this issue doesn't really apply. But if your effort is substantial, well, be sure to think about where you are going to get resources to meet new requirements on the tool.

[Previous: Managing Scrum with Wiki and Office]
[Next: Managing Scrum with Traditional Project Management Tools]

6 comments:

Michael Dubakov said...

Dedicated tools is the only option for remote teams and viable solution for large collocated teams. But dedicated tool should satisfy the following requirements:

1) It should be web based (desktop tool is a nonsense for remote teams)
2) It should be flexible enough to adopt (team should not look for workarounds in general, especially for fundamental things like release/iteration planning)
3) It should support data flows (Web Services API) for integration with existing development tools

Dedicated tools is a heavy artillery. Often it may be an overhead for small teams, so beware!

If you need more formal process for any reason (remote team, customer requirement, projects visibility) dedicated tool is likely the only way to go. And definitely TargetProcess is the best dedicated agile project management tool I am aware of :)

Dusan Kocurek said...

Hi,

We are using scrum management tool not only for distributed teams. Results can be good even the team is small. Yeeh, task board on the wall is great. It is perfect because is visible all the time, you don't need to read manual :).

But I'm talking about burn down charts calculation, about integration, planning process support with knowledge of previous progress and history tracking.

I don't think that "it should be web based". Today's technologies enables to use "nonsene desktop tools" in same manner as a web with better UI and performance.

In my experience only few customers requires API to integrate with existing tools. For them it is just another cost - time and money. More preferred is included integration or modification to company's environment.

Daniel Ferenc said...

Our teams are using ScrumDesk (http://www.scrumdesk.com).

It is a virtual task board as many other tools.
But, this tool use little bit different story cards look and feel which is good for many stories planned for sprint.
Reports are calculated and visible in one place which is very good for stand up daily meetings. We are using our long-time used bug tracking Mantis inside the tool plus SharePoint for project documentation.

ScrumDesk's SideView provides easy and quick access to sprint and project status.

Also, don't forget retrospective. Good tool integrates retrospective process. Management can easy recognize what is best for development teams.

Michael Dubakov said...

C'mon, you mean WebEx or tools like that? Performance will be bad for sure and overall user experience baaad. Usual web based tools are tending to migrate to SaaS and desktop apps will not survive in the long term.

Michael Dubakov said...

My follow up Agile Tools. When is Whiteboard a Better choice than Software?

Adam Feldman said...

I am one of the Founders of Bright Green Projects. I love using a white board and post-it notes early-on in a project, but your team can grow out of these tools as your project matures.

A dedicated, web-based Agile Project Management Tool is almost essential for non-colocated teams. Other times we have found our Agile Project Management Tool most useful is when;

*Team members work on multiple projects
*You have a long product and sprint backlog
*An audit trail is important!
*Reporting and detailed monitoring is needed