How to Achieve Shared Understanding When Scaling Agile

Agile practices as described in the literature are suitable for small co-located teams focused on a single product. These small co-located teams quickly and efficiently establish a shared understanding of a project, the customer and the architecture within which they are working. As organizations scale Agile, teams aren’t working in the same room, they are sometimes working on multiple products, and it becomes very difficult to establish a shared understanding. But you don’t have to sacrifice shared understanding for growth. Leveraging visual specifications will help large, distributed, scaling organizations achieve a shared understanding more quickly and more effectively.

Visual Specification (n): a picture, graphic or display used to illustrate or accompany the description or identification of a requirement.

Agile & Shared Understanding

A small agile team typically has everyone sitting in the same room collaborating together. They end up with a very clear understanding of the product that they’re building and the problem they’re trying to solve. They’re all familiar with the architecture. There is a shared understanding that’s established within that small agile team.

In a larger, more complex organization, teams are supporting multiple products. They are not in the same room. They aren’t familiar with the complex architectures and the needs of the end users. Before Agile we attempted to use formal specifications to build this shared understanding. Many organizations use some form of Software Requirements Specification (SRS) as defined in IEEE 29148:2011. Other organizations attempt to use Unified Modelling Language (UML), a formal set of graphic notation techniques, to create visual models. Both of these approaches support complex multi-faceted views of what the technology looks like, the problem we’re trying to solve, and the underlying structure we need to support.

But in Agile, the specification is thrown out. It’s too much upfront. It’s too much detail and it doesn’t get used. But the teams aren’t small and co-located and they don’t have a systematic way to establish the shared understanding needed on agile teams. This is where it starts breaking down for organizations scaling Agile. They start operating from assumptions and build more than is required. They don’t have a way to coordinate complex features that cross teams. They don’t understand the outcome that is really needed and miss the mark.

But, We Already Have an SRS

We recently worked with a financial services company that had historically used formal specifications. They had started moving to Agile so they took their detailed SRS and started writing a lot of detailed stories. The stories looked a lot like the line items in their old SRS.

It was clear to us that the stories lacked context about why the stories were important and what problems they solved. It was difficult to understand the relationships among the stories. Without that context they were going to struggle to get clarity on what actually needed to be built, with coordination across teams, and to create options and be adaptable as the project progressed. We asked them to develop some visual specifications to create context to support shared understanding on the project.

A visual specification is a picture, graphic or display used to illustrate or accompany the description or identification of a requirement. It should be simple and fit on one page for the most part. It should include words as necessary to accompany the picture. In this case we wanted them to define agile personas for key roles, draw high-level process flows for the significant new features, and draw a simple architecture diagram to show how the various parts of the system fit together. This didn’t need to be formal. They should fit on one page and have sufficient information to tell the story.

They felt the visual specification was a waste of time. They already had the SRS and everything was already very clear to everyone involved. They had the old and architecture documents to fall back on if there were any questions. They were agile now and needed to get into the details as quickly as possible.

We pointed out how a few personas and a few pictures would help them identify and clarify any of the exceptions and edge cases across which they were going to run. They actually felt that an hour was too much since it was so clear to everyone on the project. After some discussion they agreed to spend an hour at the front of a release planning workshop developing some rapid visual specifications.

Four hours into the meeting, they were still arguing about what’s important, how the pieces fit together and where they were going to make changes. In the room, they had technical people, product people and people representing the end users. For the first time it became evident to all that they all had extremely different perspectives on the problem and solution.

Despite having a signed contract, a detailed software requirements specification and architecture documents that had been approved by the architecture group, they couldn’t get 15 minutes into a shared conversation to agree on the visual specification before communication broke down.

Viable, Valuable and Possible

There’s something between conversations in an informal meeting and formal specifications that is needed for scaled agile teams. Visual specifications are an important practice for organizations scaling Agile to incorporate. They provide structure for the team to collaborate around to develop shared understanding around what’s technically viable, what’s valuable to the business, the users and the customer, and what’s possible given the available capacity and capabilities. Visual specifications help close the gap between informal conversations and formal specifications.

We typically advise organizations scaling Agile to create visual specifications at the feature level. They will use these during release planning to write the appropriate stories to support the feature. They will use them identify risks to manage. They will use them to coordinate dependencies and stories across teams. Importantly, they will use them later to communicate and maintain the context of the features for the teams delivering the stories.

