Scrum & Control

June 7, 2011

One myth about Agile is, “Those Agile guys are out of control!”

Of course, when one hears that, one must ask, what do you mean exactly?

For example, Scrum does reveal that the team is involved in a creative process, a process of identifying what the customer wants and how it will be implemented and with all the related trade-offs.

In our usual situations, this has some elements of chaos. It is only natural and normal that creation and inventiveness and ‘magic’ should have some chaos. It is the nature of the beast. It is not Scrum’s fault, although Scrum does reveal the chaos much more than Waterfall. Knowledge creation by definition has some element of chaos.

Some people think that waterfall (or their version of waterfall) gives them ‘more control’ than Scrum. I have only 20+ years experience in waterfall, and I certainly have not seen every situation, but my opinion based on a fair amount of experience is that Scrum gives managers far more control than waterfall. Not always do people use that control well.

Where?

First we must distinguish between real control and the illusion of control. Waterfall does provide an illusion of control. I am embarrassed to say this since I did waterfall for so long, but in Texas they have this phrase: ‘All hat and no cattle.’ I was that kind of project manager for too long. Lots of ‘pretend’ control, but no real control.

And we must remind managers immediately (and talk at more length than here) about the importance of the team self-managing itself. Especially in Scrum. (‘Whatever self-organizing means!’ you might say to yourself — but a topic for later.)

Where is the control?

Let me pick on three key cycles of control.

First, adaptive planning.

Everyone should now know what the Romans knew, which is: “To predict is difficult, particularly of the future.” Meaning, we know that the first estimate of ‘how long will it take’ is always ‘terrible.’ It is at best a SSWAG. I actually think that a decent Agile team with a known Velocity can make a far less bad up-front prediction of the delivery date than waterfall estimating ever did (we call it ‘release planning’). But let’s accept for argument’s sake that agile release planning up-front is no better than waterfall.

BUT… Agile re-estimates every Sprint based on known Velocity and based on all the learning by the team since then. (And, if it is a priority, the team focuses on learning that improves the estimate.) So, very early in the project (if we still call it that), the team always should have a far better estimate of ‘what’ and ‘how long’ and can enter into good cost-time-benefit conversations with the key stakeholders to ‘bring it in on time,’ as they say. (Time usually being the key variable.)

This provides much more control, with much better information. Never perfect, but much better.

This assumes that people are playing Scrum professionally, with some good talent and rigor and courage. Not always the case, for a variety of reasons. To be honest, sometimes it seems they make something up and call it ‘Scrum.’

Second, the working software.

The team has to deliver working software every Sprint. Any manager can walk into the Sprint Review — it does not take a rocket scientist or thousands of pages of lying reports or a highly-paid PMO to figure out that a team showing no working software (or working product, in another kind of effort) is not doing well.

There is no obfuscation. (Which is a fancy word for people trying to make things unclear. Which, you may recall, has actually happened at your friend’s shop.)

Now, managers must be reasonable in using this information. Sometimes the best teams make serious experiments. Any good scientist knows that most experiments fail. So, if they learned something useful from an experiment that failed, then let them continue, but if you are asking a great hockey team to play major league baseball, you might see a kind of failure that needs to be fixed. And, with Scrum, at the end of a Sprint you can see it and fix it.

The demo provides another kind of control. (The demo happens at the end of every Sprint, in the Sprint Review.)

Has it ever happened to you that the team did not understand perfectly what the customer wanted? OK, OK. Yes, that happens universally, and lots of laws of software development explain some of the reasons why.

If you believe as I do that ‘the bad news does not get better with age,’ then you can see that demos that enable feedback from good customers or customers representatives can provide more control. At least some of the bad news is no longer getting worse with age.

Third, the Daily Scrum.

Every day, each team member must answer the three questions to his or her other team members. This provides control in the form of motivation (positive and negative), focus (a key problem in our situations) and help with impediments.

The team is expected to make micro-adjustments to ‘land the plane more successfully’ by the end of the Sprint. (And some major adjustments, too, if needed.)

The biggest impediments should not go unidentified for very long. (Again, assuming we play with talent, professionalism and courage.)

These three things — adaptive release planning, Sprint demos of working product and Daily Scrums — are what give Scrum far more control than waterfall.

There are other things in Scrum that improve control, but those three things to me make the case.

Your thoughts?

Note: The image is borrowed from this page:
http://www.egos.esa.int/portal/egos-web/products/Simulators/Control_Center_Models/
At the European Space Agency.

« « Purpose of the Daily Scrum || Planning Poker – 1 » »

Posted in: Key problems, Scrum
Tagged: Tags: , , , , ,

One thought on “Scrum & Control”

  1. Jan Doggen

    Reading about adaptive planning reminds of my backup software and the way it calculates time remaining: frighteningly long during the first minute, then it gets better 😉

    ↓

Leave a Reply