The Great Wall—Scaling Agile on a Multi-Team Project

Category: Commentaries

Written by: Tom Looy

Introduction

If you are launching a large-scale agile project (e.g. one that requires more than a couple of Scrum teams) then careful consideration should be given to how you scale the management of the project.  Starting off by applying standard scaled agile management solutions (i.e. Scrum of Scrums or SAFe) may help you feel like you are getting off to a good start. However, with those solutions comes the danger of creating a management structure that focuses on optimizing the project structure primarily for management’s benefit rather optimizing the project’s structure for the delivery of a valuable, usable and feasible solution.

This paper describes a lightweight yet powerful approach to scaling agile management for a multi-team project. ‘The Great Wall’ is an approach that enables the emergence of a scaled management solution that focuses first on promoting the delivery of the solution but also satisfies the needs of management.

Goals for a Scaled Agile Approach

In setting up a scaled agile management approach for a new project you need to make sure that your scaling efforts support the things that make Scrum effective:

  • Deliver working software each sprint across the full technology stack of the solution.
  • Produce a single product showcase at the end of each sprint that includes the work of all teams. The showcase should not demo work done in siloes but rather a coherent customer experience that is the result of the work done by all the teams.
  • Provide complete transparency and visibility into the project. There can be no room for ambiguity, misinterpretation or obfuscation as to the status of the project.
  • Allow ‘just enough’ and ‘just in time’ scaling structures to emerge from self-organized teams based primarily on the needs of the teams.
  • Focus on building networks (relationships) and not hierarchies in your project structure.
  • Disintermediate planning data and project status. You need to minimize the number of intermediaries (e.g. versions, summaries or abstractions) of project status and planning data that stand between the project team and the organization’s management structure. With any project of this size there is a tendency to want to report status upwards with summarized or aggregate data.  But aggregations or summaries of the data often introduce biases and hide information. Therefore, minimize the use of ‘project dashboards’ in favor of using the same data in the same format that the project teams use to manage themselves.

‘The Great Wall’ – A Tool to Help Scale Agile

It may seem like a tall order to create a management structure for a large-scale agile project that meets all the goals listed above. But there is a simple and elegant solution, one that has been used successfully on large-scale projects, a solution that has become known as ‘The Great Wall’.

