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:
- Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 1. (Sets the stage for how I think about strategy and tactics)
- Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 2. (How agility might offer a strategic advantage.)
- Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 3 (How I think about tools)
- Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 4 (When we encourage teams to change their tools, we might get more agility)
(Sorry it took me so long to write this. I learned what I wanted to say as I wrote.)
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 4 Opinions expressed by Java Code Geeks contributors are their own. |
