Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 4

I started this series with observations that my clients appear to confuse strategy and tactics. They think agile approaches are tactics and agile tools are part of their strategy. That's why they want to Buy an agile approach. And that's why they want to Customize and then standardize on tools.

This post is about this question: why do organizations want to standardize every team's board? Worse, why would they Build their own board?

Because the managers don't realize that when they create a “standard” board, they demand every team follow the same workflow. The “best” board for a team reflects that team's tactics—the boards cannot even drive those tactics.

When managers want to standardize on boards, they don't realize each team solves different kinds of problems. And that each team has a different workflow. The teams require different boards.

Why Build a Company-Wide “Standard” Board?

As with most juicy questions, the answer to this might be “It depends.”

If they created their boards years ago, they might not realize there are commercial (or paper) boards that do what their tool does, and better. (They don't realize they are in the lower right quadrant, Build and Replace. They think they are still in the upper right quadrant.)

Worse, the longer they maintain their custom board, the more they spend on that internal product.  And the less they have to spend on products that affect the customers.

I do want organizations to consider internal work that makes life easier for product teams. However, if there is a Buy alternative for commonly-used tools, I would move to that as early as possible.

What if they didn't Build the board years ago?  What if they Customized the board? In that case, it might be one of these possibilities:

  • Managers don't realize they are micromanaging the teams.
  • The decision-makers think that tools fall into “economies” of scale. They can manage the cost of the tools
  • Not realizing a standard agile approach is an oxymoron. Teams need to experiment and change their agile approach.

I already said teams must be able to choose their own agile approach and their own kind of board (see Part 2).

Here's what I see too often: too many managers think they can use a standard board to “hold teams accountable” to organization-wide measures. Why? Because the managers feel tremendous pressure.

Standard Boards Create “Accountability”

When I see managers impose a standard board, they tell me they will learn from a team's velocity. These misguided managers think they can use velocity to compare teams. Or to use velocity to see how “well” teams are doing.

That's a misuse of velocity and why I recommend teams measure cycle time instead.

When managers misuse velocity, I wonder if they think the team's board is similar to a Gantt chart, even if it looks a little different. But any board is nothing like a Gantt chart. A board reflects a team's reality as of today and a little bit of what they might do for the next few days or a week.

I suspect that personal management deliverables with the ensuing pressure causes managers to act this way.

Even so, managers don't have to act that way. They have choices—which leads us back to strategy and tactics.

Understand the Difference Between Strategy and Tactics

If we want agility because we want to iterate on our strategy, we need to encourage teams to experiment and change:

  • As part of continuous improvement, teams change their agile approach.
  • When teams change their agile approach, they might want to change their board. Please allow this.
  • The faster the teams experiment and deliver small demonstrable features, the more frequently the managers can review and change the strategy.

The conclusion I draw from this is simple to say and difficult to do:

Stop “standardizing” anything for the teams. Address the cultural changes necessary for agility.

Standardizing on anything for agility makes no sense. If you want the strategic advantage of an agile culture, optimize for experimentation and adaptability everywhere. That includes a team's agile approach and its tools.

Agility might offer you a strategic advantage—if the teams decide on their own agile approach. Tools are tactics. Let each team customize both.

The series:

(Sorry it took me so long to write this. I learned what I wanted to say as I wrote.)

3 thoughts on “Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 4”

  1. Agile project management tools aren’t the only tools where over-standardization can be a detriment. I’ve also seen this with defect tracking tools, requirements management, and more. The cause generally is a corporate attempt to maximize profit by minimizing overhead costs. Surely centralization of the purchase and maintenance of tools will reduce costs! But if taken too far, the centralization, as you point out, increases the labor needed to create saleable stuff. The teams can compensate by working longer hours, but only to a point. After that point, the centralization slows down production of saleable stuff and thus reduces profit. This overall system effect unfortunately is very difficult for management to see. Cycle time measurements can help.

    1. I agree with everything you said. Yup, cycle time can help people see what’s really going on.

      BTW, it doesn’t have to be specifically agile tools. A gazillion years ago, HR managed a lot of our interactions with various systems. Now, people do it themselves. I wonder how many hours people lose each week, interacting with those various systems.

  2. Pingback: Testing Bits: 407 – August 22nd – August 28th, 2021 | Testing Curator Blog

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: