Home » Agile » Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 3

About Johanna Rothman

Johanna Rothman
Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.

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

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:

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.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

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

0 Comments
Inline Feedbacks
View all comments