Summary

My premises here will be controversial. Let me assure you that I am more than half serious about these things:

Scrum is not an agile software development framework;
Scrum is not a software development framework at all;
The Scrum community is not serious about software development.

First, let’s take a quick look at what Agile Software Development is. Then, to make a decent case for these premises, we need to look at what kinds of things are done with Scrum, the reasons for adopting Scrum, what Scrum does well, what Scrum leaves out, what needs to be done, and what Scrum-the-community is doing about it.

Why was Agile Software Development created?

Agile Software Development came about in reaction to some problems that its creators had observed, and in response to some ways of building software that they had found to be productive. There was a reaction to increasingly heavy and complex “processes” for building software, in contrast to the much simpler, more human, and more humane approaches that the Authors had been following.

Agile Software Development is defined by a set of values and principles. The Authors did not specify any actual practices or techniques as part of Agile Software Development, although of course every one of us had favorite approaches that were consistent with those values and principles. In the end, though, Agile Software Development isn’t a process. It isn’t a method. It isn’t even a framework.

We’re here to talk about frameworks, in particular the Scrum framework, and one thing to keep in mind is that any framework, including Scrum, can be applied in accord with the values and principles of the Manifesto, or in conflict with them. No framework, no method, is inherently “Agile”. Some make it easier to work in accord with the Manifesto, and some make it quite difficult.

TL;DR

Let’s TL;DR this article and then drill down.

Scrum can be and is used for production of any product, and can be used fairly effectively for organizing even non-product activities. However, Scrum today is primarily used in software development efforts, and that is the main concern here.
People adopt Scrum for many reasons, but a very common one is that they’re not getting enough done using whatever approach they’re currently using. They want to get more done. Scrum is often pushed as a way to get more done.
Scrum–if you’ll only take its advice–is a very good starting point for getting more done. It can immediately reduce hand-off delays inside development, and decision delays before and after the development part of the product cycle. Scrum usually immediately reduces “work in process”, which can profoundly reduce delays in production. Scrum also calls for a continuing focus on product improvement and process improvement.
Scrum does call for producing a “Product Increment”, a complete, integrated, tested, working version of the product, ready to ship, every couple of weeks. However–and this is very important–Scrum itself gives absolutely no guidance on how to produce the Increment.
The Increment is critical to the proper operation of Scrum. It changes the questions and concerns of the stakeholders, and focuses everyone on delivering something of value. It changes software development from a business of prediction to one of observation and improvement.
Developers are neither born nor raised to know how to produce a working Increment of software every two weeks. Doing so is counter to almost all software education, and counter to almost all experience prior to encountering Scrum or XP. In short, developers quite often do not know how to produce the Increment.
Without the increment, the central component of a Scrum-based effort cannot thrive. Other delays in the process may well be removed, but the central loop does not run. The conversation between business and development does not change. Trust is not created. Rapid adaptation is not possible. True agility is not possible. What could have been a productive and happy collaborative working relationship too often turns to one of distrust, pressure, and control.
While there have been, and continue to be efforts in the Scrum community to address development concerns, they have come to almost nothing. There are individuals trying to help, but there is essentially no joint community focus, no joint application of money and people to solve the problem.
The Scrum community as a whole waves this concern away. There are systemic reasons why they’d do this. Most of the community do not have the technical ability to help. The money that pays them comes from managers, and is rarely invested in development training. The education needed is extensive, costly, and needs to take place over time. All these things add up to minimal progress on this very central need.

Then, if we’re lucky, we’ll have a thrilling conclusion. More likely, we’ll have some questions, some suggestions, and some wishes.

Why do people adopt Scrum?

People adopt Scrum for some reason or reasons. What are the most common reasons? Generalizing a bit, I’d say the problem usually is “We’re not getting enough done”. There certainly could be other reasons, such as “We’re too disorganized”, but I think not getting enough done is the big item.

Scrum’s co-inventor, Jeff Sutherland, has always addressed this notion with his approaches, including his notion of “hyperproductivity”, a 400% or more improvement in productivity, right down to his latest book “Twice the work in half the time”.

