Using Agile to Scale Agile – Part 2

In my first post in this series I set the stage for using Agile to scale Agile 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 need 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 approaches shine when dealing with complex, highly dynamic problem spaces…And transforming an organization is just that!
  • Use of Agile for Scaling also re-enforces 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. Getting alignment with these 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’ll want to avoid big up-front planning for the scaling efforts.  We just don’ know enough and there isn’t a crystal ball!

Next we’ll want to Plan for ‘Releases’ of our Agile Organization

Just as we use agile 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 teams that are involved 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 Agile Organization ‘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.  An 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 in this series… stay tuned!

Advertisements

About Mike DePaoli

Mike DePaoli has been contributing to the IT community for over two decades and practicing agile and lean approaches to software development since 1996 in roles from programmer to CTO. His evolved approach to crafting successful lean-agile software development organizations was forged by the meaningful challenges he undertook at prior employers and as an Agile Coach at companies such as eBay, Adobe Systems, AOL, NetApp, Disney, Boeing, EMC, and Trizetto. Mike’s area of expertise is helping organizations craft strategic change initiatives that educate on and establish agile and lean values, principles and practices at every tier of the organization. Mike applies systematic thinking with a multi-discipline approach to his work. Mike is a Certified SAFe Agilist, Certified Scrum Professional, Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO). He is a highly-regarded speaker in the Agile community having spoken at Agile conferences in North America, South America and Europe. He is currently based in the San Francisco Bay Area.

No comments yet... Be the first to leave a reply!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development

agiledad

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development

Agile Scout

Agile Software Development News

The Agile Horizon

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development

%d bloggers like this: