Stumbling Through Mediocrity
Stumbling Through Mediocrity
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
From the beginning of the Agile movement, I've heard the question: "But does it scale?" And at first, I was interested in that question. "We're not sure yet," I would reply. "Here are the challenges of scaling Agile, and here's what we're doing about it." A few people listened intently, but others seemed to tune out.
In sales, they teach that the first objection is often a false objection--misdirection rather than a real concern. "Does Agile scale?" can be one of these false objections.
I wasn't really being asked "Does Agile scale?" (By now, though, we know the answer: yes.) What I was really being asked was, "Does Agile work in large, dysfunctional organizations? Can I keep doing all of the ineffective things I'm required to do and still say I'm Agile? I can't have a co-located team--it's out of my control. I can't have active, involved product managers--they're too busy. I can't create cross-functional teams--it would disrupt our reporting hierarchy. How does Agile scale to my situation?"
It doesn't... at least, not well. Welcome to Mediocrity.
Agile involves (among other things) cross-functional teams, high-bandwidth communication, and adaptive planning. We know the best ways of achieving these things. The details vary, but when it comes to broad strategy, I don't think there's even any debate any more.
We know that the most effective way for business experts, programmers, and testers to collaborate is to put them on a single team that shares responsibility and authority for success.
We know that the most productive way for teams to work together is to sit together in a shared workspace and communicate primarily via ad-hoc face-to-face discussion.
We know that the most successful way for teams to meet market needs is to adjust their plans as they go, forgoing detailed long-term plans in favor of rapid feedback and maximizing throughput and value.
We know this, and yet it rarely happens.
What's really amazing is that none of these things are mechanically difficult. Greatness--at least in software development--doesn't require great talent. Talent doesn't hurt, by any means, but I've seen ordinary people work together to create great teams. No, it's not talent that's needed. What's needed is will.
Sure, if you ask, everyone will tell you that they want to be great. But put the above list in front of them and they shrink back. Being great requires making waves. It requires taking risks. And it requires saying "no" to people who want to hear "yes." In the end, people value calm waters and safety more than they value being great.
And so it doesn't happen. Already, there are people lining up to write comments about how shared workspaces Just Aren't Practical in the "real world." In the "real world," they'll say, cross-functional teams can't work because of time, distance, and reporting constraints. These ideas would never be accepted.
My point exactly.
There are alternatives to these ideas that preserve the underlying ideals--for example, you can have high-bandwidth communication with a distributed team--but those alternatives are even more expensive and difficult than the basic scenarios I've outlined. And so many putatively Agile teams don't have cross-functional teams, high-bandwidth communication, or adaptive planning. They stumble through Mediocrity, blinding themselves with trivialities while ignoring the signposts that lead to Greatness.
Refining My Direction
I've been coaching teams in agile development for nearly ten years. (September is my ten-year anniversary.) Since the beginning, I've been fortunate to work with a lot of teams who wanted to be great, and I think I've been successful in helping many of them do so. In the last several years, though, Agile has become more popular. The market has grown, but the number of organizations willing to be great has shrunk. The emphasis has shifted from "be great" to "be Agile." And that's too bad. As much as I like it, there's really no point in Agile for the sake of Agile.
Worse, with so many organizations interested in "being Agile" rather than "being great," a whole industry is springing up around providing watered-down, non-threatening, non-boat-rocking (and non-functioning) Agile. If the point is to Be Agile, there's no need for Agile to actually work. Sell a certificate and walk away. Everyone's happy, right? Right?
Starting now, I'm reorienting my business to focus on people who want to be great. I hope there's enough of you still out there. Agile continues to be the best way I know to get to greatness, so that's what I'm using, but I'm no longer interested in helping people find the lowest-impact way to slap an Agile sticker on their door.
I want to work with people who want to be great. People who aren't satisfied just fitting in. People who are willing to take risks, rock the boat, and change their environment to maximize their productivity, throughput, and value. If that's you--particularly if you're in a product-focused, entrepreneurial environment--I want to hear from you. We can do great things together.
What do I mean by "great?" I mean teams that consistently deliver software that's a market success, a technical success, and a personal success for team members and stakeholders. Specifically, I look for (and help teams achieve):
- High throughput (less than two weeks from concept to delivery)
- Market focus (close engagement with customers and emphasis on delivering value)
- Experimentation (using risk management to enable risk-taking and experimental ideas)
- Low defect rate (less than five escaped defects per month)
- Shrinking costs (development and maintenance costs decrease over time rather than increase)
- Joy (team members look forward to coming to work, and stakeholders love working with the team)
Published at DZone with permission of James Shore , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.