Now, it’s only fair to say that the Scrum Guide and the Scrum Alliance offer a different description of what Scrum is, not aimed quite at “getting enough done”.

The Scrum Alliance says:

Scrum is a simple yet incredibly powerful set of principles and practices that helps teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change.

while the Scrum Guide, and scrum.org says:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Nonetheless, I think that “not getting enough done” is at least one primary reason why people try to adopt Scrum, and it’s central to what follows.

Problems in getting things done

To look at how Scrum addresses the big concern, “We’re not getting enough done”, let’s first consider some of the primary reasons why enough may not be getting done.

Programming takes too long

One common belief, of course, is that programming takes too long. Some causes of this are obvious: sometimes the software is initially full of defects, and it takes a long time to get enough of them out. It also often seems like it takes too long from when we ask for it until we even get that first version full of defects. If we look at the bigger picture, however, we quickly see reasons outside development contributing heavily to “it takes too long”.

Divided development

All too often, we’re organized around specialties, at least development vs testing, and commonly we find other important specialties broken out. User interface people, database people, network people, infrastructure people, may all be in separate groups. When our team needs to build what seems to you like a simple feature, we have to coordinate our needs with those other teams. We have to submit our request to UX and wait until they send us a wireframe. Or we can guess at what we’ll need and submit a request to Infrastructure to give us some help on some new functions we think we’ll need. We’ll need some database changes, so let’s get on their queue. And so on. A simple feature requiring a few days of actual work often stretches out to weeks or months as we wait for, and coordinate with, the outside departments.

Then, we submit the code to testing, and when they get around to it, they’ll tell us what the defects are and we’ll get to fixing them … as soon as we can get back to that product, because we do have other things going on.

Too much going on

Very often, the organization is trying to do too many things at once. Doing multiple things at once can be OK if you have separate sub-organizations doing them. There’s nothing wrong with having Product A and Product B in development, as long as you have separate teams working on them. But as soon as you try to push both A and B through a single team, you slow down by at least half! Seriously! If it’s going to take me a month of work to do that feature you want for A, and you want me working half time on B, then it’s going to take two months for that feature, and that doesn’t even count the time it costs to switch back and forth. (That time is estimated as high as 30% by some experts.)

Long feedback cycles

Very often, it takes too long to find out if what we’ve done is what was needed. This effect is often compounded. First, things take too long in general. Second, we’re working on two or ten things, so it takes two or twenty times longer to get anything done. Third, when something does get done, it takes the organization a long time to get around to looking at it to see if it’s needed. Fourth, often we can’t release it to users just now, so we want longer. This effect can easily extend the feedback for something that took a week to do out into many weeks or many months.

Long decision cycles

Often, getting a decision on what to do next takes weeks or months. We may have to wait until the next time the Product Planning Group gets together, sometime next quarter. And their agenda is tight, let’s hope there’s time to discuss your product. Meanwhile, work on those other nine things we gave you to do. Carry on, there’s a good lad.

Delayed answers to questions

The Product Planning Group’s semi-annual meetings aren’t even the biggest problem. Often teams can’t get answers back from whoever’s in charge of their product for days or weeks. Hey, the Product Manager is busy visiting irate clients and has no time to answer your question. Put it in the queue, they’ll get to it when they can. Meanwhile, take your best guess and carry on, there’s a good lad.

Enter Scrum

Wow, no wonder we thought we weren’t getting enough done. Let’s get going with Scrum right away!

The good news is, Scrum, were we to actually do it, starts right out resolving many of the issues above, and highlighting others.

Cross-functional team

Scrum demands that we have a cross-functional team, entirely capable of building the product you need. We may not have actually done that, but if we did, all those delays due to waiting for UX, waiting for Database, waiting for Infrastructure, waiting for Testing, all those delays would go away!

Before we move to the next obstacle, bask in that for a moment. If we would just provide a cross-functional team like Scrum says to do, we would substantially reduce the delay in getting things done. Scrum absolutely delivers on the promise to get more work done in less time. It really does, if only we’d follow its advice.

Product Owner