The Great Wall starts off as a physical wall that holds the User Experience Map of your solution. The map is first organized from the customer’s perspective, telling the customer’s story in reading the User Stories on the map going from left to right. The map is then layered into MVPs (Minimal Viable Product) based on the priority of the User Stories on the map. These layers correspond to the releases of the product.  (For more details on User Experience Maps see Jeff Patton’s article at http://www.agileproductdesign.com/presentations/user_story_mapping/.)

Next, The Great Wall is organized as a Sprint planning tool and a status-reporting tool.  Each of the User Stories on The Great Wall is written on a color-coded card that represents the status of the story: Completed, In Progress, Planned or To Be Decomposed.

Using The Great Wall

Now that the Great Wall is set up to tell the customer’s story and to tell the status of the project it’s ready to be used on a regular basis. 

  • All release and sprint planning sessions should be done using the Great Wall.  This is especially important when you have teams with interdependencies.
  • Conversations with your product owners should be done using the Great Wall in order to give context to the conversation.
  • When your team grooms the backlog they should also groom the Planned stories and decompose the Epics on the Great Wall.
  • Any and all status reporting for the project should be done using The Great Wall.
  • Do your Sprint showcase in close proximity to your Great Wall.  Refer to the wall and not a PowerPoint when you talk about what has been accomplished and what is planned for the upcoming Sprint. Give context of the work just accomplished in the Sprint in the context of the system as a whole.

Tips on Creating Your Own Great Wall

  • It takes discipline to keep The Great Wall up to date.  If it isn’t kept up to date people will stop relying on it and stop using it.  Use it and update it every day.
  • Expect some redundancy between your Great Wall and the Team’s Task Board. Don’t be tempted to use a tool to try to manage this redundancy.  It is a minimal amount of effort to keep your Great Wall up to date and the effort is especially insignificant when compared to the benefits you will get from it.  The very act of physically updating your Great Wall serves to actualize what can otherwise become abstract and remote.
  • If you are required to have an electronic story tracking system don’t complain about the work needed to keep it in sync with your Great Wall.  Just do it - serve your teams by providing them with a tool like The Great Wall that they will use. Shield them from having to deal with any redundancy – do it yourself.
  • It’s okay for The Great Wall to have a mixture of Epics and User Stories.  Decompose the Epics into User Stories ‘just in time’.  Use your backlog grooming session for this.
  • Leave completed stories on your Great Wall.  Remember that one of the things we are doing with The Great Wall is telling the story of the user’s experience so leave the story there for people to read.  It’s also great encouragement for the teams to see the progress that they are making together.
  • Don’t expect to get the structure of your Great Wall right the first time.  And don’t wait to get you think you got it right before you create your Great Wall.  The only way you are going to know if your Great Wall is working is by trying to work with it.  (In the example story below we tore down our Great Wall twice because its structure wasn’t serving the teams.  It was easy to see that it wasn’t serving the teams – they weren’t using it!)
  • Handwrite your cards on your Great Wall.  Having the cards printed out makes the team less likely to update the wall real-time.  Handwritten cards also make your Great Wall feel more organic and approachable.
  • Always be mindful of the ‘Noise to Signal’ ratio on your Great Wall.  Everything on the wall should provide information to those using it.  The color of the cards, the shape and size of the cards, the position of the cards even the color of the pen used to write on the cards should all mean something. I don’t even use different shades of the same color for what you intend to have the same thing. Every element and every aspect of the Great Wall must have meaning.
  • Be careful to not put too much information on the cards on your Great Wall.  I don’t use the “As a…I want to…in order that…” format on the cards.  I try to use short phrases to describe the story so the card can be read from a distance of about 10 feet.  I’ll also include the Sprint Number on Completed and In Progress cards and only on those Planned cards that I will play in the next Sprint.  (I won’t put Sprint Numbers on any other Planned cards as they will likely change as the stories get re-prioritized.)  As you size your stories you can include the story points on the card.  The only other thing I have put on the card is the story tracking number from an electronic tool if one is used.
  • I prefer to use different colored cards rather than putting different colored dots on the card to indicate status.  This does mean that I will have to re-write each card at least three times as the card goes through its different status changes, but I think it’s easily worth the effort based on the readability of the wall from a distance.  My rule of thumb here is I should be able to get a big picture view of the status of the project from a distance of 25 feet, something that is much easier to do with different colored cards than with different colored dots.

The Power of The Great Wall

There’s something special and empowering about working together as a team using a physical wall.  This is best told in Tom Wujec’s TedTalk on “How the Mind Works”: http://www.ted.com/talks/tom_wujec_on_3_ways_the_brain_creates_meaning.html.

The Great Wall is an organic entity as it continually reflects the current status and scope of the project.  The fact that the Great Wall is so easy to change makes it so empowering for the teams.  Things like re-prioritizing stories are done by simply moving cards on the wall, dropping stories by just removing them from the wall and adding new stories as they are discovered drives home the point that teams are empowered to be more adaptive in their approach.

I’ve used The Great Wall approach several times in my agile career.  Most recently I implemented it at a Fortune 100 financial company.  There I participated in the launching of a large agile project (projected for 5 years, US $200M budget, anticipated scaling to 20+ Scrum teams).  It was hard work getting it set up and getting people to rely on it but The Great Wall became ‘command central’ for the project, the place where all meaningful conversations related to the project took place.

Final Thoughts

Is your large-scale agile project not delivering as you were expecting?  Are you unsure about the real status of your project?  Do your dashboards show that you are on track with delivery but you still have this unsettled feeling that it’s not all coming together?  Do your teams lack engagement with one another?  Is there a general lack of engagement by people on the project?

All these symptoms are often the result of a management structure that attempts to optimize for managements sake teams rather than optimizing for the development of the whole system.  Management all too often tries to achieve maximum resource utilization or optimization of the parts of the system rather than the system as a whole.  That’s why tools like The Great Wall are so powerful – they provide a way for you to continually focus on the whole rather than its parts.

Creating a Great Wall, a physical User Story Map and Project Status tool in a prominent place for all teams to access is a great way to optimize for delivery while providing a status and management tool for the organization.  Let your teams know that they own The Great Wall. Drive all planning, backlog grooming, Sprint demos and status conversations to take place in front of The Great Wall.  You’ll find that your meeting will be more engaging, shorter and more effective.  Your teams will be more engaged with each other. Finally, management will have a truer picture of what is happening. Any ambiguity about the project is driven away as they rely on The Great Wall to see the bigger picture of the solution.