I’ve worked in successful waterfall projects, and failing ones. I’ve worked in successful agile projects, and failing ones. And when I had the chance to switch from waterfall to agile, it wasn’t because I was chasing a bright light, not caring if it was the headlight of an oncoming train, it was an experiment, to see if the obstacles I had seen in waterfall were fundamental to software engineering, or were a function of how the projects had been run.
I read about scrum, and I embraced it. It gave me structure, as I was used to, and I could introduce it slowly. It had patterns I could follow, ceremonies to perform, so I didn’t have to think about being agile, and I could sell it easily to my manager – don’t do meetings that way, do them this way. Don’t plan that way, plan this way.
And things didn’t go as smoothly as I hoped. We missed deadlines, our estimates were wrong, but at least we had more deadlines so we could reflect on why we missed them, and at least we had numbers so we could quantify the estimate errors, and correct for them. And so we thought about process, and we added ceremony, to make sure the mistakes we made weren’t made again.
We missed deadlines, our estimates were wrong.
We did daily stand-ups, we had retrospectives every 4 weeks as the sprint ended. And we were thorough. They took most of the day, they involved everyone, and copious notes were taken, and actions assigned.
And people were bored. We missed deadlines, our estimates were wrong.
We started using story points, because estimates weren’t working, we did planning poker to make sure everyone understood, and we tried to agree on what a Story Point meant. To nail it down, to quantify it. And we argued over it, and we spent a day planning.
And people were bored and frustrated. We missed deadlines, our estimates were wrong.
But we delivered on time, because we controlled the scope, and we extended our working hours.
And people were frustrated. And we wondered why our estimates were still wrong.
And we realised we didn’t need the daily stand-ups because we always talked. And we didn’t need the retrospectives because everyone was bored, and we could talk about the issues with the few developers who cared about the issues.
And we had more time to deliver story points. And we controlled the scope. And we talked. And we delivered. We got better at meeting deadlines. We got better at estimating.
And then I was told we weren’t agile. I was asked where our ceremonies were.
And I realised, it’s not about the ceremony. It’s about the principles. The ceremonies are the scaffolding that help the principles to develop. If you have a new team, or a distributed team, that don’t talk every day, a daily stand-up is a good scaffold for communication.
If you don’t have a good feedback mechanism, and the team have trouble trusting, a retrospective, and many of the anonymous feedback mechanisms, are a good way to get the issues out in the open, so that they can be addressed. If the team trusts each other to talk, and to address the issues, just have your retrospective in real time, with the people affected.
Understand why the ceremony exists. Use it to support the principles, not to curtail them. If it doesn’t work, drop it. Be agile. Don’t stick to scrum.