Scrum demands that the team have an empowered “Product Owner”, who has responsibility for maximizing the value of the team’s work. They do that by using their authority to decide what the team will work on next, and what will be deferred until another day, or never done at all.

No more waiting for the Product Planning Group’s annual meeting. No more waiting for our Product Manager to come back from placating clients in Alaska. We have a dedicated Product Owner who can decide things right now, and who can ship the product whenever they want to.

Scrum even addresses the problem of teams having too many projects, although it’s a bit indirect. The Product Owner, if they’re actually focused on a product, has the incentive and the authority to keep other work away from the team.

All those delays in getting decisions made and getting the product out are resolved by having a real Product Owner. Scrum delivers more work in less time, if only we’d follow its advice.

The Increment

Scrum also demands the “Product Increment”. Literally every week or two, the Scrum team is supposed to deliver an integrated, working, tested version of the product, reflecting all the work done to date (at the direction of the Product Owner). Every week or two, the whole team sits down with all the interested stakeholders, performing the “Sprint Review. The team shows the product, and collects stakeholder feedback on what should be done next.

This review provides two almost-magical results. First, it ensures that the Product Owner is always on top of the changing views and needs of the stakeholders, helping to ensure that the team’s work has maximum value to the stakeholders. Second, it ensures that the stakeholders are always fully apprised of the state of the product. Nor more fear and wondering: they actually know what’s going on.

There is, however, a serious concern. For this to work, the team has to actually produce a running, tested, integrated version of the product. Not a status report, not a Powerpoint™ presentation, but a real live running product.

This is not easy to do, and it quickly becomes the primary “Cork in the [Orifice] of Progress” for many Scrum teams. This difficulty is the real subject of this article and the reason for the premise: “Scrum is not an Agile Software Development framework”.

Scrum really can help!

“Everyone knows” that software development doesn’t go well enough. There are many theories and many solutions, of course. One of the most important theories for how to make things better is the Agile Manifesto, which has blossomed–if that’s the word–into the “Agile movement”.

Among the solutions, the preeminent one is surely Scrum. The Scrum framework is a very good starting approach, because its definition directly addresses some of the most common and important causes of problems in software development. Scrum addresses common problems in the value stream in these main ways: it asks for a cross-functional team, which reduces delays in production due to handoffs, and it asks for a responsible business-side “product owner”, which reduces delays in decision-making while improving communication. In addition, Scrum adds a truly new role, the ScrumMaster, with the intention of ensuring that Scrum is used well, and is well understood.

These are all good things. While Scrum’s starting position is not ideal, the framework generally works to optimize some aspects that almost always need improvement.

It doesn’t stop there. Scrum focuses on short and concrete feedback, with an emphasis on improving the product, via the Sprint Review, and on improving the process of creating the product, via the Sprint Retrospective. If you were to start with Scrum and do what it advises, you’d surely identify the things in your way, and resolve them.

Yes, well. When that works, it works. I believe that, almost always, businesses see notable improvement from using Scrum.Still too often, however, it doesn’t work as well as it could. You’d hope that “Scrum” would apply the process to itself and improve things so that it would work more often. Scrum, unfortunately, isn’t a thinking being, so it cannot do that. Many Scrum supporters do look at how things are going, and try to improve what happens. I’ll give two examples, one very positive and one much less so.

Management and Leadership

It’s important that everyone involved in the Scrum activities understands Scrum. If they don’t, their ability to help declines, and the danger that they’ll do harm increases. This is particularly true with management, because managing an Agile effort isn’t all that much like managing in the old style. Now, one of the ScrumMaster’s responsibility is to educate management, but that’s easier said than done. They’re not always qualified to educate management, and as employees, their attempts to educate “up” are often not welcome. The result has been that leadership has not been as helpful to Scrum efforts as one might hope.

The reaction to this fact has perhaps been a bit long in coming, but there is now a growing focus on “Agile Leadership”, with courses and coaching and all the works and pomps of Scrum-providing organizations like the Scrum Alliance and scrum.org. This is good.

Scrum rather quickly gets many of the available gains from limiting handoffs in development, reducing value stream decision delays, and improving communication between product deciders and product developers. Most of those improvements are built into the basics of Scrum.

