I have seen this common behaviour at many of the bigger client organisations I have worked with, who are transitioning to organisation wide agile adoption. The company will invest a lot in researching and eventually buying an agile management tool of choice (Greenhopper, Mingle etc...) and then lock it down so that project teams will have minimal access to change how they want to use the tool.
The sheer irony is that these tools are actually written to be as adaptive as possible to the development process followed in the team. These tools, and especially Mingle for one, is written keeping in mind teams that are following agile will evolve their processes as they move forward.
Story statuses and types could evolve a lot. For a team that has just started, they might just have to deal with stories and defects. But once the team starts making releases, they might also have to deal with enhancements which probably has its own workflow. Changes have to be done to the project tracking tool to accommodate this change in processes. These changes are not one off. A team might discover new types of work and also new ways of tracking and progressing through the work on a frequent basis.
The driver for locking down the project management tool is to force teams to use the same set of statuses and processes so that reporting can be rolled up at a program or an organisation level. A lot of times, senior program management tries to come up with an "ideal agile workflow/template" that should work for all teams and then use the tool to impose it on all teams within the program. The result of this is immense frustration within teams while they try to find workarounds to the system that is being pushed on to them. Teams in this state start moving away from the tool that was chosen and end up tracking themselves through more lo fi means (physical card walls etc..). This reflects poorly on the investment made in buying this agile project management tool in the first place.
Here are a few suggestions
* Roll up reports at a fairly higher level of abstraction when reporting for a program. This gives teams some more flexibility in coming up with actual numbers for the KPIs. For e.g. instead of tracking "Velocity in points", track "Velocity". This gives flexibility for one team to use story points and another which can use days, and another which can count stories :-).
* Don't rollup reports and don't lock down your workflows when the teams are still forming and storming. Let teams reach a stage where their development processes have matured a bit. Until then let each team present a different status report for themselves. Start rolling up once the teams have reached a performing state together.
Remember, every agile team has to adapt to different set of challenges and they can potentially come up with different creative processes to deal with them. For these teams to succeed the supporting systems and tools need to embrace change rather than impose order.
The sheer irony is that these tools are actually written to be as adaptive as possible to the development process followed in the team. These tools, and especially Mingle for one, is written keeping in mind teams that are following agile will evolve their processes as they move forward.
Story statuses and types could evolve a lot. For a team that has just started, they might just have to deal with stories and defects. But once the team starts making releases, they might also have to deal with enhancements which probably has its own workflow. Changes have to be done to the project tracking tool to accommodate this change in processes. These changes are not one off. A team might discover new types of work and also new ways of tracking and progressing through the work on a frequent basis.
The driver for locking down the project management tool is to force teams to use the same set of statuses and processes so that reporting can be rolled up at a program or an organisation level. A lot of times, senior program management tries to come up with an "ideal agile workflow/template" that should work for all teams and then use the tool to impose it on all teams within the program. The result of this is immense frustration within teams while they try to find workarounds to the system that is being pushed on to them. Teams in this state start moving away from the tool that was chosen and end up tracking themselves through more lo fi means (physical card walls etc..). This reflects poorly on the investment made in buying this agile project management tool in the first place.
Here are a few suggestions
* Roll up reports at a fairly higher level of abstraction when reporting for a program. This gives teams some more flexibility in coming up with actual numbers for the KPIs. For e.g. instead of tracking "Velocity in points", track "Velocity". This gives flexibility for one team to use story points and another which can use days, and another which can count stories :-).
* Don't rollup reports and don't lock down your workflows when the teams are still forming and storming. Let teams reach a stage where their development processes have matured a bit. Until then let each team present a different status report for themselves. Start rolling up once the teams have reached a performing state together.
Remember, every agile team has to adapt to different set of challenges and they can potentially come up with different creative processes to deal with them. For these teams to succeed the supporting systems and tools need to embrace change rather than impose order.