Scaling Agile with Working Groups
Before you rule this out as just dumb, hear me out first :)
Scaling Agile with various teams-of-teams constructs works great so long as you have the right coaching, experienced teams, and a practical approach of not adhering strictly to any framework like SAFe, LeSS, or Scrum at Scale. YMMV. However, most scaling strategies focus on related teams of teams. What do you do when you have a mammoth problem that requires a large percentage of the company to come together across many teams-of-teams to deliver?
So, let’s start by assuming your company has settled into a Scrum, Kanban, and XP inspired way of working, adopting agile principles and values, applying them in a way that focuses on the agile mindset: building the right things, and building them right. Maybe you’ve even started forming teams of teams to collaborate on larger initiatives, using Scrum of Scrums and PI Planning type concepts to focus on dependencies and blockers at scale inside your team-of-teams. But what do you do when an agile team has a product they want to build that spans a multitude of team-of-teams and requires a priority shift across many factions of the company, spanning multiple political lines, Agile Release Trains, and sits on top of many other “number one” priorities? Does it just never get done? What should you do?
I encountered just such a challenge recently and found myself struggling to find the exact agile scaling construct to help people find a recognizable approach to solving a problem of this magnitude using simple agile ideas. Turns out, I don’t think there is one. In fact, I think it’s just a really big Product Management challenge. I mean, we expect Product Managers (i.e. Product Owners) to just “bring everyone together” to make sure we understand the problem and consider all of the SME’s knowledge and expertise required to delight customers and build something right. Right? But if you need a small army of people to come together, it gets a bit overwhelming. So, we decided to mix up a little old school strategy into a new agile approach.
We decided to form a “working group”. I know, it sounds like a committee or a steering group or a program management team. Yikes! Super old school.
What’s different is that each named “stakeholder champion” in our working group is a liaison to a unique team-of-teams with agile delivery capabilities. We also have a business sponsor for this working group that can definitively say something like “this is an important priority that we would like to have done by the end of the year, with the understanding that existing priorities and business-as-usual functions will need to supersede it as needed”. We will encourage the use of shared OKRs and various prioritization strategies to help overlay this new initiative on top of everything else the company is doing. Transparency and collaboration are going to be critical to our success.
This product challenge is so big, not one person in the company can explain all of the parts or even comprehend all of the unknowns that will need to be addressed in order to be successful. So, our strategy of building a working group of key stakeholders was critical. At our kickoff, we set expectations for what we were striving to accomplish, and then shared vision statements, desired outcomes, and various “we know we’ll be successful when” statements. The big picture is inspiring as we are modernizing a critical part of the business that will benefit us all when it’s complete. And yet, if any one team or any one Product Owner were to try to pull off something this massive, it would never get off the ground.
With our stakeholders assembled and engaged, we then ran a simple exercise that encouraged active participation to help define the work that each stakeholder thought their teams would need to own and deliver to contribute to the overall solution. Stakeholders were encouraged to keep this very high level and to admit when they’d need to return to their teams to gather more information and detail as well as to itemize any known blockers or challenges that would inhibit the work. This produced seven big piles of sticky notes and then we asked them to start identifying dependencies and to drag these stickies to a canvas where we would build a sequence diagram of what work needed to be done when… as prerequisites, what things could be done in parallel in the middle, and what work needed to wait for other things perhaps closer to launch. And in one quick hour, we did not have a complete picture but we had an amazing graph of connected nodes starting to come together like a big puzzle, depicting a high degree of complexity with what our stakeholders knew collectively.
The plan going forward is to meet every few weeks and add detail to our solution map, ask for any fresh blockers or where teams need assistance, and start documenting any progress all in the same information radiator. As detail supporting the high level stickies emerges and work gets broken down, we’ll even add JIRA links to the underlying epics and stories so anyone can easily understand the high level at a glance or dig deep into any particular team-of-teams’ contributions. Our hope is that teams will organically find ways to work pieces of the puzzle into their backlogs and contribute to the larger mission.
Our approach may not be anything revolutionary, but the fact that we’ve been able to blend some old school concepts with our company’s overall agility has been very encouraging. As an Agile Coach, my hope is that we can continue to keep deadlines out of the conversation and treat this for what it is: a huge background project blending old and new ways of working that will require the whole village to come together to build something that will make a better future for us all without compromising our day-to-day and existing priorities. Wish us luck :)
About the Author: Brian Link is the author of AgileMisconceptions.com and the owner of Practical Agilist, LLC. Brian provides leadership and enterprise agile coaching services as an Agile Coach at LeanDog. He is the co-founder of the 2nd Business Agility Conference in North America and the Columbus Business Agility Meetup. Follow Brian on Twitter @blinkdaddy or LinkedIn, and subscribe to his newsletter.
