What is really essential?

Jens Meydam asked “What do you really care about in Scrum?” I decided to answer, instead, “What do you think is really essential in Scrum-style software development?

First, two things are fundamental:

  1. Ship running, tested software every two weeks, or, if you are a wuss, every month. (DONE == DONE)
  2. Reflect frequently on how it’s going, and revise your practices in accord with what you observe. (Inspect and Adapt)

Now then. When you set out to do these things, certain chains of events are inevitable and I do mean inevitable. Here’s one example:

  1. To ship done software, it must be tested.
  2. To ship done software every two weeks, it must be tested every two weeks.
  3. Changes to the software can, in principle and in practice, break essentially any feature anywhere in the software.
  4. To ship done software every two weeks, essentially every feature needs to be tested every two weeks.
  5. This testing burden increases linearly or worse than linearly with the number of features.
  6. Manual testing cannot sustain the two week delivery cycle.
  7. Therefore, for a truly successful iterative software project, automated testing is absolutely necessary.

There are quite a few things like this that are just inevitable. There are others that are almost always needed, others that are commonly needed, still others that are sometimes needed.

To call a process “Scrum”, we demand certain things. All of those things are pretty good ideas. Some of them may be necessary to a successful project, even if they are necessary in order to call the process Scrum. I’m more interested in successful projects than I am in the name of the process.

One Response to “What is really essential?”

MarcelloDuarte

December 23, 2009

12:14 pm

permalink

Hi Ron,

I guess if you think too much about what is essential to the Scrum you will end up thinking about what is essential to you project. That would be the natural course if we are using Scrum as a tool. It’s hard to just think about what defines Scrum, or to state what cannot be missed. The reason is that this thinking directs us to think in terms of satisfying the process instead of the project. I like the “ask the team + deliver often + inspect & adapt” trio. Your post seem to revolve around those elements too. At the end what matters is, like you say, delivering reliable software, isn’t it?

I find particular important to communicate what is essential to Scrum to teams that are doing some form of Scrum and need a reference to aim towards. Staying in the practice is often revealing of the principles and values. When the principles and values are second nature, then I am free to think only about the project.

Leave a Reply

You must be logged in to post a comment.

Recent Articles

Developer Quality! … and Certification?

Uncle Bob Martin comments on “Developer Certification WTF?” in a recent blog entry. Let’s talk a bit about developer quality, and some things that are being done about it.

Book Review: Shop Class as Soulcraft

Author Matthew B. Crawford is a physicist, has a Ph.D. in political philosophy, and is a motorcycle mechanic. What’s not to like? Recommended for practitioners, managers, executives.