What Does Scrum Say About...?

I've been reading Agile forums and there have been a couple of "What does Scrum say about.." questions and I thought that this would be a good topic to discuss with my opinions.

The questions were "What does Scrum say about SRS (Software Requirement Specifications) documents?" and "What does Scrum say about unplanned work?"

To put it simply... absolutely nothing!

Scrum at its core, as I understand it, is a basic process (a framework you can build upon) for a work feedback loop. It is not specific to software development, although I acknowledge that it's roots are from there, but in its current form, it has nothing to do with software.

What is a feedback loop? It is one where a portion of the output feeds back into and controls the input.

If you put a microphone close to a speaker where its feed comes out of, you will soon hear what happens in a feedback loop.

So what is a work feedback loop? It is one in which the results of the work feed back into the next lot of work. In Scrum, this is done through the Retrospective. Some of the lessons for the previous sprint feed back into the next sprint in the form of an action item and leanings. You also have mini feedback loops through the daily Scrum where the work from the previous day determines the work for the next day, depending on the achievements towards the goal.

The thing is, with feedback loops, the sooner you get the output directing the input, the better you can make adjustments. Think of your thermostat. If it increases the temperature, but it takes half an hour before it registers the temperature, well, things are going to get quite warm. Then when it cools down, things are going to get quite cool before the heater kicks in again. The same with work. If you can get that feedback loop in such a way that you can make adjustments to see if the decisions originally made on what to work on, then you can get those leanings faster, and adjust future decisions accordingly. If on the other hand, you do not have a feedback loop, even though you get stuff done, you don't know the effects. You could happily be working towards going off a cliff, or climb to new heights. but you won't know until you get there, which, in either case, is too late.

In Scrum, the feedback loop is used to work towards getting better. You make adjustments towards better quality, towards being better. Scrum itself doesn't make you better, or provide a better process — but it helps you make adjustments through the feedback loop towards that better process.

So, going back to the original questions, and others similar — what does this have to do with them?

Well, you have to ask yourself, does the thing you are asking advice on, whether its software requirements or handling unplanned work, help you get that feedback loop working quicker? Does it help you get better quality?

In the case of Software Requirements — well, you spend a lot of time writing them. Weeks, months. Does it help you get feedback on those requirements quickly to determine if the requirements are right in the first place?

In the case of Unplanned work, does it help or hinder the work you're already working on, on getting feedback on that?

In other words, is unplanned work good or bad? I tend to think it is bad because it interrupts, which causes context switching, which causes things to slow down — but I understand that unplanned work occurs. So, what I do is try to find out the causes of unplanned work, this is the feedback part. Then try to find ways of either eliminating the cause of that unplanned work — for example, defects, or finding ways to get more notice of that unplanned work. Sometimes, the unplanned work has been in discussion for a while — you just get notified about it at the last minute.

I see the goal of Agile not to be faster, cheaper, and all that. Its goal is to increase quality, while increasing the feedback to make adjustments to increase quality. Being faster and cheaper is just a happy, unintended side effect.