Scrum is OK. Let’s get to work!

Alan Shalloway and I were tweeting about whether Scrum could be improved because it doesn’t include some damn thing or other. Scrum is working as designed. We and the Alliance need to get to work.

Alan and I both believe that to be successful, teams need to know a lot of things. I tend to focus on “know how to program”, and he tends to focus on “know Lean”, but that’s our individual focus. Teams need to know many things, and do many things, in order to succeed.

Alan seems to believe that Scrum isn’t as good as it could be because it does not call out key practices that he believes nearly all teams will in fact need. I agree that Scrum does not call out key practices that nearly all teams will in fact need.

I think Scrum is just fine without including more practices.

Inclusive Processes vs Minimal Processes

When someone defines a method or framework for doing something — software development in this case — there is tension between describing everything users need to know, and describing some kind of safe “core” process that will get them going and able to improve. You can be inclusive, or you can try for a small process, minimizing what you put into it, but including enough to be useful and safe.

The Software Engineering Institute (SEI) and Project Management Institute (PMI) seem to have chosen to list everything that could possibly be needed. Their processes are inclusive. The Agile methods, as they were originally contemplated, were aimed in the other direction. They were intentionally small, light on their feet. They relied on a strong belief in the people doing the work.  We believed that putting developers and business people together, letting them self-organize around the work, gave the best results.

The various method creators took somewhat different approaches to creating these small near-minimal methods.

Alistair Cockburn (pronounced “Co-burn”, in the Scottish fashion) created a family of methods, ranging from incredibly simple to fairly elaborate, based on the size and risk of the project. His method Crystal Clear is almost fairly described as “Come together in peace, love, and understanding; ship software every month; think about it.”  Crystal Clear is the simplest Agile method that could possibly work, in my opinion.

Kent Beck was more focused on developers at the time of the Manifesto. He once said that he wanted to make the world safe for programmers. Kent is a master craftsman in software development, and his method, Extreme Programming, shows it. XP has an outer planning and development cycle much like Crystal Clear or Scrum, and it includes a number of technical practices such as TDD, Refactoring, and so on.

Scrum, which predates both XP and Crystal, focuses primarily on the outer loop. Scrum calls for planning, building an increment of software, demonstrating it, looking back at what happened, and repeatedly improving the process. Scrum also calls for some specific meetings, some specific rituals,  and even a couple of artifacts, the burn-down charts.

Teams Do Need More Than What is in the Box

All of these methods rely on the general knowledge of the team to see and make improvements as time goes on. Obviously, a team with very limited general knowledge may not do as well as a team with great knowledge. (This is not guaranteed: I have seen some brilliant teams go down the sewer. Project success is not just a matter of knowledge.)

Nonetheless, a team that is aware of some idea — “Hey, let’s test our code before we give it to users!” — is likely to be more successful than a team who just code and ship. Similarly, a team that knows how to visualize its work flow has a leg up on a team that just can’t figure out why nothing is getting done. And so on. Knowing stuff is good.

Now it turns out that Scrum teams get into trouble a lot. (All teams get into trouble a lot, and as far as I know, Scrum teams may get into less trouble than random teams, but they do get into plenty of trouble.) When they do get into trouble, or just don’t go as well as they’d like, everyone who coaches them, including Alan and me, finds that they would do better if they knew better, but they do not know better. So we show them a technique, or show them how to learn something they need to know, and voila! they are unblocked and move forward. At least until the next block.

It seems to an XP guy like me that Scrum teams would do better if they would just start with the XP practices right away. It probably seems to a guy like Alan that Scrum teams would do better if they would just learn and apply some principles from Lean and Kanban right away.

And we are almost certainly right: they would do better.

Teams Need More and the Process is NOT Insufficient

Alan seems to think that Scrum is insufficient in many situations, because it doesn’t come right out and tell people to do the things he believes are commonly necessary. I believe, with him, that there are things that are commonly necessary, and very likely we even agree on what some of them are.

But I do not agree that Scrum is insufficient. Most team’s actual practices, however, are insufficient. Scrum’s purpose is not to be sufficient: it is to set the team into an improvement loop whereby they try to build software, observe what is wrong, and fix it. Scrum’s generous assumption is that people, seeing things are wrong, are smart enough to work out what to do. Quite commonly, they are smart enough, and generally Scrum teams produce results better than they did before Scrum.

Also quite commonly, they do not produce results as good as the experts know to be possible. The reason for this is always that they do wrong things, they do things wrong, and they don’t do some things that they should. And, somehow, they don’t manage to figure out what needs to change.

Alan would prefer that Scrum include more things that people are likely to need. To me, that is like saying that we should redefine the Corvette to have dual rear wheels for better hauling. The Corvette is what it is: deal with it.  Scrum is defined as it is, by thoughtful people who have a certain set of assumptions about how things should work. It works pretty well, it has a commanding market share, and it means what it means.

Do teams need more than is defined in the handful of pages it takes to define Scrum? Hell yes! They need a lot more. Do they need to learn things they don’t know? Hell, yes! Should they pay people like Alan and me lots of money to help them? Damn betcha!

Should Scrum change to list those things? I don’t think so. Scrum has a pleasing near-elegance, and done with attention, works nicely to highlight what you need to know. I’m good with that.

The Scrum Alliance Should Help

On the other hand, should the Scrum Alliance change? I think so! The avowed purpose of the Scrum Alliance is to “transform the world of work”. This is not unlike the vision we all had at the time of the Agile Manifesto: to make a real difference to the success of projects and the happiness of the people working on them.

The Scrum Alliance has done a fantastic job of getting people started down the long path to the things all Agilists value. (You may not like that they did it with a near-meaningless certification, but the fact remains they have greatly increased the pool of people getting benefits from the ideas of the Manifesto authors and all those who have come after.) And, by the way, they have created a huge market for those of us who help teams move forward. Thanks, Scrum Alliance.

But now the Scrum Alliance needs to turn its attention more to transforming the world of work. To do that, they need to do a better job of reminding people that Scrum is the beginning of the path, not the end. They need to point to the ideas, like Lean, Kanban, XP, that are so valuable to so many projects. They need to recognize the individuals, like Alan, Mike, Dave, Bob, Eric, even Ron and Chet, who are out there helping Scrum teams to succeed.

To me, Scrum is a good enough start at doing projects well. We need to be sure people realize it is the first step. There’s no need for it to be the last step: that’s not what it was designed to be.

Scrum is just fine. Now let’s get to work helping projects. That’s where the action is.

Recent Articles

Emergent Design

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

XProgNew – Pivot?

Experience with Sinatra, and some thinking, cause us to look at a shift in approach. Martin Fowler was probably right.