Alan Shalloway blogged on "Big Change Up Front", suggesting that it's not always the best thing to do. This made me think ...

Alan’s blog makes the point that processes like Scrum (everyone’s favorite whipping boy) require big changes right out of the blocks. Scrum asks you to have a ScrumMaster, whatever that is, and a Product Owner who can make decisions about what to do and what to defer, and a team with all the capability needed to produce a working increment of whatever they’re supposed to be building.

Now, to many of us, it’s hard to imagine how you could build the right thing without someone to decide what the right thing is, and how you could build the thing right without all the skills needed.1 Nonetheless, it’s true that many organizations can’t manage these things, and set off to do Scrum without an empowered Product Owner, and without everyone on the team that is actually needed. So it is surely fair to say that these changes are too big for at least some organizations.

Alan goes on to remind us that processes like Lean, and especially Kanban, start from wherever you are, and allow for incremental uptake of change. This is clearly easier, in the sense of less stressful. If an organization isn’t up for anything quite so horrific as having a ScrumMaster lurching about the office moaning “INSPECT … ADAPT …”, well, maybe they can at least put some cards on the wall and notice that most of their features are coming back ten or fourteen times before QA finds them to be acceptable. And, with luck, even figure out something to do about it.

It could happen: there are a lot of paths to improvement. This leads to another question:

What's Best?

Yes, well. Nothing is best. Or, maybe, whatever you’re willing to do is best. So if, say, Kanban is easier to swallow, maybe you should take some. Of course chocolate is easier to swallow than those horse pills that your doctor gave you, so maybe you should take chocolate instead. Let me know how that works out.

But Kanban isn’t bad for you, so it’s not quite so iffy as switching from Diovan to Dove Dark. If you’ll improve bit by bit with Kanban, and stumble and  fail with Scrum, then by all means, start rocking Kanban. But there is an issue:

It's a Long Way to Tip a Rarie

Many teams, perhaps even yours, are a long way from really being good. In particular, there are some ways of practicing that are generally very good ones. Let’s consider just one: have testers as part of your team, instead of separate.

Scrum, if you’re paying attention, demands this: you need to have all the capability needed to ship an increment of software on your team. If your organization has separate testing, Scrum demands that you fix it.2 Kanban, on the other hand, in that gentle way that it has, merely draws the picture and waits for you to work out, in your own good time, that maybe it would be a good idea to test the stuff before you kick it out the door, rather than after.

An optimist would assume3 that teams would notice this and figure it out. Someone actually paying attention would observe that organizations that will not create cross-functional teams make it essentially impossible to contemplate this solution, much less implement it. Kanban people pride themselves on not offering solutions. People are supposed to discover the solutions.4 (Remind you of Inspect and Adapt, anyone?)

But most teams are a long way from some of the well-known, likely good, solutions. They may improve a bit, yet never really prosper.

So I believe that we are faced with …

A Dilemma

If we ask a team to do Scrum–or, God save us, something actually hard, like XP–there is a chance that they will not take up these “big” changes, and will therefore founder and fall back into the pit.

If we ask them to do something easy, like Kanban, there is a chance–I think a good chance–that they’ll drift for a long time before adopting practices that help them really improve.

Now of course the Kanban people can point to teams they have kanbanned who have done really well. Woot! And Scrum people can point to very successful teams as well. The most productive team ever recorded happens to be a Scrum team. So what?

There probably is no best process for everyone. But the best start, for everyone, is probably to decide to improve, pick a way to start improving, and not to stop.

However ...

There are a lot of practices that are known to be widely applicable and helpful in addressing specific issues that come up for many teams. To list a few: Test-Driven Development; Retrospectives; Co-location; Close Contact with Customer; and so on. There are many.

Whether you jump in with all your feet to XP, or start with Scrum or some god awful distortion of it, or visualize your process with Ritz crackers on the wall, remember this: you don’t have to invent all the solutions to the issues you encounter, and you would do well not to. Observe what is out there, observe what people are saying, and choose powerful moves every time you move at all.

Alan raises an important starting question about Big Change Up Front. However big change up front or itty-bitty change up front isn’t the most important thing to me. Choosing the best moves we can manage, every day, that’s what I’m talking about.

  1. OK, I'll grant you, the need for a ScrumMaster isn't quite so obvious. But it's the other two that are more commonly left out.
  2. Of course you don't have to listen to Scrum when it demands stuff. Just don't come crying to me if you don't.
  3. Remember, though: when you ASSUME, you make an ass out of yourself.
  4. I will leave it to you to figure out what Kanban people must be, if they are not part of the solution ...