The hardest thing we do is communicate across teams.
—Troy Magennis
2.3
EXPOSE DEPENDENCIES
San Francisco, 2012
A large organization launches their third Agile transformation. A new team of consultants arrives to assess the situation. The new Agile teams are organized into subteams of five to nine people. Pizza is frequently delivered to these teams. (Remember the pizza problem from Section 1.2?) They had heard about the success Google had with two-pizza teams, and so this large organization decided it would work for them too. Many stories impacted other teams. They called these stories “away” stories because you had to go away to another team to solve the problem. Away stories impacted approximately 92% of the teams. Lots of people seemed to be away, well, a lot.
Thief Invisible Dependencies (aka Thief Unknown Dependencies) sneaks up on teams. A stealth-like time thief, Thief Unknown Dependencies reminds me of something someone once said to me that stuck: “By the time you find out you suck, you have sucked for a very long time.” Similarly, by the time invisible dependencies are reported, you are already in deep water. The damage is done. But have heart—There is, as always, hope. This thief tends to thrive, predictably, when many teams work on different parts of one big system. The more teams, the higher the probability that more features are worked on at the same time, and this opens the door for more dependencies.
You know Thief Unknown Dependencies is robbing you when you hear, “Oh, by the way, so and so made this change/did this thing,” and your jaw drops. Or worse, you get blindsided by the arrival of an unexpected instant messages from another team indicating a devastating problem. The hardest thing we do is communicate across teams. So, what do you do now? All the pizza in the world can’t placate Thief Unknown Dependencies.
When a crisis occurs with one project team, people from other projects can be pulled off of their work to address the crisis. This leads to what is known as a high coordination cost. When the coordination cost between teams is high, people aren’t available when you need them to be—and a project manager is often put in place to coordinate.
A large organization on their third Agile transformation attempted to deal with coordination issues by using spreadsheets. Dependency spreadsheets began floating around between some of the teams. This meant that some teams were in the know and some teams were blind to it. The hardest hit teams were shared services teams that supported multiple departments.
The consultants decided to try and minimize this risk. After some thinking, they came up with the following ideas to bring visibility to and deal with the dependencies:
The idea of using cross-functional team stand-ups to flag dependencies was quickly abandoned because it was impractical, if not impossible, for groups of impacted people to attend numerous daily team stand-ups. The coordination cost was too high, and it would result in people spending all day in meetings.
The dependency matrix idea, however, had some real merit. One clever consultant created a floor-to-ceiling dependency matrix, which looked sort of like Figure 11 but much bigger:
Figure 11. Physical Dependency Matrix
With everything laid out like this, people could begin to see the problems that resulted from having so many dependencies. It took a long time to finish stories because the experts capable of solving the issues weren’t available when needed.
When a bunch of two-pizza teams have a lot of dependencies between them, how much time is spent coordinating? It’s true, we like small teams because they can move fast. Just realize that by moving fast as an individual team, you’re less able to move fast at the organization level due to the high coordination impacts from having a large number of dependencies.
Now, what to do about dependencies? If they are a problem for you and your dependency matrix, or if software isn’t providing the necessary visibility, then you must find a way to make them visible across impacted teams.
Snazzy electronic automatic dependency mappers exist, but not many teams seem to take advantage of them. If you’ve got one in place and it works well (your dependencies on specialists or tightly coupled architecture don’t cause you grief), then that’s great. It’s still good to have a clear understanding of other ways to visually depict dependencies.
Sometimes, dependency mapping involves good, old-fashioned arts and crafts. Part of the joy of making work visible lies in tapping into those long-dormant, construction-paper-and-colored-markers skills from your elementary school days.
Note the last column on the board in Figure 12 titled “ARCH,” which is short for architecture review. The intent of the architecture review is to provide expert guidance and support to enable the desired business functionality. It is not meant to be an authoritative approval moment.
Figure 12. Arts & Crafts Dependency Board
If these options do not appeal to you or are not accessible to you, then take a look at Figure 13 which shows another way to visualize dependencies via your kanban board using a swimlane of its own.
Figure 13. Dependency Swimlane Board
Design your board(s) to keep Thief Unknown Dependencies far away as shown in Figure 14.
Figure 14. Dependency Tags on Kanban Cards
Or, visually call out dependencies between different teams so they can be broadcasted widely to reduce expensive business pain.
Figure 15. Show Dependencies Between Different Teams
Teams rarely work in isolation. If a skill set is needed from a different team, then hand-offs between the two teams need to happen. To avoid the “out of sight, out of mind” issue, visualize work flowing between teams. This helps people anticipate work that’s headed their way and avoid “Oh, by the way, you need to do this thing today” situations. It also provides them with a heads-up on potential issues that are coming their way, which is usually much appreciated. Visualizing important cross-team information helps communicate across teams.
Small Agile teams are pervasive across the IT industry, and it makes sense. Nothing beats a talented, motivated, and cohesive team that makes fast decisions and can produce amazing results. In situations where the team has everything it needs to design, build, and deploy the product, then lucky you—Thief Unknown Dependencies is not stalking your neighborhood.
However, large organizations with many teams are not so lucky in this regard. At a certain point, the organization has grown to where it’s impractical for lots and lots of people working on lots of different projects to be aware of every decision that impacts them (such as architecture changes and new third-party integrations). The more teams, the higher the probability that more dependencies are going to sneak into your day, project, objective, and so on. The more WIP, the greater the likelihood of Thief Unknown Dependencies hunting you down.
This is why you must expose dependencies—to avoid teams from unintentionally breaking existing functionality. Ask any team whose code has been broken by another team because they were unaware of a dependency created by that team—it’s no fun troubleshooting a broken production environment while customers complain about your company on Twitter. Be informed and inform others, use whatever method works best in your situation, and remember that starting simple is better than not starting. Increased visibility helps get you to the next level. It may even help you to get leadership buy-in for organizing by product teams instead of by project teams—something to consider if your current organizational structure isn’t serving you very well.
The problem is that project teams are short lived. Project people disband after dumping their project onto the Sustainment or Operations team and head off to work on another project. This transition is costly and time consuming. In the project team’s rush to make project due dates, things get left out—you know, like dependency information. This introduces more WIP into the system because the team on the receiving side must interrupt the team on the delivery side to get the necessary information needed to run the new stuff. In this way, the project team’s expertise becomes a domain knowledge dependency. The WIP piles up because by the time Operations interrupts the people from the project team, the project team people are already off and running on something new, and now they need to context switch back and forth until the old project is stable or the new caretakers are effectively cross-trained, because, well, dependencies.
Organizing teams around a product allows the people who developed, tested, and delivered the functionality to stay in their area of expertise. There is no need for complex, dependency-driven hand-overs. Instead, organizing teams by product decreases dependencies during hand-off to ongoing operational support.
The project/product distinction is an important one for many reasons, so let’s touch on that here for a moment so we don’t conflate or confuse the two, especially since one is more productive than the other. Projects are delivered as one big monolithic thing, meaning that coordinating all the activities within a big release is difficult and slow. Projects create big batches of work that are handed off to others at the end of the project to deliver and maintain. Projects come and go and require extra coordination and communication to set up and organize temporary teams. Many issues can arise when maneuvering through a cumbersome, project-oriented process.
In contrast, organizing and managing by product keeps the same group of people with the necessary expert domain knowledge consistently involved. Those who develop the product features don’t leave; they stick around to deliver changes to prod and maintenance. Project teams tend to be measured by vanity metrics (e.g., test teams within a project team are measured by the number of software bugs), whereas product teams are measured by the business value derived.
Senior Director of Technology at Pivotal Cornelia Davis noted in conversation at the 2017 DOES Forum, “Architecture is so tied to how we do our work. The preferred architecture is loosely coupled components, individual microservices, built by individual teams—autonomous product teams, not project teams.”1
EXERCISE
The “Oh, By the Way” Dependency Matrix
PURPOSE: To bring visibility to dependencies across teams, to help people anticipate what’s headed their way, and to prevent delays from unknown or invisible dependencies.
Time: 60 to 90 minutes (possibly longer for very large teams)
MATERIALS:
INSTRUCTIONS: Gather up the detectives on your teams. Their mission, should they choose to accept it, is to investigate and visually capture dependencies across all teams that could negatively impact their work.
Draw a large square graph with columns and rows. Using sticky notes, populate the column headers with your team names. Populate the row labels with the same team names.
Figure 16. Exercise Example
The rows show teams that are impacted. The columns show teams that impact others (the impactors, if you will).
Identify the outputs from each team that create work for another team and write that number in the intersecting square.
For example, a customer success effort to provide self-service training content impacts Marketing and Sales because of the awareness required to promote and support presales. Sales requires monitoring of the customer experience and collecting customer data for personalized offers and promotions, which impacts Product Team 1 because of changes to the website and data collection. Product Team 1 in turn impacts IT Ops due to security and data storage requirements.
Your job here is to identify dependencies between teams for an important upcoming feature or project, and mark an X in the intersecting square where dependencies exist. Each cell of the matrix represents one or more dependencies between the two intersecting teams. Capture the dependencies themselves on the matrix.
Once your cross-team dependencies are identified in the matrix, discuss which actions can be taken to reduce the risk of breaking or negatively impacting another team’s work.
Variation 1: Include upcoming risks in the matrix addition to dependencies.
Variation 2: Instead of teams, call out software components in the dependency matrix.
KEY TAKEAWAYS
