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 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
  • 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…

The post Using Agile to Scale Agile – Part 3 appeared first on VersionOne Blog.


More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read 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
Contact Us