In my first post in this series
, I set the stage for using agile to scale agile development within an organization. In this post we'll explore at a high level how we get started using agile to scale agile, and the steps and deliverables needed to take us to the point where we can make use of an Agile Organization Release Planning process for our organization.
First, let’s take a small step backward and ask the obvious question: “Why use agile to scale agile?” Here are a
few good reasons:
- Agile project management approaches shine when dealing with complex, highly dynamic problem spaces…and transforming an organization is just that!
- Use of agile for scaling reinforces an organization’s commitment to Agile to its members.
- It can aid in embedding agile into the culture of an organization at all levels.
- Having a continuous improvement cycle built in to change initiatives is very important and at its core, agile provides this principle/practice.
So where do we start? First, our organization should have a clear vision of itself on the other side of the transformation, including what it will look like and what it will be capable of doing.
As part of this exercise, the sponsors of the agile transformation must identify the clear business benefits linked directly to our organization’s strategic goals that will be served from adopting agile methods. Getting alignment with these goals is important.
Next, we must identify misalignment to being agile within and across the functional areas of our organization. This will help us to build out our product backlog or, as I’ll refer to it, the "Agile Transformation Backlog."
Also, we want to avoid big up/front planning for the scaling efforts. We just don’t know enough and there isn’t a crystal ball!
Next we will want to Plan for "releases" of our agile organization. Just as we use agile software development to plan releases and iterations to build a product, we can use it to plan for releases of an agile organization.
We’ll need to execute our agile scaling in an incremental and iterative fashion. Doing so will enable our agile teams to continuously groom the Agile Transformation Backlog. It is important to avoid having everyone go agile at once because you can greatly increase the likelihood of misunderstanding, confusion, and failure.
You will want to hand/pick the first agile pilot projects. Are they likely to succeed? Do they have the necessary training and support? Look for the opportunities to get wins and experience on smaller efforts, and then start to scale up to the bigger/harder projects.
As we progress through our agile organization release plan, we’ll want pay particularly close attention to retrospection to gain continuous improvement. Through regular review and retrospection, we can adjust the release plan as we learn from pilot projects' iterations.
The table shown above is what a high/level current vs. future state analysis might yield for an organization going from waterfall to agile. This type of analysis provides a good initial framework for developing the Agile transformation backlog. All of the misalignment items should have backlog items in the Agile Transformation Backlog covering how each functional area would get from the current state to the future state. The organization will want to produce a deliverable, such as the one shown, and share it broadly to get feedback. This is important because the perceptions of gaps between current state and future state can differ greatly between people.
So with an initial Agile Transformation Backlog in place, we can move on to planning our Agile Organization Releases. I will pick up on the Agile Organization Release Planning topic in the next part of this series... stay tuned!