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.
Craig Nicol 
5 replies on “Scrum: standing on ceremony”
Good post and succint summary.
I believe most of the issues (if you could call them that) at the beginning were caused by lack of experience of using agile. The story points issue was a good example. The debate that raged over what a story point was and what it was best used as took a while to resolve.
Estimates are always going to wrong. An estimate is only a best guess. In the beginning when the domain knowledge isn’t as solid and the developer isn’t as familiar with the subject. The developer / planner can be some way off. As experience and familiarity builds then estimates get better. Estimates can also be set back by other variables like an addition to the use case (but that could be a case for removing it from the planning board).
Deadlines, maybe we made a rod for our backs by setting a finite limit on the number of story points per sprint and not looking at the amount of story points completed at the end of sprint as a guideline for the next. This is possibly a factor on why we never delivered the amount of features that we wanted to, in the beginning.
Retrospectives and planning, I think it was a case of two many cooks, everyone was there and that made it difficult to cover everything in the time allowed. As soon as the number were brought down and became more focused, it became better.
I believe the key thing is that we learned from each wrong turn from story points to planning. The agile process allowed us a certain flexibility to make changes, improve as we went, and use what worked for us. We are still learning and we still aren’t perfect but that’s a good thing, right?
I enjoyed the ceremonies, the changes and the debates. It kept things interesting and pulled us together as a team. 😀
LikeLiked by 2 people
Thanks for sharing, always good to hear how others saw it.
Definitely agree that always learning is good, and the ceremony had its place to bootstrap the team but I think most of the ceremony we started with has outlived its usefulness.
LikeLike
I think the biggest factor we had with the finite limit on story points was that the limit didn’t properly take rollover into account.
LikeLike
Yes! Agile is about principles, scrum is about ceremonies and how to do stuff.
I like your point about estimates. They are indeed pretty much always wrong, but it might not be that much of a problem because:
– as the team works together, their ability to estimate in a more relevant way wiml increase, and the delta vs actuals will become smaller
– after a few sprints, irrespective of the estimates being right or wrong, we have a decent idea of how many points the team can deliver in a sprint – kind of a benchmark, whis is useful to assess whether the high level full backlog is in line with the resources available.
A major problem I find where I work (and I assume in 99%) of organisations is that projects are delivered in an Agile way, but the funding of those projects is not agile at all : in order to obtain funding, we need to commit on a final product, based on estimated resources for the full project. This puts a major pressure on the delivery in terms of storypointing because we are biaised ahead in order to fit it all in…
LikeLiked by 1 person
Definitely agree on the funding part. Every bid is for fixed price and fixed scope which means a lot of adjustment when work starts and we start scratching away at the surface.
LikeLike