During our third quarter in 2018, I embarked on my journey of building a new cross-functional team for a greenfield project. Initially, when we first started, the team only consisted of a product manager and me, as the lead engineer. Fast forward a few months down the road and we had gained the support from two additional developers. The first engineer was working with us in our HQ in Berlin, while the second engineer was working remotely from South America, while his visa was being processed. At first, we didn’t really feel the need for having a specific process – we were using a Kanban board to prioritize and track progress on development. As the team continued to grow and our remote engineer relocated to our HQ in Berlin, we started having the feeling that we could be more productive. This is why we started testing scrum for our team. 

After having realized that there are more efficient ways to increase productivity and reflecting on the topic with fellow colleagues and our senior management, we decided to address this situation by changing our software development process. 

That being said, the main reasons for this change were:

• The anticipation of team growth
• Feeling that we could be more efficient
• No metrics for tracking team performance
• We were looking for a more efficient way of getting things done
• Mentoring available

Is Scrum the way to go?

I first heard of Scrum during my studies at University in 2012. I found the topic to be really intriguing, which led me to study and obtain a certification as “Professional Scrum Master”. However, many companies that I worked for didn’t use Scrum. I had also worked with many companies that had an approach that was described as  “Scrum-like”, which means that they tailored Scrum to the needs and reality of the company. One major learning I had from this experience, is that this “Scrum-like” approach can sometimes alter the process and thus, diminish the benefits of Scrum.

Scrum Theory

Scrum is founded on empirical process control theory or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

Three pillars uphold every implementation of empirical process control:

• Transparency
• Inspection
• Adaptation

Transparency

Significant steps in the process must be visible to those responsible for the outcome.

Transparency requires those steps to be defined by a common standard, so observers share a common understanding of what is being seen.

For example:

• A common language referring to the process must be shared by all participants; and,
• Those performing the work and those inspecting the resulting increment must share a common definition of “Done”.

Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be too frequent, otherwise, it may get in the way of work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

Adaptation

If an inspector determines that one or more aspects of a process deviate outside acceptable limits and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of this document:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Adopting Scrum: The first baby steps

We were working on a greenfield project, which meant that we knew exactly what we should be working on during the next couple of weeks.  We started off by scheduling a kick-off meeting in which we reviewed Scrum, roles, values, and artifacts. This was a very important moment for the team in regard to the direction of transparency, previously I (tech lead) and the product manager were sharing the role of product owner, we made a clean cut that day and the product manager took the role as product owner, I took the role of Scrum Master and we also reviewed the role of the development team. Clear roles, expectations, and accountability were keys to moving forward.

The team agreed to follow Scrum “by the book” and we defined that a two weeks sprint would be ideal to get started.

We did our first sprint planning and used the criteria “what do we forecast we can achieve in the next two weeks?” as the starting point to come up with our first sprint since we didn’t have any metric to predict the current speed of the team.

In our first sprint retrospective, many blockers became clear – a few days after we had started our sprint, we could see a significant increase in story points. This pattern happened more and more the subsequent days, which was an increase of scope caused by weak specs that ended up blocking development. The team added other stories that were better written in the sprint and a long time to review work made the team delay finishing tasks.

Here are a few of the items on our “What should we have done better?” question on the Sprint Retrospective:

• Optional requirements in stories (they were never done and would get lost, also made QA very confusing)
• Slow code review/QA
• Change of scope in story Y during development
• Estimation meetings could be more effective
• Preparation for sprint review presentation (fixtures)
• Stories Blocking other stories were too long in review

It was very interesting to see the team raising these questions on their own; I always wanted to point out many of these concerns, but one retrospective was enough for the team to bring these items up and discuss possible solutions. By having multiple people bringing these topics into consideration, it was much easier to implement solutions, because the team felt (and was) empowered.

Status Quo after 5 iterations

After five cycles of learnings and adaptations, many changes were made. For example, the team decided that the ideal story size had to be smaller – on average one day per story. This is reflected in the burndown chart by the many, yet small points that are often being completed. The team found that this strategy decreased the risk of not being able to complete a big/complex story and had to push it into a subsequent sprint, which meant a great deal for the predictability of the team.

Wrapping up

Our overall experience with Scrum was very positive – the team was empowered by being able to drive change by discussing during the retrospectives and being directly involved in the planning. The product manager and tech lead gained a better understanding of the speed of the team and were able to use it when developing a product roadmap and managing the expectations of stakeholders. Our management was then able to better track the progress of the team in a very transparent way.

The process helped us move from a more centralized decision making (PM and Tech lead),  towards a more empowered team that is involved in all stages of product development. As the leader of the team, I noticed a notorious increase in engagement by the engineers, which was reflected in an increase in performance throughout the team.

In the image above, we see that the blue represents the forecasted capacity for a given sprint, while the red shows the number of story points that were actually delivered. However, since we might have a different amount of people/days on holidays in each sprint, I added the third bar (in yellow) on the chart that represents (estimated performance based on average) the speed as if everyone was present during that cycle, which represents the real velocity/capability of the team. We can see a consistent trend of improvements over the course of the sprints.

In conclusion, nothing is perfect: There can be less productive sprints or if something happens, we might need to change the scope. However, the team was able to handle these situations more gracefully and with increased transparency after implementing scrum. After only a few cycles, the team was already reaping the many benefits by the change in the process.