The story of one team’s evolution with Scrum
Hello dear followers and readers.
First of all, let me excuse myself for taking such a long pause and not writing in my blog. This September was packed up with interesting events and trips. After spending some time on a vacation, I gave a speech on the topic you are about to read at Krasnodar Dev Day #3. After that, I had the pleasure to attend the best conference on agile I have been to so far — Agile Rock Conference 2018 in Kyiv, Ukraine.
Finally, I have spent some time getting ready for my PSM II certification, which I have successfully passed this week. Expect the article with my tips & tricks on how to get prepared for it soon. Thank you all for following and enjoy your reading!
If you have ever read Scrum Guide, you should know these words:
Scrum is a framework for developing, delivering, and sustaining complex products. It is lightweight, simple to understand, but difficult to master.
Today I would like to share the story of one team’s evolution with Scrum. It took place during my days at N26 — the fastest growing mobile bank in Europe. Achieving and maintaining that status requires a high level of flexibility and agility which have become the main driving factors in the modern business environment.
Software development specialists were one of the first in the world to recognise that and adapt their way of getting things done. That gave birth to a set of frameworks and practices which were later united around the Agile Manifesto values and principles back in 2001. Scrum is one of them. It has the highest adoption rate amongst the software development teams around the world.
Putting Scrum in place
The team I would like to tell you about uses Scrum framework since day one. It was formed back in late April this year. Initially, we used only the tools and techniques given in the Scrum Guide. As the group gained maturity, we started to add additional practices to our toolbox. Being an Agile Coach at N26, I fulfilled the Scrum Master role in that team.
The structure of Scrum itself is very lightweight and is supposed to be understood easily. However, most of the team members were new to Scrum and I have previously experienced cases when people struggled even with Scrum foundations. So, to make the adoption of the framework less stressful we evolutionarily introduced changes, taking one step at a time.
For example, we did not involve our Stakeholders in the Sprint Review after the first Sprint. That allowed team members to get acquainted with the event’s structure and format in the safe environment. In fact, our first Sprint Review was more like a rehearsal where we defined the sequence of steps, ways of interacting with stakeholders and how to avoid turning our Sprint Reviews into useless Demos.
After the second Sprint, we invited the team’s main stakeholders to participate. Both Product Owner and Development team members were enthusiastic about the feedback and appreciation they’ve been provided. So, after the fifth Sprint, we all went to another office to involve our real users. That allowed us to gather lots of useful insights and look at our product from a different angle.
Ideally, I recommend having real users present at each Sprint Review. It will allow you to:
- ensure Transparency and foster direct collaboration by cutting feedback loop down;
- develop empathy in the Development team;
- go through a regular cycle of Inspection and Adaptation of your Product Backlog to keep it as clear of false assumptions and priorities as possible.
Other practices & tools
Besides applying Scrum, we continuously added engineering practices and process tools from other frameworks, such as Kanban, XP (Extreme Programming) and Lean. The team still uses most of them regularly nowadays. Others became obsolete, and that’s a natural process too. It is important to mention that they were mainly proposed and introduced by the Development team members, not by the Scrum Master. Of course, sometimes it required mirroring the team’s behaviour and asking the right questions.
It is a proven fact that Scrum Development Teams with excellent technical practices are likely to be more successful. Regular Pair and Mob Programming sessions allowed us to ensure a better understanding of technical aspects and enable natural knowledge sharing. We managed to speed up the professional development of team members and prevent knowledge or expertise siloing.
Holding an offsite Kick-off and Threat Modelling for the new Product allowed us to create fundamentals for the future and bring all team members on the same page about our Product, its Mission, Users, their problems and ensure Product’s security.
Applying WIP Limits and Definition of “Done” helped us to define and eliminate bottlenecks. These factors combined with the outstanding team collaboration made our Flow smoother and more predictable. We also tried to apply the Definition of “Ready” but soon realised that establishing a close collaboration with the Product Owner and holding ad-hoc Product Backlog Refinement (PBR) sessions works better for us.
Team dynamics
Of course, we also had some conflicts and disturbances in our way. That always happens when it comes down to people and interactions. In mid-July, we faced a conflict between the Scrum Master and Product Owner that took place during the Retrospective in front of the whole team. It led to a counter-productive tension within the team during the next Sprint. However, we were able to solve it pretty fast and learned some useful lessons out of it.
Unfortunately, one month later our Product Owner has left the company, so we got to replace him. That factor combined with a new Developer joining the team was supposed to pull us back into Forming phase, but it did not affect the team too much. Kudos for that fully go to the team and new joiners who behaved pro-actively and enthusiastic since day one.
Results so far
Here you can see some metrics we use to assess the team’s performance process-wise. As you can see both Velocity (measured in Story Points) and Throughput (number of tasks) have stabilised and don’t show significant deviations when we take both of them into consideration. The team also managed to ensure regular achievement of the Sprint Goal and maintain quality on a high level though we don’t have a dedicated QA Engineer role in the team — all Development team members are responsible for reviewing the code and testing each other’s work.
Of course, assessing any Scrum Team performance only on these factors doesn’t make sense — the main metric should always be the value delivered and acceptance of the Product by the market. It is important to say that one should not use these metrics to compare different teams between themselves. They make sense only being applied to that specific team and allow us to define trends in our productivity. Naturally, there were some sick leaves, vacations and other things that are not viable on the graph, but should be taken into consideration while analysing the performance of any team.
We also used Spotify’s Squad Health Check to self-assess our work from the team’s perspective every two months. You can learn more about the way we used it as a tool for Retrospective facilitation from this article in my blog.
Based on the set of factors combined (team dynamics, performance, level of transparency and attitude) I can say that applying such evolutionary approach has benefited us a lot. We were able not only to avoid significant pitfalls in productivity but also make sure that all team members understand and share Scrum values: Courage, Focus, Commitment, Respect and Openness.
It was also a pleasure of mine to see that the team really owns the process and did not roll back to the previous way of doing work while I was away. This is the best proving that they have really understood Scrum and benefited from other tools and practices we have introduced in these 5 months.
Thanks for reading, I really hope you enjoyed it! If yes, feel free to clap or leave your response below. I am looking forward to reading your thoughts and ideas on the topic.
P.S. I would like to thank all people whom I worked with in the team described: Abhishek, Claudio, Daria, Emanuel, Friedrich, Jackson, Maximilian — without you that story would not take place. You are all amazing professionals and individuals. Thank you and keep Scrumming on!
