I spoke at Agile 2019 last week. I had both a great time and a heart-rending realization. The great time was meeting and reconnecting with people. The heart-rending realization is our industry is in big, big trouble. Here are my thoughts and where I think the “agile” industry is headed.
Problems I See with “Agile”
Here's a summary of problems I saw last week:
- Too many people think “agile” will solve all their problems. “Agile” is a silver bullet and will fix everything—as long as the teams do it.
- Too many people think “agile” is what teams do. They don't realize management is a necessary part of the problem and solution.
- Too many people I met—and this is true outside the conference—want “the answer” and want the recipe.
- Too many people have not read a single book, a blog post, nothing. They picked up the words. They don't know what the words mean. For example, they don't know that “agile” is an adjective, not a noun.
People aren't wrong for wanting any of this. I would love a silver bullet solution. If only teams needed to be “agile,” we could solve most of the problems with late and problem-ridden projects/products.
I would love the recipe for many things. I would love to take shortcuts to my writing and not have to read all the books I read to prepare my writing.
All of these are indications that too many people think agile approaches are a project approach. People don't realize an agile approach is a cultural change.
Culture requires management involvement. In my view, if managers changed first, the entire organization would discover their own agile approach. Instead of all the scaling nonsense we see, we could create organizations with a better culture which would lead to better results. (Yes, that's why I'm writing the management books right now.)
Do You Need an Agile Approach?
Agile is not a silver bullet. There is no universal approach to agile work, and I include Scrum in that. Let's discuss why.
How much change does your product development require?
Many of the people I met who want to “install agile” or “use agile” have no idea what that means. They are not thinking about their necessary rates of change.
I might use VUCA, or Cynefin, or the Stacey Complexity curve. I've had better results asking people/teams about the kinds of problems they solve. If they solve problems that are totally deterministic—with one right answer—they are on the left side of this continuum. They do not need an agile approach.
Most of us are somewhere in the middle. We need to iterate on ideas and experiments to find a reasonable solution in a reasonable amount of time.
The folks who have problems all the way on the right need a ton of experimentation so they can recurse on the problem to understand it and wrestle into something more in the middle. They need to create small, safe-to-fail experiments.
An agile approach with a reasonable amount of experimentation works best with the problems in the middle and the problems on the right. People with left-most problems do not need an agile approach.
As to why Scrum is not the universal answer: Scrum is terrific for teams who are collocated or within 4 hours of overlap so they can collaborate. It's also great for teams that work on one and only one project/product at a time and can predict a little about any interruptions or support. If your team doesn't fall in those boundaries, Scrum will be a total pain and you might stop using it. Worse, you might think all agile approaches cannot work for your team.
(I'll discuss time for experiments in the next post on management.)
“Agile” is Not a Silver Bullet
Agile approaches are not the answer to teams that have trouble delivering. Yes, an agile approach at the team level will help. It might help the team:
- See its bottlenecks (where does the work get stuck)
- See its WIP (work in progress)
- Create smaller chunks of work (Limit the WIP in some way)
- See the team's technical excellence
Maybe more. Agile approaches help teams see what they're doing and not doing. (Create Your Successful Agile Project is about how to help a team select and use the agile approach that will work for them.)
And, I spoke with many Scrum Masters who said their team members work alone. No pairing, swarming, or mobbing. Their “team” works as individuals.
These people also said each team member has other work and that work doesn't get onto the team's board.
Most of these people work in mini-waterfalls, struggling to finish the work each “sprint.” I put that in quotes because most of these people have not read the Scrum Guide. They use the words. They don't know what the words mean.
I'm not going to discuss all the ways people misuse the Scrum words or how they misuse the Scrum intentions. I've discussed my worries about certifications before.
The entire series:
- Where I Think “Agile” is Headed, Part 1: Do You Need an Agile Approach?
- Where I Think “Agile” is Headed, Part 2: Where Does Management Fit?
- Where I Think “Agile” is Headed, Part 3: What Is The Recipe, The Right Answer?
- Where I Think “Agile” is Headed, Part 4: What Does “Agile” Mean?
- Where I Think “Agile” is Headed, Part 5: Summary
I totally agree with your thinking on this – I have just one caveat, Agile (noun used deliberately) is a silver bullet, but as you point out it could be the wrong calibre for your “gun” (corporate culture, etc) or the wrong type for the thing you want to hit (achieve).
Funnily enough I had updated my article relating to this just prior to finding yours – the universe is conspiring again 🙂
https://www.linkedin.com/pulse/weve-got-plenty-silver-bullets-mel-kendell .
Looking forward to your next post…
Mel, this is an example of great minds thinking alike! Interesting, I hadn’t thought “Agile” as a silver bullet, but that’s what people who sell frameworks sell it as. Good point. Thanks.
What we need to help people to understand is that bullets, not even silver ones, are not going to do kill the beast on their own!
A few things.
I love the term “install agile”. I’ll use it.
Recipe: I listened to an NPR article years ago where a woman recounted trying to recreate her grandmother’s recipe (cooking) for something (I don’t remember what it was) with precise measurements, after experimenting many times. She gave her grandmother a laminated copy of the recipe as a gift (Christmas probably) and her grandmother just shrugged. She didn’t need it. The story is about this granddaughter’s growth as a cook – from using recipes to, I might suggest, “inspect and adapt”.
I went through this same transition as a cook. My father was a great cook and I wanted recipes. He made chili once when I was young; I wanted to learn. I wanted to know exactly how much chili powder and other ingredients should go in. He would put some chili powder in his hand and say “about this much”. It frustrated me.
These days, I’ve made many meals where people would ask for the recipe and I’d have to try to recreate my thought process as I inspected and adapted while cooking.
I have the same approach to agile leadership and coaching. I have no recipe. I also understand the frustration of my father’s “about this much” when folks are in their agile infancy.
Shuhari: I try to practice but must remind myself of it when I’m coaching new teams. In my early coaching days I would try for transcendence before introducing simple routines. I use the mental reminder: “training wheels”.
I’d suggest that there is another problem you didn’t mention. There are those who read books and think they know from books (or a certification course). To me, information comes from books and classes; knowledge comes from practice.
“No Silver Bullet” by Fred Brooks. What is missing in most references is the subtitle: “Essence and Accident in Software Engineering”. I find that subtitle informative.
Thanks, as usual Johanna, for making me think. Now, I’ll get back to re-reading Brooks’ article.
Adrian, thanks for the cooking analogy. I like it! Ah, yes, the “read-and-I’m-an-expert” or “take a class and I’m an expert” problem. Yes, many of us (I include myself) need the background from books and classes. And, until I implement it and learn from my successes and mistakes, I don’t become an expert. I suspect I am not alone.
You’re welcome and enjoy Brooks!
Pingback: New PM Articles for the Week of August 12 – 18 | The Practicing IT Project Manager
I think part of the problem is that people don’t deeply understand the limits of the tools they elect to use.
I don’t agree with your statement that Scrum requires colocation (although it is always a good idea). I do think that there a limits around what Scrum can do: https://agilepainrelief.com/notesfromatooluser/2019/01/what-are-the-limits-of-the-scrum-framework.html
These limits centre around Teams and a common goal. Without these Scrum doesn’t work its magic.
All tools have limitations. When we fail to deeply understand the tool, we’re surprised when it fails us.
Mark, I totally agree with you that people don’t understand the limits of their tools. Thanks for your link to your article.
Maybe the issue is that I can count on one hand the number of distributed teams that have an adequate use of Scrum. Not even good, just adequate. I bet you’ve seen more distributed teams that succeed with Scrum than I have.
Yup, when we understand limitations, we are more likely to manage the various risks. I do wish people would understand that agile approaches are a subset of lean thinking, applied to knowledge work. That might help people understand their options better.