Scrum is lightweight. Scrum is easy to understand. But Scrum is very, very difficult to implement. As more and more organizations try to improve their way of working through Scrum, more and more are finding out just how very difficult it is. Sometimes, they despair completely and turn their frustration to Scrum.
My belief is that Scrum cannot succeed or fail. People do. This gives credit where credit is do, in both the happy successes and the tough failures.
I came across Adam Ard’s article today. His frustration is easy to understand for those of us who do the hard work of delivering software solutions to people’s problems. I feel his pain; I’ve been there, but I don’t blame Scrum.
I’d like to start today as humbly as possible, with a goal of reconciling the ideas in Adam’s article to the true intent and content of the Scrum Guide. The goal is not to prove him wrong. His experiences are valid and not uncommon. So common in fact, that it would be dismissive to pretend that his troubles were just he and his organization, “Not Scrum’ing hard enough.”
Therefore, let’s assume that there could be basis for each of Adam’s reservations rooted in the Scrum framework itself. Let’s assume the Scrum framework is poorly constructed and has led to the pain he’s experienced. If so, we should be able to trace at least a few of the bad behaviors his assertions to flaws in the Scrum framework. In my answers to his assertions, I refer to the Scrum Guide and teaching from Scrum.org courses.
1. Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to groveling to product management for any level of inclusion in product direction.
The Product Owner’s responsibility is to maximize the value of the Product and the Development Team’s work. Scrum encourages the whole Scrum Team to collaborate on the order of the work in the Product Backlog, especially during Product Backlog refinement. In a healthy Scrum Team, one who members practice Openness and Respect particularly the Development Team will have great influence on the Product Backlog order even though the responsibility and accountability for that order rests on the Product Owner’s shoulders.
2. Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability.
Tracking developer’s time is a common practice in some software shops and can often be a result of a full utilization mindset. In this theory, the goal is to reduce a worker’s downtime and increase their actual working time to as near 100% as possible. This has several, well-known negative consequences when it is applied to knowledge work.
Scrum does not have any mechanism for accounting for developers’ time. The closest dynamic is the mandate than the Development Team forecast the work it can accomplish in a Sprint as part of the Sprint Backlog. No one can create this forecast except the Development Team. Additionally, the Sprint Backlog is inspected and may be adapted in the Daily Scrum.
Here’s a visualization of the time spent in a 30 day Sprint:
This is assuming the maximum time box is used for each event. In practice I’ve noticed mature teams use only fractions of their time boxes leaving even more time for work.
3. Scrum encourages “least amount of work possible” solutions — to conform to it’s strict predictability requirements.
Scrum does encourage simplicity, the art of maximizing the amount of work not done. It does this by time boxing it’s inspect and adapt events and maximizing the amount of time that can be dedicated to work of the Development Team. Additionally, having the Product Owner be responsible for ordering the backlog based on what maximized the value of the Product and the Development Team’s work tends to cut down on wasteful work.
There are no strict predictability requirements in Scrum, there are only forecasts produced by the Development Team in Sprint Planning which are understood to be negotiable and are usually informed by empirical data from recent Sprints.
4. By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and/or ownership of their work.
Scrum does not assume any item should be completed by anyone on the team, but rather that the Development Team can complete any item. This does not discourage individual ownership, but rather encourages those with expertise to take greater ownership and make the best use of their expertise. They can do this by exercising it directly and mentoring their colleagues to increase the flexibility and resilience of the team. That being said, Scrum makes no prescription for how the Development Team should perform it’s work. The understanding is that they will practice the five Scrum Values and work such that the quality goals do not decrease.
5. Scrum is highly intolerant to modification, and it’s proponents typically espouse an all or nothing attitude in it’s implementation.
The Scrum Guide has changed numerous times since it was first published in 2010. It has been exposed to the same inspect and adapt rigor it requires of those who would practice it. I encourage anyone to submit your ideas for how you think it should change at https://scrumguide.uservoice.com/.
When practicing Scrum, it may be both appropriate and inappropriate to take a hardline approach. Much like with one learning to drive, it can be dangerous to diverge from commonly accepted practices until the student has learned the fundamentals; however, once an individual has mastered the basics i.e. building high quality, high value software delivery in the Scrum framework all while having strong practice of the Scrum Values, then it may be time for them to modify their approach accordingly. At this point, adhering strictly to Scrum may become a hinderance for future growth.
6. Scrum’s attitude of intolerance to self-examination is present in all of it’s practices. Only processes that operate internally to Scrum’s framework are open for modification — as for Scrum itself, it is seen as sacrosanct.
I would encourage you to get involved the the Scrum.org community so that you can witness first hand the constant and intense self-examination that occurs. I’m a professional Scrum trainer and know the extent and frequency to which the Scrum guide, teaching, etc are constantly refined.
To say, “It is seen…” is to imply a perspective outside the Scrum guide. There are times when mature organizations have mastered Scrum. When this happens, teams will find a ways to improve upon and even diverge from Scrum. This is rare and should be done responsibly.
Scrum is not sacrosanct. If compelling evidence showed it to be ineffective, dangerous or even unethical I have full confidence the Scrum guide would be taken down in a matter of days.
7. Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more.
The Product Owner and Scrum Manager are managers yes, though they do not manage people. The Product Owner manages the Product Backlog and the Scrum Master is responsible for ensuring Scrum is understood and enacted.
The result of the Product Owner’s management is that the team knows what it should be working on each Sprint and that work should be of the highest value. The result of the Scrum Master’s management is that the Development Team can work optimally within the organization and Scrum framework.
Scrum establishes a minimal management structure. The development teams are free to accomplish their work as they see fit, determine what they do 7’45” each work day, and have a respected voice in determining what they work on each Sprint.
8. Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective.
Scrum makes no prescription for tooling. It is a common misstep for organizations to choose a well known “Scrum” tool and expect that by simply using the tool that they are then doing Scrum. This can make all involved slaves to how the tool operates and cause confusion about what Scrum actually is.
Having said that, I have definitely experienced this. The most fun I’ve had and the most effective I’ve been as a developer has been using stickies on a wall. I’ve used Jira, TFS, Pivotaltracker, Trello, etc and all have their upsides and downsides.
It’s important to remember, a choice to avoid Scrum is not a choice to avoid project management tooling. Remember Microsoft Project?
9. Scrum discourages bug fixing, reduction of technical debt, and risk taking, all because of its narrow, exclusive focus on only doing items that Product Owners would interpret as valuable.
Scrum mandates that, “Quality goals do not decrease.” Further, it builds increasing quality standards into the Sprint Retrospective, “…the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate. Lastly, “…it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.”
The mission of Scrum.org is, “To Improve the Profession of Software Development.” Nothing could be further from the truth.
10. Scrum is hypocritical
a) Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on?
b) Are they required to present burn down charts that show that they are on target to finish?
c) Are they required to do bi-weekly sell-off meeting to justify their activities?
At the risk of sounding blunt, I’ll respond this way:
a) Scrum don’t care.
b) Scrum don’t care.
c) Scrum don’t care.
It may be that organizations learning agility by practicing Scrum will still cling to old practices, even practices like the burn down chart that used to be part of the Scrum framework. Scrum provides the necessary inspect and adapt events for teams practicing Openness, Courage and Respect to challenge the effectiveness of these traditional practices if they are shown to have negative effects.
11. Scrum makes many faulty assumptions
a) It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand-holding.
b) It assumes that engineers are not to be trusted with directing their own work.
c) It assumes that engineers cannot aligned themselves with the best interest of the organization, without tight supervision.
d) It assumes that engineers cannot conduct a meeting effectively without a facilitator (Scrum Master)
e) It assumes that you can plan every facet of a software task by merely talking about it in sprint planning/backlog grooming
f) It presumes that all engineers work the same way.
More bluntness on the way, mainly for brevity.
a) Scrum doesn’t mandate or even mention task tracking. Tasks can be a useful practice in the Development Team’s plan for accomplishing their forecast for a Sprint. That said, Scrum don’t care if you track tasks.
b) Scrum actually mandates developers should be trusted to direct their own work (Development Team should be self-organizing). Several checks are built into Scrum to ensure Development teams are free to determine their own ways of working, methods of development and even the focus of their work.
c) Scrum explicitly includes a Product Owner into the Scrum team so that developers can influence the work that is done on a Product. The opposite assumption is made, that developers want to do what’s right for the Product and the Organization.
d) It is common for growing teams to ask a Scrum Master to facilitate, but the expectation is that the Development Team and Scrum Team will develop the competency to run it’s own events when necessary or desired.
e) Scrum builds inspect and adapt events into to each day of the Sprint precisely because understanding will change frequently. Scrum expects that teams will encounter changing requirements and enables them to harness change for the customer’s competitive advantage.
f) Scrum is a framework for developing and sustaining complex products. Specialized labor is an artifact of Tayloristic, industrial age work theory. Scrum has it’s roots in modern product management theory and the systems thinking of J. Edwards Deming and others. Integral to Scrum are the principles of self-determination theory. The ethos of Scrum.org includes creating, “A world in which all software developers love their work, and their customers love working with them.”
Scrum presumes that developers want to do the right thing and are driven by the desire for autonomy, mastery, and purpose. If you disagree, I encourage you to look into the recommended reading for Scrum.org’s Professional Scrum Master’s course.
12. Scrum story points are supposedly meaningless, yet they are tracked, recorded and presented at many levels in an organization and often are the only metric by which a team’s performance is represented (ie. Velocity)
Scrum defines effort for each Product Backlog Item. You are free to determine how that effort is defined and tracked. Teaching from Scrum.org across the board counsels that these sort of estimates should be for the use of the Scrum Team only to describe the work involved in a forecast of work.
These effort estimates also allow the Scrum Team to forecast goals in the Sprint Backlog: “At any point in time, the total work remaining to reach a goal can be summed.” This does not imply the entire backlog, but rather only the effort needed to accomplish a particular goal. This is also implies a forecast and should be treated as “today’s weather” and subject to new discoveries tomorrow.
13. Scrum is designed to manage the weakest Engineers and consequently dis-empowers the better ones.
Scrum requires that developers work as a team. It places the emphasis on team success rather than individual success. More competent developers often find it in the team’s interest to bring along and mentor more junior developers such that the Development Team sees greater success. I do not see this as dis-empowering of more competent developers but rather enabling them to expand their influence and effectiveness.
14. Scrum is the opposite of many of the points set forth in the original agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I’ve demonstrated how Scrum encourages collaboration and is allows great leeway for process and tooling choices.
The goal of every Sprint is releasable software, first and foremost.
If you’re practicing XP, a customer/client is part of the Development Team. In this case, they are welcome in every, single Scrum event. This demonstrates the richness of what can be done in the Scrum framework.
I’ve demonstrated how the daily inspect and adapt events are built into Scrum to enable and encourage responding to change. Additionally, I’ve shown that planning in Scrum is based on empirically based forecasts and are not cast in stone.
15. Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate.
Scrum assumes software is hard. It asks developers only to estimate and form forecasts. The assumption is that we are learning new things daily and that yesterday’s assumptions could be disproved today by inspecting and adapting.
Software is hard. It’s made hard because the problems’s we’re solving today with today’s technology will not be the problems we’re solving tomorrow with tomorrow’s technology. Scrum presents a lightweight framework within which you can develop and sustain complex product development. I hope Adam Ard will someday work at an organization that practices agility, believes in its concepts, and maybe even practices Scrum.