Agile’s Business Problem
Agile has a business problem.
I was watching a video of Uncle Bob Martin awhile back, and he said something that struck a nerve.
[Paraphrased] “When we sat down to do the Agile Manifesto, several of us wanted everybody to be sure that the purpose here was re-establishing trust with the business.”
At the time, he was making a case for TDD — how that if we keep writing code in Sprint 1 that breaks in Sprint 3, or delivering buggy software, or not being reliable, you lose the trust with the business. But I think his observation says something about the technology world in general.
Given a choice, we don’t want to be part of the business. Many technology developers work at an arm’s length or more from the actual business. After all, one of the big “benefits” of Scrum is that the Product Owner brings in a list of things for the team to do. The team isn’t expected to know business things, only deliver on a to-do list from the PO.
Most small company development teams have sales, marketing, and management out in the field bringing in the money. They just deliver stuff. Most BigCorp teams are so far away from value creation that I doubt many on the team could describe the relative importance of what they’re delivering or how it fit into the corporate strategy. They just deliver stuff. Non-profit development teams deal with inter-office politics: their goal is to produce something the non-profit likes. They just deliver stuff. Everybody — except for startups — just delivers stuff.
And why not? Let’s face it: business is messy. The amount of work you put into a product is not directly related to the value it might create. There are many factors outside your control. There is no single person to make happy. And other businesses are trying to do the same thing as you are — many of them with more experience and capability than you have.
Wouldn’t you rather just work from a to-do list too?
We tell ourselves what we want to hear, what’s popular. So we focus on our backlog, how well we create things using it, and how to improve our little world. We don’t worry about the larger one.
The problem is: once you draw the line at the Product Owner, once you make the trade-off that, for purposes of “all that business stuff”, the Product Owner is the magic guy, then it becomes a lot easier to start making other arbitrary compromises. Wherever there’s a business consideration, why not just change the rules so to eliminate it?
Is the Product Owner asking you for estimates on when you’ll be done? Stop estimating! Does several new recent corporate acquisitions mean that the new product is going to have 8 teams all working together? Insist on firing everybody until you get one team. After all, the organization should adapt to Agile, not the other way around. Rituals like demos and sprint planning bugging you? Hell, just go to kanban/flow-based work and who cares about cadence, calendar, or commitments?
Sometimes these conversations make me want to laugh. Sometimes I wonder: is there something there? Am I missing something that’s going to provide value for folks down the road? I intuitively like a lot of what I hear: things like flow-based work systems. But I think that’s the problem: we’re confusing the theory in our heads and what we’d like to hear or not with what actually works.
We’re resistant to philosophical change. I know there’s a lot of people in the Agile community who already have everything figured out. As a coach and technologist with 30 years of experience and eyes-on hundreds of teams, back when I started blogging and writing, I thought others would be happy to have me share with them.
I was mistaken. Instead, amazingly, most coaches and practitioners — even those with a year or two of experience and a 2-day class under their belt — already know everything. The old cranky farts are worse, because, well, they’ve been around the block a time or two. Selection bias is a powerful thing, and if you decided you figured something out back in 1995, you’ve had decades of time to convince yourself there isn’t much more to learn. We get the general idea of something in our head, then we insist on the rest of the world conforming to that general idea.
The Agile community is an echo chamber. Instead of viewing this entire enterprise as an evolutionary effort spanning many decades, we view it as a brand-based deal where we’re all competing for market share. People don’t worry which parts of Scrum to adapt here or there, they worry about whether Scrum is still “pure” or not. They worry about whether we have “true” Agile or it has gotten corrupted.
These ideas, instead of being just ideas that we’re supposed to take and learn from, have become some weird kind of Platonic form. There is a “true” Scrum, and if we could only stay in the light of true Scrum, everything will be fine.
We’re not using ideas as stepping stones; we’re coming up with things we like hearing and then branding them. Then we have arguments over branding. This is dumb.
The Agile community continues to have a crisis of conscience: are we part of a system that is trying to learn better ways of providing real value to real people? Or are we trying to create a system of value for the way we work that we will then expect the world to conform to? It’s an important question, and it’s important to determine which side of the fence you come down on.
To me, Agile is a series of ideas about things that mostly work in incremental and iterative development. None of it is perfect, none of it is a magic bullet, and everything I’ve seen so far has places where it works better and places where it doesn’t. I don’t say that to dismiss ideas like Scrum, XP, and so forth. I say it to put them in context. But it’s nothing if it doesn’t do something real for somebody, if it doesn’t deliver.
I expect this body of work to grow, and hopefully I can come up with a thought or two that might last a while. But if it’s going to grow, it’s going to need to keep becoming more and more a part of business and less of its own separate universe.
Note: I didn’t say the entire Agile community. I still have faith that this is the best place to be for people who care about happy and productive teams. My point is that the future is in startups and in adapting what we do in order to create real value (instead of just cranking out technical solutions), not in taking the tiny bit we’ve figured out so far, over-generalizing, and then trying to make the world conform to it.
March 30, 2014