There's too much context going around.

Martin Fowler has recently posted a note on Flaccid Scrum. Related posts such as Jim Shore’s The Decline and Fall of Agile have made similar points. Lots of discussion has ensued. The fundamental observation can be put this way:

There are a lot of Scrum teams out there who are not performing well.

Jeff Sutherland, co-inventor of Scrum, says he has never seen a Scrum team become hyper-productive without adopting the XP practices. Less elegantly, I have said that teaching Scrum teams how to get Done-Done is why I have such a lovely blue convertible.

In our justly famous “Nature of Software Development” talk and course, Chet Hendrickson and I show rather clearly why Agile is good for business. We also show how Agile demands that you solve certain problems that can only be solved in the XP way. The stories on my site about Kate Oneal make a similar point, from the viewpoint of someone who puts our advice into practice.

A recent thread on the XP list has described a team who are not using good technical practices, and who are falling further and further behind in “technical debt”. (“Technical Debt” is a polite phrase describing the situation of a team who are writing crappy code on a regular basis.)

Through Deep Snow, Uphill, Both Ways

From the beginning of XP and the other forms of Agile, we have been plagued with people reporting that they tried Agile and it didn’t work. It used to be my practice to ask them about a dozen questions, like

  1. Was your Whole Team together in one place?
  2. Tell us about your On Site Customer.
  3. Describe your Release Planning process.
  4. Tell us about your automated customer acceptance tests.

… and so on.

This approach was unpopular. People said that I was trying to find some aspect of XP that they didn’t do and then blame the failure on that. Well, not exactly, but on the other hand, hell yes.

If you don’t do what we suggest, then don’t call what you do by the name of what we suggest. Don’t call it XP if you don’t do the XP practices. Don’t call it Scrum if you don’t Inspect and Adapt, and while you’re at it, how about heeding the Jeff Sutherland hint up above?

XP and Scrum and Agile are not guaranteed to succeed, and they aren’t the only way to succeed. The only way to succeed – other perhaps than catching a really lucky break – is to build a team who work well together and who get things done. XP and Scrum are the best ways we know to work well together. They are not necessary – there might be other ways – and they are surely not sufficient – there are a million things we must do to be successful, and they’re not all written down in books.

You have to do right things, and you have to do things right, in order to succeed.

What right things, you irritable curmudgeon?

Let’s take a simple example from the “Nature” talk. We begin that talk by showing why the business people need to see real software getting done, on a regular basis. We’ll skip that derivation for now.

Given that you’re going to ship software from the beginning to the end of the project, it is clear that you need to

  • start with a simple design, because at the beginning, you won't have enough of a design to support all the software;
  • have a more and more robust design as the project goes on, because you can't make progress with insufficient design;
  • wind up with a fully robust design, capable of supporting the whole project and its future needs.

There is no choice. You must evolve your design. You must improve the design of existing code.

Guess what!?!? That’s the subtitle of Martin Fowler’s book, Refactoring.

In order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.

There are many more practices, generally outlined in XP and elsewhere, that are just as essential as this one. There really is no choice. If you want to succeed, you’ve just gotta do them.

Situational Ethics

As XP / Agile / Scrum have become more popular, many teams and individuals have wanted to do them, or “be” them. This has led to a school of Agile methods that wants to be called “context dependent”. The idea is that whatever brand of Agile is under discussion is “too rigid” and “doesn’t fit our context”. So we have to modify Agile because God knows we can’t modify our context.

Well, my dear little children, I’ve got bad news for you. It is your precious context that is holding you back. It is your C-level Executives and high-level managers who can’t delegate real responsibility and authority to their people. It is your product people who are too busy to explain what really needs to be done. It is your facilities people who can’t make a workspace fit to work in. It is your programmers who won’t learn the techniques necessary to succeed. It is your managers and product owners who keep increasing pressure until any focus on quality is driven out of the project.

There is an absolute minimum of practice that must be in place in order for Scrum or XP or any form of Agile to succeed. There are many other elements of practice that will need to be put in place. And yes, the context will matter … and most commonly, if you really want to be successful, it is the context that has to change.

Want to succeed at software? Then it can’t be business as usual. Study the material, do the practices, get help. Or get out of the way.