Hola, my name is Carina, and I was the first Scrum Master in our Nice Code Valley. Today I’d like to share the story of how our Scrum journey began, what challenges we overcame, and what plans we discarded on the way. I’d like to tell you why Scrum is worth it, how you can learn the Scrum process, and how I pushed my own limits doing so!

Why do I want to share this story with you? 

A) I want to share my incredibly cool experiences! I have to admit, I’m very grateful for the last year. I’m grateful to be a part of an open-minded company and to work in such a trusting environment. Without help from all the nicepeople I work with, we would have never succeeded in making the big change to Scrum in such a short time. This is reason enough to be proud of my great team; they’ve exceeded my wildest expectations!  

B) I also want to share my less-than cool experiences. We ticked off all the acceptance criteria from our “Introduction to Scrum” epic and met the “Definition of Done”, but we certainly stumbled along the way! The journey was tedious, and sometimes gruelling, but provided the valuable lessons that got us to where we are now. Thankfully, you don’t have to make mistakes yourselves, you can learn from ours in the Nice Code Valley Blog 😉!

How it all began…

Niceshops has grown enormously over a very short time, and so did the Development Department. We went from a one-room office with 2 people to a department of over 40 people, spread across two locations, tackling increasingly complex tasks at a pace. This growth does credit to the much-cited VUCA leadership theory. With growth like this, you wake up and suddenly face a plethora of challenges, like: How can we develop faster and with more agility? How can we make our organisation more scalable? How can we increase the quality of our work and better meet the needs of our internal customers? What can we do to keep our workflow and priorities transparent?

Scrum as a framework has always been interesting for us. Actually, we thought we had already adopted the best parts of the Scrum process. We worked in sprints and had daily stand-up meetings (even if they were mostly seated and were only three times a week). For some reason, our cherry-picked Scrum process just didn’t work. At the time, we didn’t understand why our modified Scrum system wasn’t working. Our “tickets” were far too extravagant, our teams were too diverse skill-wise to work well together, we cut back on meetings, and we decided we didn’t really need Product Owners if we had Developers…

At the time, I was theoretically familiar with Scrum and had attended training courses and read books, but practically, I only knew that what we were doing didn’t have much to do with Scrum. Then, Scrum became my top priority task for 2020, and I fell in love with the process. 

In my role as the Team Lead of the Nice IT Department, I thought about many possible approaches to Scrum. In small groups, we presented proposals, discussed them, adapted what we wanted to use and discarded what we didn’t. Looking back: the introduction of Scrum was our first real agile project; we adapted it in small iterations and incremental steps. By the summer of 2020, we had clarified many things, including which new roles needed to be filled, how our internal structure would change, what a switch to Scrum would mean for the company, and how to create transparency around our workflow. 

What was my role in all of this? Well, in what was probably the first violation of the Scrum manifesto, my role was unclear.

As Team Lead, it was my job to get the team to commit to scrum. The first step was to get our CEOs on board. Thanks to our corporate culture, this was a mere formality; the advantages of using Scrum were clear. Support from our CEOs gave us the backing and the necessary budget for hiring Scrum Masters, Product Owners and so on. Next, the CEOs presented our project to the management teams. We collected all the necessary information, presented our plan, adapted it for the individual stakeholders and created a uniform understanding of Scrum. After lots of attempts, our plan began to take shape. Soon we were ready to rock and roll! 

Transparency has always been important to us, and our stakeholders knew that a Scrum system would mean hard work for them too. Feature requests need to be  clearly formulated and have a clear business value; knowledge has to be passed on to the Product Owners, and time and patience have to be invested in reviews and coordination. Our stakeholders realised that the time we needed to process tickets may even increase using the new Scrum system. 

Within the team, we also had to create a little motivation for the project. We needed to keep the team informed of where we were with our plans, but not communicate anything that we ourselves were not 100% sure of yet. We planned a Kick-off Workshop to get the developers, UX experts, future product owners, and selected stakeholders on board. After the meeting, we were all pretty psyched! We also brainstormed a lot of challenging questions, like: How will we plan our releases? How long will our sprints be? How will we build our teams? At this stage, we were still workshopping our own answers and ended up discarding a lot of the “right” answers by accident.

How did we find a solution to building our teams? We asked our senior team members the following question: “Imagine you have to choose your dodgeball team at school. Who would you like to have on your team if your opponents were last year’s champions?” The results were as amazing as they were trivial: We created cross-functional teams with different knowledge bases and experience levels, that were perfectly capable of working in harmony. It sounds like a simple solution, but believe me, it took us a while to get there. 

First, we got bogged down by thinking of creating our teams using existing structures. Here, the perfect solution came from the team itself. We decided that each team would have a theme, dividing ourselves into: “Logistics/Finance”, “Shop Management” and “Customer Care”. Each team would meet with the department they were matched up with so that the department could share their expertise. As a result, each team could be mixed and matched using the “Split and Seed” approach, so that each Scrum team can implement each of our feature requests. 

With the teams set up, it was also clear which roles still needed to be filled. My colleague Christian supported and coached me through a staffing marathon. Since we already had a mental picture of exactly how our roll-out should take place, all we needed to do was find the right people for the roles we needed to fill. The great conversations we had during the recruiting process helped challenge and refine our ideas as we talked to experienced Product Owners and Scrum Masters. As we developed our Scrum framework, we thought about what structure to clearly define from the begging, and where we still had growing room so that our new candidates could help shape our process. For all of this to come together, we needed to make sure that our new candidates were a good fit for our teams on a personal and professional level.

