Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Jul 26, 2010 — Enterprise Agile Planning expert

Using Agile to Scale Agile / Part 3

Enterprise Agile Planning
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 toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding 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
  • Retrospection
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...

More from the Blog

View more
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Contact Us