How to start an agile transformation

Our transformation into a responsive agency

In 2016, we changed the way we work at aFrogleap. We moved from project-based teams to three Scrum teams. This is a retrospective on our transformation.

Agile is a mindset, based out of four values, twelve principles, and many tools and practices. The Scrum framework helped us make a leap in our agile journey.

In 2015, aFrogleap looked a little bit like this: a bunch of motivated individuals — as you may know, we like to call ourselves frogs — simultaneously working on a number of projects for different clients. Our projects included strategy, product design, and development work. Based on the nature of the project, frogs of different expertises were involved. Usually one per expertise.

For every project, we had a Digital Producer who managed the project , trying to align the project’s stakeholders with the team. Since Digital Producers managed several projects at once, this meant that they were often running from one standup to another , sometimes even four in a row. We were doing standups for a while now, along with some other parts of Scrum , like the idea of a short iteration. Time-boxes weren’t there, so a standup could sometimes take 45 minutes, and an iteration could take three instead of the originally planned two weeks.

To guarantee that work followed our development standards, developers were peer reviewing each other’s work. Because most of the times, the reviewer wasn’t involved with the project, this required a lot of context switching during a day.

New projects usually went like this: after a number of sessions with a potential new client, a director sent out a proposal of the expected work . This was based on our experiences with previous, similar projects. If the project was a ‘go’, the involved frogs were expected to work within these time constraints, which sometimes didn’t match up with reality.

When we started a project, it usually went through three stages: strategy, design, and development. Because people were involved in multiple projects at the same time, there usually was a hand-off after each stage. Later on in the project, this sometimes made it hard to understand what had happened in a previous stage.

And, of course, there was the maintenance of older products that sometimes needed ad-hoc improvements or bug fixes.

The problem

As our team grew quite steadily over the last couple of years, we were beginning to feel the pain of that growth. Our way of working had worked really well, up until now. It was time to re-evaluate.

To visualize what was happening, we used a number of tools. We started with regular project retrospectives. This helped us to stop and take a look at what was going on. We began doing ‘Frog awesome checks’, our twist to Spotify’s Squad Health Check. This way, we got a clear overview of the biggest issues per project. We did the same companywide, in a big retrospective with all our frogs.

We also got a helping hand from Leo, Officevibe’s Slack bot. Leo helped us measure employee engagement on ten domains, ranging from personal growth to company alignment. The feedback we got gave us great insight into what areas to focus on.

In summary, we were struggling with:

• Company growth. Growing to over 25 employees forced us to reinvent ourselves. As we grew out of our lunch table, it also became harder to stay up-to-date on everything that was going on in the company. It was hard to see where things went smoothly, and where people needed help.
• Clarity and overview. The teams our frogs worked in changed at least once a month, causing our teams to be in Tuckman’s Storming stage constantly.
• Personal growth. It was really hard to learn on the job because of the constant context switching. There was little room for autonomy, mastery, and purpose.
• Prioritisation. Everything was happening at the same time. Multi-tasking was the standard. It was hard to focus on completing one task. We were working efficiently, but not effectively.
• Quality assurance. The way our teams worked caused project silos: collective knowledge only existed for a short period. After a project team split up for new projects, this information dissolved.
• Handovers. Fifty percent of knowledge gets lost in handovers, and we were having a lot of handovers.

Following the rules of Scrum

After having a clear picture of what was holding us back, we started with our first experiment: Run 10 one-week sprints, following the rules of Scrum.

We had adopted a number of agile practices already, and we were seeing some of the benefits. What we were struggling with, though, was taking that next leap in our agile journey.

We hoped this experiment could help us overcome our struggles and improve in a number of areas:

• Continuous improvement. We chose to start with one-week iterations so that there was a retrospective every week. This would give a team the opportunity to inspect, adapt and do a small experiment every week. This gave us the opportunity to try out a number of tools and practices, and to create a safe environment for personal growth.
• First steps to High-Performance teams. We started with two stable teams, working together on a daily basis. Both teams existed of two Android developers, two iOS developers, a backend developer, two designers, a strategist, and a Product Owner (our two former Digital Producers). Teams were expected to self-organise and therefore break down the expertise silos where needed.
• Work at a sustainable pace. By doing one-week iterations, we would get a better understanding of the events in Scrum, and how to use Scrum’s values, roles, and artifacts to become more effective. We want to maintain a constant pace indefinitely, guaranteeing a high level of quality while having fun in what we do.
• Prioritize our company backlog. Working with two teams would give us the opportunity to create one company backlog (both with internal and external work), giving more clarity and overview.

