Many teams new to Agile start with Scrum. Scrum provides clear guidance, rules, and practices to help teams adopt an Agile mindset. It also surfaces a lot of problems in organizations, which is part of what makes it so difficult for many companies to do successfully. For those that have been doing Scrum for a while, the question becomes, what now? Is this all there is?.
Jimmy Bogard, in his article, Why I'm Done with Scrum, describes how after having success with Scrum, his team found they were able to improve their performance by letting go of some of the core practices of Scrum. Here were his reasons.
Iterations are less efficient than pull-based approaches
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.
Iteration planning meetings were wasteful
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.
Scrum is highly disruptive in established organizations
Shoving Scrum down the organization’s throat, especially when it comes from the development team, has a high probability of failure. 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.
Focus not on delivery
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.
While mentioning some of the things he did like about Scrum, Jimmy also mentioned what he disliked about the framework.
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.
Francisco Aquino, shared his thoughts on Scrum in the comments.
Scrum is a self-destructive methodology, it ceases to exist the moment people know what to do, when to do -- then the process becomes a burden and annoyance, you may have hit that point.
Ryan Cromwell, added
There isn't anything inherently conflicting with pull/flow based systems and the Scrum framework. I work with teams that ship each feature when it's done inside Scrum. They use iterations to create a forecast with the rest of the business among other useful things timeboxes provide.
J.B. Rainsberger provided a word of warning.
Let me caution you: just because you no longer need the scaffolding now doesn't mean that you never needed it. Iterations can play the role of scaffolding. They can help us develop discipline. Of course, they can become pointless status meetings, too, but people, not rules, did that.
The article also sparked some discussion on Hacker News and Drupal Groups. Fingerprinter added.
When I took over development of a extremely dysfunctional engeering team at an established startup with 100 people, the first thing I did (after watching for a bit to learn) was put in scrum. It worked. And it worked really, really well.
2 years later, it didn't work anymore. The team had matured, the organization itself had adapted to the leaner processes and mindset and, in time, the actual scrum process was too much. It was time to change again...
Adrian Howard, responded to the notion that Agile and Scrum were developed by managers.
Agile got popular in the early 00's [because] it helped many teams get better. It then suffered the curse of getting popular. Everybody and their dog started doing it badly, or relabelling what they were doing already as agile. Pretty much every agile method came from developers. XP in particular was a process that came from developers observing what worked well for them. Ditto Cockburn's Crystal methods. Scrum worked so well because it kept management out of the loop during sprint development (and that's also one of it's failings... but that's a different argument.
Sirktree mused about the benefits of Scrum vs. being efficient.
I often wonder at the real benefits of agile and scrum. Meetings can take up valuable time. Does an expectation of 'this is all the work I have to do this week' make developers less efficient? The overhead of scheduling so many things get in the way of actual progress?
On one of my current projects we did not do 'official' sprint planning and such, and as a result, got a ton of work done. But at the cost of client visibility into our process and much more stress due to needing to get to launch in a very short timeframe.
James O'Sullivan posted an interesting response, Scrumbut isn't always a bad thing.
There have been discussions for many years about the need to always do Scrum by the book. I think this statement might be true for some teams, but not all. I'm not talking about having a half-arsed Scrum adoption, but allowing your teams to evolve beyond it when they are ready. The last four words of that last sentence are critical.
For your initial scrum adoption I do recommend that you do everything by the book. Also hire some seasoned ScrumMasters to help you out. Though Scrum is a simple framework, sending someone on a 3 day course and expecting them to be an expert is naive at best. Another option is to hire an agile coach to work with your newly minted ScrumMasters. I can't stress this more. Don't go it alone. If you're serious about agile, then take it seriously and hire the right people to teach others.
Remember that Scrum is a starting place on your agile journey, not the final destination and not the only way to get there.
And Dave Rooney cautioned.
I've seen far too many teams be "pragmatic" about the practices they choose to implement, only picking the easy ones. They might do standups for a while and work in 3 week cycles. However, they never get the benefits of introspection, truly cross-functional teams, or a business-facing prioritized backlog. After a while, they pretty well abandon all that because they aren't seeing any of the promised benefits of Agile. Well, duh!
So is Scrum a form of training wheels Agile or are teams losing value by dropping some of the practices? If it's the former, what have your teams done when they've moved past the basics?