A favorite author of mine once quipped, "The Christian ideal has not been tried and found wanting. It has been found difficult; and left untried," (G. K. Chesterton, What's Wrong With The World?, 1910). I want to adapt this quote for present purposes. How's this: agile philosophy has not been tried and found wanting; Scrum has been tried and been mistaken for agile.
Let's look at a list of scrum "ceremonies"[1] as generally understood.- Backlog refinement
in which the backlog of tasks is organized, tasks are clarified, and work is generally prepared - Sprint planning
in which a 2-4 week period of work is set out, mainly by taking tasks from the top of the planned backlog, if tasks weren't estimated in refinement, they are estimated now - Daily scrum
also often called a standup, in which team members meet briefly to discuss blockers and plans for the day - Sprint retrospective
in which the sprint's work is reviewed, mistakes are analyzed, and new standard operating procedures are set out - Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
You may have read my mini-rant about agile philosophy not being dead. If it's not fresh on your mind, let's quickly look at the four preferences make up agile philosophy or mindset:
For more information, you can go to agilemanifesto.org. Fun fact: there isn't more information. Just a list of signatories. Because this is all agile is. And it's really simple.
Scrum is a managerial structure that attempts to implement the agile mindset. The two have been implemented together side-by-side so often that in most minds they have become completely and literally synonymous.
Comparing the two lists, do you see a problem?
It's right in front of you, like your nose. Look closer. Take a step back. Focus and unfocus.
There. There it is.
The two lists have nothing to do with each other. At all. One is a managerial schedule that can be used to implement agile philosophy; the other is a philosophy that can be put into action any number of ways.
You could use that structure of two week sprints to approximately predict how many sprints a major initiative will take and then release it 3 years later, with rafts of documentation, thousands of pages of documentation, all sorts of bureaucracy, and have nobody ever care about the release because the problem it was trying to solve has long since gone away.
And the whole thing would have been perfectly Scrum. But there would have been nothing agile about it. In fact, this basic process is mostly what has been adopted by software shops that think they have "gone agile" or "undergone an agile transformation".
Veterans of this system usually call it wagile, a portmanteau of agile and waterfall. Waterfall is a project management system derived, I suspect, from manufacturing. These veterans often chuckle while saying, "wagile," and I can never tell if it's because they are sharing an inside joke or because they think someone hasn't heard it yet. I don't like this term either because it perpetuates the myth that there's anything agile about what they're doing. It does give hint at the fact that they know what they're doing isn't fundamentally different from waterfall approaches.
Scrum is just a management system. There are a number of other management systems that more or less effectively enable the agile mindset.
Don't get me wrong. You can do scrum in agile way. In fact, most software development teams that use scrum are reasonably agile. When the business asks them to pivot, they rearrange or jettison their backlog. By nature, they don't love paperwork or bureaucracy, so they keep intra-team paperwork and bureaucracy to a minimum. They grimace through useless Scrum meetings because "management" thinks daily status reports makes them more nimble. Software engineers often don't love meeting with clients, but often do like to see what clients are experiencing, understand the business value of their work, and respond to those insights rather than staying on a set plan.
Software engineers are, by nature, fairly agile. I love them for it.
I recently told another product manager that my two engineering teams don't do daily scrums. He was astonished. "Why should we?" I asked. "My engineers are high performing, peak-career adults who talk with each other and me in person or via instant messenger throughout the day to clear obstacles and ask questions. Why add another meeting to their lives? If some of them didn't raise their hand when they had a problem, we'd need some way of opening up that communication. Maybe then a brief daily meeting would make sense."
The other product manager continued to stare at me, but gradually, slowly started nodding.
Individuals and interactions over processes and tools.
Agile.
[1] I don't like the word "ceremonies" because they aren't ceremonies. They're meetings. Let's call spades spades. Refreshing language is all well and good, but we have a word for this thing, and changing the word won't change the actual thing.