Skip to main content
Enterprise Agile Planning icon with arrows

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 Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us