What worked well

Last year, the week before Easter, we took two days to align where aFrogleap was standing, what steps we wanted to take and why. We combined workshops with talks, discussions and team building exercises. We created team names (Kaeru and Blitzkikkers), team agreements, learned about each other’s past, about the five dysfunctions of a team, Tuckman’s stages, and decorated the team war rooms.

Also, we made a start with aFrogleap’s Playbook — a living document describing our history, vision, values, objectives and way of working. Everyone at aFrogleap has been able to edit it since then.

And then we started.

After settling down from the team formation, the teams started to see the first opportunities for improvement. During the first weeks, retros were focussed on soft skills, needed to effectively work together — especially cross-functional. After that, we started experimenting with new tools and practices that could help resolve our biggest impediments.

After ten weeks, we did another company retro to inspect and adapt. We talked about what to keep doing (one that got a lot of votes: “learn what’s working for us”), what to do differently (“be more strict about following agreements, or change/drop them”), insights (“being cross-functional is difficult”), and mysteries (“how can we learn from the other team”). Frogs were able to volunteer to resolve mysteries and impediments.

Since then, both teams have switched to two-week sprints, we scaled to a third team, we started with OKR for team and personal objectives, we set up 360 degree reviews, and improved the on-boarding of new frogs. We also created training programs for teams and individuals. We use them to help new frogs or new clients get up to speed with our way of working . Examples are our agile & Scrum training, and more specific our Product Owner training.

All in all, a year later, we can say that our original experiment ( 10 one-week Scrum sprints ) was a success. It gave us the opportunity to resolve systemic problems, to create space for personal growth, and it allowed us to slowly grow into High-Performance teams. Since then, our employee engagement has improved by 20 percent, customer satisfaction is a 🙂 or 😁 most of the times, and we’re continuously trying to improve and resolve our next biggest impediment.

Tools & Practices we love

These are some of the tools and practices that help us improve our workflow.

• Product design sprint. A unique, five-day process to validate if an idea is worth building, via prototyping and user interviews.

• Product vision board. The long-term goal we use as a beacon during the project.
• User story mapping. Creates a visual overview of the user’s journey in the product. After slicing it in several value-adding releases, it also serves as a roadmap.
• Example mapping. Helps us work out the details of a specific story and make a visual representation of it within 25 minutes.
• Magic estimation. Get an initial, rough estimate of how big a project is and what is most valuable to build first. We use this to give a range of sprints.
• Company Definition of Done (DoD), and Ready (DoR). We started with team DoD and DoRs. After a while, we decided to combine both teams’ learnings into our company DoD and DoR, which all our teams now use as a minimum.
• Team poster. Every Tuesday, we start with a 45-minute company-wide meeting, called the Weekly. At the end, the team who finished their sprint the day before share their highs and lows with the use of a poster that shows their burn-down, (customer) satisfaction, retro action items and next sprint’s priorities.

What we learned

Of course, not everything was a breeze. Besides being frogs, we’re also humans. With our experiments, we try to take small steps to see if it has the desired outcome, so we can learn from that as quickly as possible. These are some of the things we have learned from the past year:

• One-week sprints. While one-week sprints gave us a great opportunity for learning Scrum quickly, it did feel like being in a pressure cooker all the time. The teams changed to two-week sprints after a while, which we run out-of-sync, so that frogs can join the other teams’ events.
• Objectives and Key Result (OKRs). We started last year with setting company, team and personal objectives using OKR. It gave us great insights in the alignment of personal and company goals. What we didn’t do well enough yet was follow-up and update our OKRs frequently. We’re now making a fresh start with that. We hope that it will enable us to further improve employee growth and engagement even further while maintaining a balance between alignment and autonomy.
• Automated metrics. Most automated metrics we use are for the current sprint only. We have plans to create a dashboard which should give an overview, and let us spot trends more easily than through manual labor.
• Playbook updates. Our Playbook was gathering some dust. We have just brushed it off and gave it a fresh look. Slowly, we’re making more and more tweaks and updates.

And now what?

Our journey continues! While mastering domains like mobile, artifical intelligence and cultural change, we found out that there are whole new areas to explore.

Our goal remains to help clients achieve their business goals better and faster, with innovative ideas and validated learnings. We are figuring out better ways to do so each day. Better enjoy the ride, while we’re at it. 🐸🚀

Special thanks to Henrik Kniberg for being a great source of inspiration.

‍