PrologueWhy I came to Scrum

In 2008 I became CTO of a software company whose products took three years to build. Fourteen months later, we launched a product into a market it had never sold to. The method that made the difference was one I had resisted for most of my career.

I trained as an electrical engineer, and I believed in thorough method: specify, plan, execute. My last project at IBM, the computerisation of the Alsace-Moselle land register, shook that belief. The client had spent two to three years writing a detailed specification, yet the real requirements only surfaced once people saw how the new system would change their work. No plan could have found them sooner.

In my first CTO role, in medical device software, the regulations of the time ruled Scrum out. The most I could do was get domain experts, architects and developers working together. In the next one, nothing stood in the way, and I replaced our plan-driven lifecycle with Scrum. We built the product in increments as the requirements emerged, the most valuable features first, and everyone could see where it stood. It was the 2008 financial crisis and the pressure was enormous, but it rested on the whole team rather than on a project manager's shoulders. Scrum kept its promises.

That is why it frustrates me to see what Scrum has become in so many companies: the ceremonies are all there, and the results are not. This article is about the difference.