Not every feature needs the same amount of visual specification. Some may not need much at all. Often visual specifications can be re-used over time – so you don’t have to create them all the time. For example, personas tend to be used throughout the life of a product. When you’re in a planning meeting and sense there’s a disagreement, or it seems like people are having three different conversations about the same subject, then have someone draw a picture.

There’s a lot of work that’s been done in this space by people like Dan Roam and David Sibbet. They have conducted research around how the IQ in the room goes up by 70% when we use pictures to support our conversations. They also found the ability to remember what was talked about increases four times. We also are much more effective in sharing with others what was discussed when we use pictures.

Visual Specifications

Visual specifications tend to combine pictures and words so they appeal to the part of our brain that likes visuals as well as the part of our brain that likes language. They can support what’s valuable around the product – personas, product briefs, screenshots or business model canvases. They can support what is viable to build – logical architecture views, interaction diagrams, deployment models, process flows or user journey maps. They can support what’s possible – release road-maps and timelines. In fact, these visual specifications can support conversations that support all three.

Visual specifications don’t need great granular detail, but just enough to facilitate the conversation. These are high-signal and low-effort tools. They can be supported with data-driven examples as well. The data-driven examples can be elaborated in more detail as the project evolves. They may be developed at different times during the project and serve multiple purposes throughout the project.

Visual specifications support release planning. They support product owners and the business as they are slicing work up to create options. They help teams become very clear around the most important things to build and the options available. They help teams budget for how long the features are going to take to build. These visual specifications supported by data-driven examples create the context for sequencing the work and clearly coordinating work between teams to minimize or eliminate the dependencies that exist on complex projects.

Visual Specification in Practice

When teams are preparing for release planning, members can walk in with supporting pictures already prepared. As questions arise, the team may draw some pictures in the room. When drawing pictures in the room, take a snapshot of what’s drawn and store that as part of the specification. Capture the risks, assumptions and some data-driven examples and add some words to the picture.

Visual specification is useful to align QA. Combining a technical picture to describe how things fit together, a process or user experience-type picture and data-driven examples at the feature level communicate clearly to QA how to test at the feature level. Using the visual specifications to support story splitting help provide clarity on how to test stories in a way that complements feature-level testing.

We were recently working with a company that had over one hundred teams supporting a vast e-commerce platform. They were struggling with clarity on what work to do and how to write effective stories, and were being hindered by cross-team dependencies. They weren’t going to get one thousand people in the room for release planning. It wasn’t possible to put an Inventory Service developer on one hundred teams. They weren’t going to self-organize their way through the dependencies that would arise within the release. The release was broken into a set of Epics or business goals. Small groups that incorporated product managers, architecture and technical leads, QA and project managers used visual specifications and data-driven examples to gain clarity around the features needed to deliver those Epics. They also identified the cross-delivery team dependencies. They used this to coordinate the complex release across the delivery organization – dramatically reducing the number of features that got blocked. They used the visual specification to communicate to the individual teams just what was needed to deliver in the next release – quickly and efficiently getting shared understanding across the teams, including QA.

We recently worked with a small agile team that had been growing rapidly and had been bringing in new teams, including some offshore teams. They had been working very effectively as a small group. As they started to scale and add more teams, they reached the point where they simply could not scale the conversations. They weren’t able to have all the right people in the room. They were really struggling with this and we introduced the concept of visual specifications. We told them that if someone has to start waving their hands to describe a feature or draw on the white board to describe it, they needed to produce a visual specification. Drawing the picture would create shared understanding in the room and capture the part of the conversation that wasn’t clear to the people not in the room. This simple practice dramatically increased the productivity of new teams. It led to a lot of mixed conversations and shared understanding of the context of the problems they were addressing with their project. They also found that the personas that they drew as they were talking were long-lived. They used them again and again and actually started referring to them as they discussed their product.

Leveraging Visual Specification to Support Agile at Scale

As you’re incorporating visual specifications, make sure not to over think them. It’s not as formal and detailed as UML. It doesn’t have to follow any precise guidelines, as long as it captures the context of the conversation. Use them to communicate about the product and features across teams, to somebody who’s not in the room during the initial conversation or who joins the team later, or to go back re-establish shared understanding. Try to find the point where you produce sufficient specifications to support planning, shared understanding, sequencing of work and effective testing. But don’t produce reams of unused documents.