The Art and Practice of Agile

I went to a Sprint demo today. I usually avoid all things agile but today I made a mistake and arrived in the office too early. Thus I was unable to avoid the meeting by pretending I was late or I hadn’t got a reminder. So I had to attend the damn demo. Sucked to be me, or so I thought.

For once, it was worth going to. The first announcement was that they had completed “sixty-two story points” in the Sprint. Although such a figure is entirely without meaning, they were nevertheless congratulated on this “achievement” by the teleconferenced-in development manager, who, due mainly to his poor judgement of lighting and camera angles, looked like Bruce Willis. Not the man Bruce Willis, but the actor Bruce Willis playing the role of a man dazed and disoriented after having been badly beaten up.

The demo was short. It was scheduled for three, long-ass, interminably boring hours, but it only lasted 45 minutes thank God. That’s mainly because the only thing they had to “demo” was a comprehensive document they’d written. They had written some software too, mind. In fact, maybe as many as fifty impressive story points of software dedicated to changing the internal state of bought-in hardware. But it wasn’t working so they didn’t demo it.

“Working software over comprehensive documentation”

But it didn’t matter, because at the start of the sprint the SPL and PO had been called to a meeting with the hardware vendor. The vendor had explained to the PO that their hardware doesn’t work like that and the SPL doesn’t need to develop code to change its state. There are API calls built-in that should be used instead. However, the SPL announced, it was decided to go-ahead with the development as planned so as not to disrupt the sprint but the code developed would not be included in the final product.

Both the PO and the SPL, who on this project are the same person, agreed that the goal of completing at least sixty story points in the sprint was more important than what does and does not get included in the final product. Accordingly it was considered better not to disrupt the plan by removing or adding stories.

“Responding to change over following a plan”

The scrum master explained that the low values on this sprint’s anonymously-compiled happiness index were due mainly to developers who felt demotivated working on software that they knew would never be included in the product and would be scrapped as soon as they had finished developing it.

“Individuals and interactions over processes and tools”

In the world of Agile, it is the individuals themselves who are tools.