This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Using Agile to Scale Agile – Part 3
In my last post in this series, Using Agile to Scale Agile, we generated an initial Agile Transformation Backlog by doing a gap analysis of where our organization is today vs. where we envision it to be on the other side of our agile adoption. In this post we look at constructing our Agile Transformation Roadmap / Release Plan that will give us a high level plan of the execution of our agile transformation.
It is important to remember that a critical factor to our success in using Agile to scale Agile is to always be mindful of the basic agile methods when we are making decisions. Keep the Agile Manifesto in mind:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The only adjustment I make is to substitute “Working software” with Working Agile Organization. In my opinion keeping things simple, attacking small slices of the organizations and having embedded in the culture the idea of continuous improvement will help to ensure success in your agile transformation efforts.
Before we continue, let me say, there is no one right way to do this… as with most complex problems, context is very important for crafting your approach.
Here is an example of what a high level Agile Organization Release Plan might look like. I’ve set it up using VersionOne’s release planning capabilities. Using a tool like VersionOne for planning and tracking an agile transformation gives the effort the visibility and transparency it requires. It also enables those involved (just about everyone in a company eventually) the ability to contribute ideas and have them seen and considered in a common environment / tool.
Agile Organization Release 1
- Identify the right projects to pilot with
- Educate & assess – education is key, make sure adequate training is provided to all involved. If possible, no function for the scope of the pilot should go untrained
- Enlisting an agile coach to help in planning transformation and then be present during the execution provides continuity and much-needed coaching to new agile teams on understanding agile principles and practices and reinforcing them.
- Select an initial agile development approach for pilot projects
- Establish 2 accountable teams – one for the leadership and one working team
- Execute initial pilot projects
- Design and institute first-cut agile project governance
Agile Organization Release 2
- Adjust from learning from pilots and other Release 1 transformation efforts
- Begin broader organizational alignment
- Launch and assess several more pilot projects – Seed new projects with experienced people – Expand training and coaching program
- Assess and modify the agile governance – map to existing systems as needed to keep people comfortable
Agile Organization Release 3
- Start to leverage more tools to help scale our agile efforts
- Expand our agility to encompass agile engineering practices, this includes:
- Daily build capability and continuous integration
- Automated testing: including unit, system and acceptance testing
- Test driven development
- Pair programming
- Design collaborative workspaces – This usually requires assistance from the leadership team to assist in changing policies to approve workspace reconfiguration… too often the cost of this is looked at without any regard for the benefit it delivers
- Consider a combined Lean Agile approach, applying WIP limits as well as defect queue thresholds.
Keep in mind that since we’re dealing with changing processes, roles, and behaviors, this is complex stuff and we just can’t plan too much in advance. It’s better to lay out the basic ground rules and then let the teams self-organize around the transformation problem with guidance from coaches. Change that teams arrive at themselves is the kind of change that sticks. If it is forced on them, its likelihood of success is greatly diminished, in my experience.
In my next post in this series we’ll take a more in-depth look at Release 1 of our transforming agile organization. Stay tuned…