In Part 1 and 2 of this series, I wrote about how an agile approach might offer strategic benefits. And because an agile approach changes your culture, I said the agile approach was part of your strategy.
So let’s ask this question: Can any tool—agile or otherwise—offer you a strategic advantage? (I don’t see how, but it’s worthwhile exploring this question.)
Maybe that’s too black-and-white. Maybe the question is this:
In what ways does an agile tool offer you a strategic advantage?
Tools have specific uses—they support you so you can accomplish the work you choose to do. The work you choose to do represents your strategy for now. (See Part 1 for possible questions.)
The work you choose to do makes your business unique. (That’s why project portfolio decisions represent your strategy.)
Can a tool help you make your business unique?
Maybe. Let’s start with a tool from my ancient programming past: a who-calls visualization.
A Useful Tactical Tool That Supported My Programming
Back in the 70s and 80s, when I was a programmer, we had too few tools to support our work. (This is back in the days where we added print statements to debug. Why? We either didn’t have debuggers or they couldn’t step through the code, one line at a time.) However, one of the tools I liked the most was a who-calls data visualization tool.
The who-calls tool let me see a static analysis of which other functions called this one. I used that analysis to see:
- Where else did I need to look if I wanted to change the inputs or outputs?
- Could I delete this, if no one else called it?
- Did I need to manage memory or footprint or performance if I wanted to call a different function?
Because of the computers at the time, I could assess and make tactical decisions about changes I wanted to make in my code.
This tool offered me tremendous value as I wrote, tested, and demo’d my code. Even though the tool was valuable and tactical, we could not Buy this tool. We had to Build it. And every single year, we looked for commercial alternatives, so we could choose the Buy option.
This tool was firmly in the lower right quadrant of my image at the top. Tactical, but unique to our business because of the special-purpose hardware.
While I am no longer a professional programmer, I am a professional “maker.” I make books, workshops, blog posts. That means I use the most common of all agile tools: a board. I don’t share my board with others, but teams do. So let’s talk about team-based boards.
Team Boards Are Supposed to Support the Team’s Work
In Part 2, I said that agile approaches might offer a strategic advantage, especially if you customize the approach to your context. And each team might have its own unique context. (You might want to review the examples for SmallCo in that post.)
I see a lot of organizations buy or decide on a specific tool for all teams. Not only does the organization specify a tool, but the organization decides how each team will use the tool.
Yes, the organization specifies the workflow for all teams.
The organization decides on the columns. And if they think that all teams use Scrum and do not need multiple columns, the teams can’t visualize their bottlenecks on the board. Worse, they can’t measure their cycle time.
Why do managers/organizations do this?
They think the tool offers a strategic advantage. Let’s explore that.
In What Ways Does a Standard Team Board Offer a Strategic Advantage?
Can a standard team board support the organization’s or product’s strategy? If so, the standard team board would allow new answers to these questions:
- Why do we exist as an organization?
- What is our purpose?
- What kinds of problems do we solve for which kinds of customers?
In my experience, a standard team board does not answer or change the answers to those questions. A standard team board only might support tactical questions:
- Which products or services do we want to offer for those customers?
- When do we want to introduce those products and services?
- How do we want our customers to use those products and services?
Especially the When question. The product roadmap might answer the Which and How questions.
So why do organizations want to standardize every team’s board? Worse, why would they Build their own board?
Let’s address that in Part 4 because this post is too long already.
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)
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 3 Opinions expressed by Java Code Geeks contributors are their own. |