Where these gains aren’t immediate, the problems often come from elements of the company not understanding Scrum and how to use it. Therefore, programs aimed at leadership and management will almost always improve things even more. (Arguably, even “scaling” approaches to “Agile” can provide these kinds of benefits.)

Even without much focus on “leadership”, Scrum provides great value. With added emphasis on leadership training, it provides even more. If you’re a company using Scrum even fairly well, you are likely to be satisfied. If you keep working at it, things will get even better.

You won’t be doing Agile Software Development

With all these benefits, there is too often one major gap. If your development teams are not producing a truly ready to ship Increment of running tested software after each and every Sprint, you’re leaving money on the table.

Even if producing the software was not the primary Cork when you started, it probably was a concern, and as you lean out other parts of the value stream, it will again become clear that the actual development cycle is a problem.

The true Agile way of resolving that problem is right there in the Agile Manifesto, in the references to “working software”:

Working software over comprehensive documentation

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

Tangible, working, truly shippable software changes the conversation between stakeholders and the developers. It allows–it outright demands–that they focus on getting it out there, in the hands of users, delivering and returning value.

Producing the Increment changes software delivery from something we can do a year from now, into something we can do next month or next week or today.

Producing the Increment requires changes to how teams build software, and those changes include continuous integration and continuous testing. These changes reduce defect injection rates profoundly: many truly Agile teams ship one or two defects per year, or less, instead of having backlogs of hundreds or thousands of defects saved up in their defect management tool.

Truly Agile teams ship software at very high reliability, so rapidly that the company often has to reorganize how it delivers to its users. Deployment can become the biggest obstacle to increasing value.

You can’t “just do it”

Despite these benefits, it’s very likely that a Scrum team is unable to produce a working Increment every Sprint, and thus very likely that their organization cannot gain those benefits.

The reason is simple: the things you have to do to produce a high-quality increment every couple of weeks are not taught in schools, they are not taught at most programming seminars, they are not in most books, they’re not in most videos, and they’re not in the experience of most developers.

These things are not incredibly difficult, though they do take learning and practice. The primary obstacle is just that developers don’t know the techniques, having never been taught them or seen them in action.

We’ll not go into detail here, but a short list of what developers need to know is this:

Test-First and Test-Driven techniques ensure that the code always does what it is intended to do.
Incremental design, with refactoring, ensures that features can be delivered, week-in and week-out, from the beginning to the end of the effort.
Customer-focused “Acceptance Tests” ensure clear understanding of what needs to be done, and what is done.
Continuous integration ensures that the product is ready to hand and ready to ship, all the time.
Pairing and mobbing techniques ensure that all the code gets all the best brains applied to it, and all the brains learn as rapidly as possible.

The better your team can do these things, the better they’ll be able to produce the Increment. That will improve your communication and it will help you get your product into the hands of your users in weeks rather than months and years.

This is truly Agile Software Development. Accept no substitutes.

Scrum does not tell you how to do this.

Let me repeat that. Scrum does not tell you how to do Agile Software Development.

That’s not a sin, not a mistake. It’s a fact and it’s done on purpose. Scrum was designed to be minimal. It was designed to apply to more than software development. It was designed to stand the test of time, in case some new way of building software came along.

By and large, to gain the ability to do Agile Software Development, a developer, or their company, must look beyond the Scrum community. Mind you, both the Scrum Alliance and scrum.org do offer courses in the techniques mentioned above. The courses I know about are good ones, but they barely scratch the surface. They are introductions to the concepts, providing enough experience to get a sense of what they are. Like everything important, gaining real skill takes time, practice, and benefits from more help.

And those courses are costly in time and money. The Scrum Alliance course requires five days of developer time, including Scrum overview and technical training. It costs upwards of $500 per day per developer, not counting the impact of travel and time away from work.

The impact of this on actual training results is profound.

In April 2018, there were over 628,000 Certified ScrumMasters. Since there are about a half a dozen people on a typical Scrum team, with one ScrumMaster, we can guess that there are over three million programmers who are working in a Scrum environment, needing to build an Increment every two weeks, needing real facility with the techniques of TDD, refactoring and so on.

