A Scrum time capsule of 2008

A trip back memory lane from my first year using Scrum twelve years ago. At least all the cake was good!

Picture from https://www.rymdturism.se/

I was just about to press delete when my eye caught a glance of a document. The title was “One year’s worth of SCRUM retrospectives”. Curiously I opened the document and realized that the document was a collection of mistakes and lessons learned I had written from my first year using Scrum. A Scrum time capsule of 2008.

Both funny and shameful memories popped up as I read through the document. Sometimes I wished I had a “shame” pillow. You know the pillow you have when watching TV-shows so embarrassing you can’t stand it…where you have to put a pillow in your face…

The bad

For example, when we had prepared user stories for a sprint. The Product Owner walks into the room, looks at the user stories written on post-its on the table, and throws them all in the trash bin. He turns to us and says that this was not at all what he wanted. Imagine our shock. We had spent so much time preparing these user stories in advance. Not to mention time on the architecture. That taught us a lesson.

Or the problem we had with story points. We spent an insane amount of time trying to figure it out. We really made it much more complicated than needed. We loved making it really complex. I still laugh about this. We debated endlessly if we should change the estimates for a story during a sprint.

For example, if a three-point story turned out to be a five-point story. Should we change it during the sprint? If so, how should we handle the burndown? Changing the estimate would ruin the ideal line!!! In the end, we decided to use story points relatively. That is when adjusting, thinking more in percentage done. In hindsight, our mistake was that we based story points on ideal days. That made us conceptually believe that each day we should deduct one point from a story.

We had a fine for coming late to our daily scrums. If anyone was even a second late you had to put a dollar in a can. We used this money to buy cakes for our retrospectives. I remember explaining this rule to a new product owner. He looked at me, took up his wallet, and put 30 dollars in the can. Then he smiled at me. I was annoyed but the team was thrilled. That was a lot of cake.

The good

Some of the discoveries from my first year using Scrum are still relevant and still useful twelve years later.

A good discovery was to create mock-ups and establish a shared understanding. I still believe this is very powerful.

We also discovered that when running several scrum-teams at the same time it is beneficial to talk to other teams so we don’t create the same common components. For example, three different implementations of error handling.

We struggled with how to handle stories with new, uncertain technology and came up with the idea of using proof of concept. A spike, we later learned it was called.

We discovered sprint fatigue. That is that you need a break for a few days after running too many sprints.

The teams became self-organized. Every day after the daily one team sneaked away and had a new meeting. When I asked what the meeting was about they said they invented a 15-minute technical meeting discussing common components they all worked on. It was more efficient to meet once per day and discuss potential needs, dependencies or problems. The approach seemed to work very well. I cannot be sure as I was never invited. Maybe they were just eating cake without me!

We discovered that using technical language in a user story that no one else outside the team can understand is not very useful. We also learned that these stories never get priority. How can you prioritize something when you don’t even know what it is.

We discovered that user stories got stuck at testing. We added a column in our Kanban called “ready for test”. We implemented a rule that anything in that column must be tested within a day. We didn’t know about WIP-limits at that time but the approach worked. To get stories tested quickly we also had to change the entire approach on the complexity of test scripts. Making them simpler to report on. Also, sitting together doing testing with many people proved very useful. Mob-testing that is :)

The most important thing we learned

At the end of the document, I saw the following text

The final and perhaps most important lesson after one year is to do all the Scrum events and follow the principles. In every retrospective, tracing the problem back to the root cause was not doing the Scrum events or following Scrum principles. There is a lot of wisdom in Scrum. The wisdom that you might not be aware of until you break the rules and face the consequences.

I was proud. I realized there was no need for a “shame” pillow. We failed and made some funny mistakes. But that made us better.

Scrum has few events and rules. None of them work in isolation. Only when used together do you get the full benefit of Scrum.

Do you want to write for Serious Scrum or seriously discuss Scrum?

Twenty years plus of continuous professional expertise in the information technology sector working in the private sector and United Nations in Europe and Asia.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store