Stepping back from the strategic view of scaling agile, I thought I would share a very very practical first step.
GIVEN you have hundreds… thousands of developers (programmers and testers),
AND you have more than a few dozen product owners
WHEN your enterprise intends to scale agile
THEN you are going to need a tool to coordinate activity and decisions and summarise status.
- Everyone in the enterprise needs to use the same tool for task management. Whether it is Jira, Rally, Version One, TFS, Lean Kit, Blah, or whatever tool, the entire enterprise needs to use the same instance of the same tool. Your Agile Scaling initiative will have emergent requirements. Its hard enough getting everyone to adopt a process change on a single tool. Trying to do that on multiple tools would be impossible.
- The tool will need to support the entire scaled product owner process and the development process (whether it is Scrum, Kanban, XP, or whatever). There will need to be a minimum set of agreed processes that everyone will need to abide by so that the tool can be effectively to support scaling to the enterprise.
- Some agalistas will protest saying that the team should pick their own tools. They can but they should ensure that the corporate tool is always up to date. Given that teams are unlikely to want to maintain two tools, they should probably only use the corporate standard tools (My personal preference is that user stories and above are managed in the tool and tasks within a sprint etc are managed on a physical board).
- You will need to extract the data from the tool and put it into a reporting database so that you can isolate your enterprise reporting from the tool… so that you are not dependent on the tool for reporting, Also, this means you can more easily switch if you find you have selected the wrong tool.
- All reporting needs to be automated. You never want to be in the situation where people are manually aggregating data in a spreadsheet to get an enterprise view. This will break completely when you go into your capacity planning meeting and people are making last minute updates even in the meeting.
- You need to have a dedicated team who maintain the tool. You need to create the budget for this as part of the Agile Scaling initiative, and as an on-going activity. You cannot rely on a team maintaining the tool as a side project. The tool is a strategic asset that needs to be carefully controlled. Without proper management, your initiative can derailed by people adding the wrong fields or processes in the tool. The tool maintenance team need to work very closely with your Agile Coaches.
- Your tool and supporting processes need to be Agile. Your support team need to be able to add fields/change process in quickly as emergent requirements arise. Any tool that needs modifications to be made by the vendor to add fields etc. IS NOT FIT FOR PURPOSE. If you need to create a manual process as a work around, you have broken your process.
The IT Risk Manager 
February 16th, 2014 at 9:15 pm
I think this is only true if you are all working on the same product and you need to keep things in sync. when you work with total independent teams, I’m not sure you need to be this strict.
February 17th, 2014 at 7:08 am
Hi Yves
I agree. If you are working on totally independent products with no dependencies then this is not necessary.
Also, if you only have a few hundred developers and a couple of dozen product owners its not necessary either. I will explain in a further post. Its all about Dunbar again.
Chris
February 17th, 2014 at 8:22 am
This may come as a surprise, but even development teams notice that standardization is a good thing. Forcing a tool from above or outside is the best way to discourage its adoption. Hint: let them manage the tool(s) themselves, they’ll figure it out.
February 17th, 2014 at 2:45 pm
Hi Peter
Thank you.
Teams do understand the need for standardisation.
Note the constraints I placed on the organisation…
1. One tool. I did not say who chose it or how it was chosen other than it should be something that can be extended without having to involve the vendor (and their time consuming backlog).
2. There should be a budet for the tool rather than force it on the first team to set it up.
3. I did not say how it should be adopted.
Chris
February 23rd, 2014 at 1:46 pm
[…] Chris Matts gives a great summary of this context: […]
March 1st, 2014 at 12:46 am
A tool must be used to add value. Remember your Agile core values: people over process, collaborate, respect. Of the three levels of an average enterprise software company (portfolio, program, team/s), the team/s are the most important for use of any tool. Without this foundation, you cannot provide feedback to program and portfolio management.
To that end, pilot your best choice tool with teams and ask for the feedback. If they like it, consider next steps. If not, pick another tool and continue until the teams approve use.
Remember, it is a ‘get what you pay for world’. So don’t be frugal with the tool choice (management’s tendency – those who use the tool the least). Pick the best-of-breed tool that meets all three levels of need.
March 1st, 2014 at 8:05 am
Hi Darnell,
I agree.
I do not say how the tool should be selected. Context will determine the ideal process.
As to who is the most important, that is also down to context but I agree it is likely to be the team.
Could not agree more on the value rather than the cost of the tool. Though unless you are a tool vendor, this is a “good enough’* investment and you should not build your own if an adequate tool exists.
Regards
Chris
* The purpose alignment model in Stand Back and Deliver by Pixton, McDonald et all
March 3rd, 2014 at 1:33 am
[…] if your organisation is large, and conservative, and has a requirement to deliver things bigger than a single Agile team could handle in a sane timescale, and has much longer product development pipelines (including governance) than can be addressed by put a few empowered business people in the same room as the technical team, and has proven resistant to Scrum, XP, Kanban (etc), then here are some practises that have worked in organisations with similar characteristics. (Chris Matts has had the beautiful idea of writing that in a format that may be familiar). […]
April 13th, 2014 at 6:54 pm
[…] (Chris Matts has had the beautiful idea of writing that in a format that may be familiar). […]