I had a privilege to be a scrum master in 2019 for a few months. It was my first time as a scrum master and I was excited about it. But like usual, as a rookie (scrum master), all didn’t go well but there were also good points. In my mind, I thought that I can do it better, and someday I want to try it again! That day came in February 2020 when my boss called me that she and the customer wanted me to be a scrum master for a new team. Immediately I said yes; now is the chance to show that I can do better and we won’t to same mistakes that were done in 2019.
This blog post is a story about my second scrum master period in 2020 between February and September. I will go through what were the things I wanted to fix from my first try in 2019 and what we did to fix them. This is also a small story to my mind; what was I thinking as a (not rookie but quite junior) scrum master.
Three Principles
Before the project started I made three principles for myself and the team:
- We will work together, and one thing at the time,
- We should know our estimated completion date all the time, and react to delays early and
- We will focus on improvement and especially focus on retrospectives.
Pair / mob programming
In the 2019 project, there was one big issue: everyone had their specialty that they worked on and others didn’t know about it. This let to too much pressure on few team members when they didn’t go forward. We had a low bus factor. In 2019 I thought that if I get a new chance to be a scrum master again, this won’t happen anymore: everyone should be a generalist, “full-stack” developer.
In another team where I had been a developer, practically all of us had the specialty that we worked on: just like in the team in 2019 where I was a scrum master. Everything went ahead but most of our work didn’t finish. I realized that we were multi-tasking inside the team. If we would’ve concentrated on just few things, we would’ve got things done and finished something.
When planning for the new team at the beginning of 2020, pair programming came to my mind. I had read good things about it; maybe we should try it now. In the past I wanted to be in the comfort zone and code alone; even if I had read about the benefits of pair programming. I was afraid to show how I write code, to show unfinished code, the work in progress. Also, I was worried to tell others to pair program: what if they don’t even want to try it?
My worry was unnecessary: all members agreed to try pair programming. Mostly we did even mob programming with the whole team at the beginning. There were many benefits that we got from pair and mob programming:
- Everyone knew our codebase,
- We discussed a lot about our code,
- We shared a lot of different ideas,
- We learned new ways to use our tools,
- We got things done and
- We became a team, not just individual programmers.
Especially at the beginning, we did a lot of pair and mob programming which made us more like a team. It was especially important because we were distributed team: no one was co-located.
But there were drawbacks also. Pair and mob programming are quite stressful. Someone is always looking at you and you have to keep on talking (latter is sometimes difficult for Finns). You have to show your weak moments when you simply don’t have any ideas. We were now and then talking that pair and mob programming is a really good thing but enough is enough: we want some private coding time also. It would be best to find some balance between coding alone and in a group and have both during the week.
Pair and mob programming fulfilled my principle to work together and one (or just few) things at a time. At the beginning of the project I told the team:
Stop starting, start finishing.
This became one of our main rules in the team and we kept saying it every week. Although not all of us remembered it from the outside and it turned to “stop/start” or “start/stop” now and then. But everyone knew what it meant. You can read more about why multi-tasking is a bad thing from my earlier blog post The Evil of Multi-Tasking.
Estimate Continuously
The schedule was important for the customer in this project. It wasn’t a strict requirement but a strong wish. They wanted to publish the software in time. Before the project began my boss told me about this and I was worried about it. I promised her that I can’t promise to launch it by the deadline. But what I promised was that we will know early enough if we aren’t making the deadline.
I was a bit worried because during my whole career almost every estimate had been way too optimistic. I had tried it many times and every time I didn’t succeed with it. How can we this time make this succeed? I bought a book: Agile Estimating and Planning by Mike Cohn. It sounded quite good and I got many ideas from the book.
We had a list of features for our first version but we didn’t know how long it will take to implement those. I wanted us to have some rough estimation because we needed to know when we are not on the schedule. We used about half a day to go through the list and gave them t-shirt sizes: S, M, L, XL, and XXL. We didn’t care about how much is XL or how much more XXL is compared to XL. I wanted it to be simple at this point because at the beginning we can’t make much better estimates by using two times more time for estimating.
After we had all features “sized”, we just turned them to story points: S=5, M=8, L=13, XL=20, and XLL=40, and we got a sum, let’s say it was 500. Is it realistic to get 500 points done in the schedule? We looked at a couple of smaller features and estimated that 1 point could be one person day (7.5 hours), and calculated that then 500 points can be done by the deadline. Notice that this was a very early estimate and we really didn’t know if this estimate is even close to the reality. We only guessed that 1 point could be one person day, but it could’ve been much more (or even less). But at least we had some estimate to start with.
Then began the actual work, coding. In each sprint planning, we re-estimated those features we planned to implement in the sprint. Notice that we already had some rough estimates before the planning but now we looked more specifically to each feature. Usually, original (rough) estimates didn’t change, but there were also many whose story point estimates changed.
One thing that makes estimation of project or version difficult is unknown work or surprising work. By surprising work here I mean some feature that we don’t know at the beginning but at some point just realize that it is needed. We were lucky about these. There were some surprises but not many. And our customer, who was the product owner, was disciplined and didn’t take new features to the version loosely but just few and really important ones. Whenever there was a new must-have feature, we gave it a quick estimate, and it was immediately calculated to our estimated release date.
We estimated everything but didn’t count everything to our version that we used in the Jira version report. Technical tasks, like some refactorings, etc., were excluded from (Jira) version, only features were included to (Jira) version. Why? The reason was that features are easier to know beforehand than technical tasks. And we had many technical tasks that we simply couldn’t know beforehand; over 90% of them were not known at the beginning. While only about 5% of features were not known at the beginning. Our estimated release date would’ve been way too optimistic if we had included technical tasks to (Jira) version.
But now those hidden technical tasks were practically calculated to our estimated release date because they delayed features. On average there were the same amount of technical tasks between features during the whole version so practically technical tasks affected our velocity. Yes, there were moments when there were more technical tasks, and then also times without technical tasks. But on average they were evenly distributed during the version even if we didn’t know them beforehand.
Don’t misunderstand that we didn’t estimate technical tasks: we estimated them also. We just didn’t include them in (Jira) version. We included all features’/stories’ and technical tasks’ story points to our team velocity. That way we knew how much work we will be able to do in each sprint.
Key takeaways about estimation:
- Use story points: Why We Should Estimate with Story Points, Not Ideal Days?,
- Make draft estimation immediately,
- Re-estimate in sprint planning,
- Be strict with new features/stories after starting to work on the version,
- Include only features/stories to the (Jira) version and
- Exclude technical tasks from the (Jira) version.
Retrospectives – Most Important Scrum Meeting
Improving daily work is even more important than doing daily work.
Gene Kim in The Phoenix Project
This quote is something I repeat almost daily. Improving daily work is in the core of scrum as part of its workflow: sprint retrospective. It is maybe the most important meeting in the scrum (even if it is really difficult to put them in order; each of them has a really important mission). That is why I took it as one of our scrum team’s principles.
In each retrospective, I tried to have a theme that we will discuss. What should scrum master improve was one theme, and improving our daily scrum was another. Few times I had a predefined theme but I had to change it because at the initial discussion a more important topic emerged. It was pair programming that bothered the team, and I switched the theme to it on one retrospective.
I aimed to have one “daily work improvement task” as an output from each retrospective and then measure how it affected our work. This was easier said than done. In many retrospectives, it was difficult to take only one improvement task because there were many really good ones I didn’t want to dismiss. And in some retrospectives, we couldn’t get any improvement task. The reason was that we had had an only really good conversation but couldn’t make it as a concrete task within our retrospective’s timebox.
What I couldn’t achieve at all was to measure the impact of “daily work improvement tasks”. This was just too difficult for me. In theory, it could have been measured from story points achieved. If we achieved more story points than in the previous sprint, then it was a good change in our daily work. And vice versa for negative impact. But in my opinion, it is not that simple because there is variation in each sprint. I couldn’t be sure was it just a variation or did the task have a positive/negative impact. I am sure without retrospectives we wouldn’t have achieved that many story points and get features done, but I don’t know what was their actual impact.
If someday in the future I get the third opportunity to be a scrum master I will focus on improving sprint retrospectives. How to measure their impact on daily work. How to get a concrete task for the sprint to improve daily work. Etc. I have to admit that this time I didn’t succeed with this principle, and next time I want to do it better.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Manifesto
Conclusion
My very first experience as a scrum master was in 2019 (from May to September). When that ended I knew that I can do better, and I wanted to have another chance to try to improve on the mistakes I made that time. Luckily I got another adventure as a scrum master in 2020 (from February to September), and I was able to improve a lot and learn from mistakes I made in 2019 as a rookie scrum master. This blog post was about those improvements that I wanted to do, and most of them were achieved in 2020.
First thing was to work as a team, not as individuals. We didn’t assign tasks in the sprint planning, and mostly we worked as pairs or small groups by pair/mob programming. That made us more like a team, and not a collection of independent programmers. We really did a lot of teamwork and we got things done. In my future projects, I will promote pair/mob programming.
Estimation succeeded in this project far beyond my expectations. Practically I had never been able to make estimations that would have been correct; they mostly exceeded. But I studied about it from the excellent Agile Estimating and Planning by Mike Cohn. And we succeeded in it. We could react early to too many features and was able to reduce less important features together with the customer. In the end, we were on schedule.
Improving daily work and investing in sprint retrospectives didn’t go as I had planned. Sure we did improve, but there was left many things I couldn’t make happen. For example, to measure the impact of the improvements on daily work. This will be one thing that I will study more if I will be a scrum master for the third time.
Lassi Autio's Software Development Blog 