Meanwhile, I also took on the role of Scrum Master in our interim Scrum setups. These “experiments”, as we called them, arose out of necessity, as the prospective Product Owners were getting impatient, and the development team was waiting in the wings. During our “practice refinements”, the Product Owners had the opportunity to present their first user stories to the Developers. In retrospect, this exercise proved to be invaluable: the Product Owners were able to adjust to the needs of the development team in advance, fill the backlog with user stories they already had time estimated for, and the team was allowed to try their hand at ‘planning poker’. Furthermore, it was possible for the team to get in tune with each other, define the rules of conversation and become familiar with Scrum in practice, in a protected environment with plenty of room for making mistakes.

After a short “experimentation phase”, I accompanied the “Saazer Power” team on their first Scrum. The rules of the game were clear, the team was working well together, and we were all highly motivated. Like old hands, we took up the fight against User Stories and courageously faced our stakeholders in the review. The process worked like clockwork, even with home office and remote Scrums working against us. The team practised self-organisation and arranged coordination meetings and pair programming in their chats. As their Scrum Master, I celebrated achieving our sprint goals with little surprises and lo and behold, things just kept getting better and better!

Were we ready for a victory dance? Not quite. As the Scrum Master, I had the feeling that the team skipped the forming phase and sprinted straight into the storming phase. What happened? One part of the development team was pushing really hard but forgot about the Quality Assurance Crew and Product Owners, who were under pressure as a result. It felt more important to “outperform one’s own development” than to adjust to a sustainable pace as a whole team. This raised the first doubts about Scrum: “Does it really work for our challenges? Is it really always applicable? Can’t we skip a few meetings and develop more?”

Questioning the process made it easy for old patterns to rear their ugly heads, e.g. attempts to overrule the Product Owner in setting priorities, forgetting about the customers, etc. What was surprising for me was that the transparency of the Scrum process was partly perceived as a fight for “control” (by the customer, Quality Assurance team, Product Owner, and Scrum Master) and the “self-organisation” and empowerment that the team received as a result was perceived as a loss of self-determination, especially by the senior members of our department.

Noticing and interpreting these points of friction was an important step for me personally. It showed us our blind spots and showed me where I had to refine the process, as well as where we had been too hasty. That was my biggest challenge: giving myself the time I needed to work through the process. I needed time to understand how Scrum works, time to trust the process, and time to get used to it all. Patience is unfortunately not one of my strengths, and I was slowly running out of steam. When I was able to hand over my Scrum Master torch in March, I was grateful to devote my attention back to my team. 

Step by step, we hired two Scrum Masters, two additional Product Owners, and Quality Assurance Managers. We integrated them into our teams, shared our Scrum vision and onboarded them throughout our various nice departments.

My top-five personal takeaways: 

• Do Scrum by the book: do Scrum right, or don’t do it at all! Starting half-heartedly is doomed to fail. 
• Setting a sustainable pace in development is really important: a sustainable tempo protects the last step of the testing phase and gives the Product Owners and Stakeholders a feeling of when a release is realistic. Not to mention a good work-life balance. 
• You can’t over-communicate: whether it concerns the “Definition of Done”, the roles and finer points of the Scrum framework or quality assurance, you can’t communicate enough as the Scrum Master. It’s really easy to lose perspective if you’ve developed a lot yourself or were involved in creating the product. Make sure to question each step of the way for clarity and focus.
• Create role clarity: avoid the slippery slope of making exceptions or telling yourself, “oh, we don’t really need to follow the Scrum framework in this instance”…like, it’s no problem if the Product Owner develops the solution, or is also the Quality Assurance Managers, or if the Scrum Master has a management role or departmental responsibility… Excuses like “that’s definitely not a problem for us” or “that’s just an exception” will get you into hot water sooner or later. 
• Make sure to pay close attention to people as individuals and to personal interactions: Well-prepared retrospectives are part of a Scrum Master’s duty, and reading between the lines in your team is really important. A task that is a blessing for one person might be a curse for someone else. Needing to work closely together might be a burden for one person and a relief for another. Responding to the needs of the individuals in the team is a real challenge, and you won’t find solutions to meeting personal needs between the pages of the Scrum handbook. Take time to listen to the team and give the team time to familiarise themselves with the new requirements and processes of Scrum.

Once Scrum was established – was I unemployed? Once our Scrum teams were up and running, our Product Owners were gaining experience, and our Scrum Masters were becoming masters of motivation, I withdrew from the operative Scrum process. It made me both really happy and really sad to see our teams functioning so well, as it meant that it was time for me to bow out. If I do still get involved in Scrum Master agendas or Product Owner discussions, it’s not because I’m not convinced that they can’t do it on their own, but because I just really love the Scrum process. Now I am consciously trying to stay out of our teams’ daily business, instead, I’m investing my time in supporting our “Communities of Practice” where I am available for questions, requests, suggestions or simply as a sparring partner. We’re all united by the same goal: to constantly improve our processes and cooperation so that we’re more efficient and to offer both ourselves and our stakeholders more satisfaction.

According to the Scrum literature, we need another one to one and a half years until Scrum is ingrained in all of us. Since Agile constantly grows with us, there is no end to our growth in sight! I’m sure we’ll make more mistakes, fall down, get up again, and keep on going! Through it all, I’m here to support our teams on their journeys. 

According to Mike Cohen’s “ADAPTing to Scrum” principle, the next step on our journey is to promote Scrum within the company, sharing our stories with other teams. The ultimate goal would be to expand Scrum to other departments in the company. We’re not sure if we’ll get there yet, but we’re definitely up for the challenge! Oh, and p.s. – I’m not unemployed. The journey continues! 😀