How many Certified Scrum Developers are there? In April 2018, there were 13,761. That’s less than one half of one percent of the number needed. It’s only two percent of the number needed to have only one certified developer per Scrum team.

Let’s put that another way. The odds are 50 to 1 against a random Scrum team having even one certified developer. Fifty to one against.

But before we start casting blame, let’s do one more bit of math. To train three million developers at present rates would take over seven billion dollars and 57,000 person years. If we only train one per team, that’d only be a billion-and-a-half dollars and 12,000 person years.

(In case you’re wondering, there are estimated to be about 18 million software developers in the world.)

Your organization suffers

Without solid technical practices, development is slowed. In the end, the delivery of value to the organization and to the users is slowed. The organization isn’t getting the results that it should. It’s not doing as well as it could. Sooner or later, the original reason for going with Scrum, “we’re not going fast enough”, comes true. Scrum will have helped the organization remove the other important obstacles to progress, leaving this one.

Now it is quite likely that things are better overall at this point, because better decisions are probably being made about what to build and what not to build, just because of the greater attention to limiting work in process that comes from having a dedicated business person at the wheel.

There is additional negative impact on the organization when development is not fully capable: the product will be inferior in important ways.

You have ten times the defects!

You will absolutely have more defects in the product than with developers with rich Agile Development skills. Agile Software Development includes a strong focus on testing, both at the code level and at to show that the product does what has been asked for. Teams with solid Agile coding skills commonly reduce defects by one or two orders of magnitude. Turning that around, without solid Agile programming skills on your team, you are experiencing ten times the defects.

You are going at one-third or one-half speed!

Naturally, you’ll fix those defects, at least the important ones. Writing and then fixing a defect always takes longer than doing it right the first time. Every time you fix a defect, you defer some other valuable change, and you continue to pay for a feature you should have already had right the first time. You are going slower, typically by thirty to fifty percent or more.

You are slowing down even more!

Solid Agile programming skills enable the team to keep the system design fresh. Since you are evolving the program over time, it’s necessary to improve the design in every Sprint. To the extent that the design falls behind, development slows down. To the extent that the design fails to match needs, work gets harder and defects increase. You are grinding inevitably to a halt.

You are losing control of your product!

When a team cannot reliably produce a running tested product increment, you have less ability to inspect and improve the product. You may likely stop holding Sprint Reviews, or hold them less frequently. Instead of relying on actually seeing the product, you begin to rely on status reports and numbers from the team. Your understanding of progress declines and you guide the product less and less well. The product’s focus and quality decline.

If you’ll think about the feedback and control loops available to you, and the ones you lose if the development isn’t producing frequent solid increments, you’ll see that I’m not making this up.

You have more defects, lower quality, slower delivery, and poorer control over your product than you deserve.

Your development team suffers

When teams don’t have all the skills they need, work slows down and becomes inferior. But the team suffers as well. The work becomes more tedious as they slog through code that needs improvement. It’s demoralizing to be creating too many defects, and to be spending time chasing them down.

True, in a sense they have brought this on themselves by not being more capable, but we all have to learn, and Agile programming skills do not come with the original package. True, they could learn on their own time, after going home drained from having been working hard in difficult conditions, and giving up time with their families or cats, but the buck doesn’t stop there.

These are your developers, and if they are not productive and happy, it isn’t just their problem. To the extent that it is their problem, they’re going to blame the job and look for a new one, or just buckle down and slog out their eight hours or more a day. Either way, that’s not good for you.

Your product is suffering, your people are suffering. Things are not going as well as they could go, because your people are in need of skills that they do not have and likely can’t get on their own time.

You’re doing better than you were, but your defects are still ten times what they should be, your speed is half what it could be, and your people aren’t as happy as they could be.

You’ve got a problem.

Solving the problem

It seems pretty clear that this problem isn’t going to be solved by teaching Scrum Alliance or scrum.org developer courses. One course isn’t enough and given the number of available instructors, we don’t have a few hundred years to do it anyway. Plus, much as I’d like to have a few million dollars of those fees, I don’t think anyone is going to pony up.