How to Make Your Case for Change Based on the Story the Visuals Tell

I'm working on finishing a talk based on a recent Pragmatic Manager newsletter: Three Tips to Focus to Deliver Better Products Faster.

I wrote that newsletter because I'd given several recent talks where the audience told me their “agile” teams could not collaborate. Those “teams” were component teams and they were not near each other. They did not have sufficient hours of overlap. Worse, because the “teams” are siloed and distributed, they cannot complete a story alone. Every “team” needs the rest of the people.

Because I want to deliver a great talk, I spent the last couple of hours making visuals that show the hours of overlap. Here are their locations:

• The middleware and backend teams are in the Eastern time zone.
• The UI and frontend (including the API) team is in Spain, CEST
• The testers are in Bangalore, IST.

That means they have too few hours of overlap. While my spreadsheet shows that, my spreadsheet, in its original form, is unreadable.

When the Visuals Are Unreadable

Far-Flung Component Teams HOO.xlsx I cannot read this pdf and I bet you can't either. That's because the image width is too wide. It takes almost the entire width of my 24″ monitor at just 100% magnification. (I'm using a black Geneva font at 12pt.) It's not readable on a smaller laptop or in a presentation.

Why is it so wide? Because there are too few hours of overlap for this supposed team.

It's easier to understand when I split the hours into three different charts:

This first image shows the testers in India and the UI people in Spain. (If you click on the image, a larger, readable image will open in a new tab in your browser.)

This image is large enough to see in many possible modes, especially on a laptop screen or in a presentation. However, it only shows the testers and UI/Frontend people and their overlap. There is some, but not much.

This second image shows when these people have enough overlap to collaborate. However, notice the times that people work. The Eastern people start work at 8am. The Indian folks are at the end of their day, 5:30 pm.

The entire team has two hours of overlap. and two more hours where much of the team is available. But not all the team.

That means the “team's” cycle time increases.

Finally, this third image shows when the US teams work alone.

What happens when developers work apart from the rest of the team? Too often, they continue to write code without enough information from the testers or the UI people.

But the details don't matter yet. Step back and look at that first pdf, which shows “everything,” except it's impossible to see. We can go meta about the data and explain what the data says.

Go Meta About the Visuals

If the people who want to see the data can't see the data, that's information. Could I have used something like this screenshot from WorldTimeBuddy? While there is information about possible hours of overlap, there is not enough detail about when each person works.

The spreadsheet shows the unreasonable hours the people choose to work to make some progress. That's why it's time to change.

Data and Stories Make the Case for Change

The data shows we do not have an agile team. Going meta, to learn what we can just from looking at that initial spreadsheet, tells us everything we need to know:

• The team does not have enough time to collaborate as an agile team. (Mark and I wrote an entire chapter about this problem in From Chaos to Successful Distributed Agile Teams.)
• The cycle time will increase. So will aging. The throughput will go down. (See Flow Metrics and Why They Matter to Teams and Managers.)
• That combination of increased cycle time and lower throughput will increase the cost of the final product. (See Throughput: Why Salary Costs Matter Less Than You Think They Do or Wage Cost and Project Labor Cost.)

The fewer the team's hours of overlap, the longer the cycle time, the lower the throughput. The more everything costs.

That's why component teams, especially those separated by many hours, are not teams and cannot use an agile approach. However, they have options as in Three Tips to Focus to Deliver Better Products Faster. That's why data tells part of the story. The visuals tell the other part.

Visualize Your Data for Better Storytelling

All of us are emotional creatures, even (maybe especially!) if we think we are not. That's why I show pictures and tell stories in all of my writing. When I showed this client the unreadable pdf, he told me I was taking advantage of his good nature. When I explained I could barely see the spreadsheet either, we both laughed.

That was my way to enter his system, his frame of reference. While he had heard me explain about the flow metrics, seeing these spreadsheets helped him feel the problem. As a result, he slowly changed his organization from component teams with too few hours of overlap to collocated feature teams with significant hours of overlap. Yes, the product value team had trouble for the program, but they didn't have to work with each other every day. They could make a little time to work together each week.

The data details do matter. And if we step back and get an impression about that data? That might tell an even better story and make the case for change.

(If you have this problem, and want to hear what I have to say, go to https://www.meetup.com/virtual-agile/events/300515272/ and register for the meetup.)