My first foray into Agile was with a product team back in 2004-2005. It was my first “real” job out of college, and my first experience with a death march. During the death march, I was struck on how bad the idea of death marching was. Working weekends, long hours etc. were a sign of failure not on the development team, but our a failure to plan, set expectations, and deliver frequently.
This rather horrible experience pushed me to explore better options, leading me into Scrum and XP. For a team that released once every year or two, delivering (and having acceptance) around stories etc. were very helpful in turning our team around.
So I’ve had a lot of success with Scrum – but I’ve had greater success in ditching it. Here’s a few (of my many) my reasons why:
#1 – Iterations are less efficient than pull-based approaches
With Scrum, there is an explicit commitment (whether the Scrum books tell you or not) on what stories are going to be delivered within the sprint, and ones that are stretch goals/extra/end ones.
There’s something psychological about timeboxing, and working filling the space allotted. When we moved away from explicit time-boxed iterations, and just delivered as fast as we could without iterations, we saw a marked improvement in delivery.
We still had regular checkpoints on schedule/timing/etc. but no longer were burdened by iteration boundaries to decide to do more work.
#2 – Iteration planning meetings were wasteful
Iteration planning meetings are seriously expensive. Group discussion around design, group estimation, group acceptance, all highly inefficient. These meetings are helpful when the team has problems with commitments or trust, but otherwise, these meetings require a lot of time and are very, very expensive.
I remember just getting bored to tears listening to discussions around stories I wasn’t developing on to begin with. Eventually, we had to ask the question, “are these meetings providing the value we are paying for”. Yes, there was some value, but not near enough to warrant so much expense. I’m sitting in a meeting, thinking, “can’t I just start actually developing software”?
Instead, just about everything was JIT’d. Design was done with our architect and product owner. Estimation was done in concert with tech lead and architect (though only really when there was significant new work). When stories were ready, they were put on the board. When a developer was ready to develop, a quick meeting took place between the architect and developer on the story.
Fast, efficient, and focused on delivery.
#3 – Scrum is highly disruptive in established organizations
I hate the term “scrum-but”. That these are viewed as dysfunctions is just insulting. For established organizations, Scrum is very hard to deploy. Moving from yearly or semi-annual releases to weekly iterations is very, very hard. And very easy to fail at.
Pull/flow-based approaches start with what you have, and work on improving that. Scrum works when the organization is open to change. Flow-based works when the organization is not, by starting with existing work, highlighting inefficiencies, and allowing the organization to decide to improve (or not). Shoving Scrum down the organization’s throat, especially when it comes from the development team, has a high probability of failure.
Disruption can be good, but it’s extremely risky. I think of Kanban more as “Working effectively with legacy code”, where we focus on improving what we’re already doing, rather than the “File –> New Organization” approach of Scrum.
#4 – Focus not on delivery
This might be a bit controversial, but the big difference between Scrum and things like Lean Software Development for me were the difference of focusing on process versus delivery. Lean focuses on delivering value, and having a set of approaches on discovering your unique way of doing so, where Scrum has a framework for a process and tells you if you don’t follow this approach, you’re doing it wrong.
Ultimately, our goal is to continually deliver success. Well, most developers anyway. Too much discussion comes around “are you doing Scrum” versus “are you delivering”. Delivering is what matters. Process is merely the how.
What I like about Scrum
A lot of people have had success with Scrum, including myself. I like Scrum, when it works well. What I don’t like is the assumption that it can work everywhere. It can’t, and it’s not a problem with your organization if it doesn’t. It’s a problem with Scrum.
Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum.
So how do you know if Scrum isn’t right for you? If it’s hard. If it’s easy, then it will work for you. If it’s hard, then you’re using a process to force organizational change, and that’s a rather lousy, failure-prone way to do it.