Yesterday I asked you to imagine you’re on a team with some bottlenecks, and share how you’d begin looking at the problem.

I got several great responses.

The answers are usually already in the room, so I would start with some open ended casual interviewing.

Another one:

Ask up to 5 why questions with the team, starting with why we have this problem.

And one more:

Transparent conversation assuring a safe space will help.

The common theme in virtually all responses was talking about the problem.

And that’s good. Of course.

But I find it interesting that one thing in particular was missing. I received virtually no indication that the team should try to measure the blottleneck, or look at data.

Maybe that’s not always necessary. Maybe the problem, and its causes, are obvious enough not to need measurement. But in that case, I wonder why we need a conversation?

I also won’t assume that everyone who suggested a conversation wouldn’t look at data at all. No doubt some of those conversations would lead to a measurement or data gathering.

What data do you have about your software development process, and any bottlenecks that exist?