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.
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.
I’ll address the necessary role of management in the next post. As I finish the posts, I’ll link to the entire series.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Where I Think “Agile” is Headed, Part 1: Do You Need an Agile Approach? Opinions expressed by Java Code Geeks contributors are their own. |
