If you are considering an Agile Scrum transformation, or are curious about what Agile Scrum could do for your product development team, here’s our story as a cautionary tale — with a happy ending. Two days after we switched to Agile Scrum, we had a full-scale riot on our hands and began thinking we had made a big mistake: No one knew why we had changed, everyone had an identity crisis and people were ready to leave the company.
Here’s How it Happened
Three years ago, we were doing waterfall development: features would start out as PowerPoint presentations that defined how things should work and pixel-perfect Photoshop renderings that described what the user interface should look like. Product managers would hand these renderings over to developers who would code them up and then hand off to the QA team to test. In theory, that process was supposed to lead to predictability and productivity. But in reality, we were deeply unsatisfied with our capacity to get anything built.
We knew there had to be better way to build software and we saw Agile Scrum as a way forward.
As the Product Development leadership team, we went on a sacred quest to learn more about Agile Scrum. We read books about Scrum, finding the short books the most useful. We visited a company that we admired who were already doing Scrum and witnessed the cross-functional teams sitting together, planning together and working together. We all went for Scrum training — I even got certified as a product owner — to learn how the rituals of Scrum worked. Finally, we hired Scrum ‘experts’ to train the rest of the company on the process.
Then, one sunny Monday morning, we gathered the entire Product Development team and told them that we were changing the way we were developing software IMMEDIATELY. We introduced them to the Scrum experts who gave them generic training. Then we unveiled a new team structure — where product managers, developers, testers and designers were going to work with “Scrum Masters” — a new job title at our company. We believed we would start building great software efficiently, transparently and predictably… and all live happily ever after.
Two days later, that riot I mentioned was in full swing.
What Did We Do Wrong?
We Didn’t Explain Why Things Were Changing
Two days into the transformation, it was obvious that no one was really bought in to the new way of working. As the Scrum experts were training the entire team, one of my developers was tweeting that we were now wasting his time with a futile attempt at process re-engineering (except he used much more colorful language).
Looking back, I can understand his point of view completely. Why would he or anyone else buy in? BEFORE you do the switch to Agile Scrum, you need to share with your team why you’re changing. This involves explaining and debating why you think that Agile Scrum is better. And when you have done that so often you are sick of it, you need to do it a few more times.
We Didn’t Visualize “What Scrum means to ME”
During the riot, we were surprised by the number of people that felt like they were now out of a job. One of our brightest product managers had a severe identity crisis; he no longer understood how he fit into the organization because he wasn’t just creating PowerPoint decks anymore. And he was part of the leadership team that forced the transformation!
When you make the leap to Scrum, every member of your team needs to very deliberately map the difference between their job today and their job after the transition. Conducting this thought experiment and figuring out the impact new responsibilities will have on daily routines will help everyone make the transition confidently. It will help everyone get through that feeling of displacement and helplessness they sometimes have on the first day, week or month.
We Weren’t All Team Players
Agile Scrum philosophy talks a lot about “self-organizing teams” that emerge organically. The unwritten assumption is that all your people are team players who are good at communicating, interacting in groups and collaborating. This was definitely not the case with our team at the time of the transformation.
Agile Scrum is not for everyone; it really only works if your team members know how to collaborate. Be prepared. Lone wolves will have a really, really hard time adjusting, sometimes just giving up altogether and leaving your organization. Be prepared to accelerate this “adjust or opt out” process and be OK with the consequences.
But… It wasn’t all bad. We did get some things right.
What Did We Get Right?
We Asked For Breathing Room
We set expectations with the rest of the company. We let the executive team know that we may not get results for 90 days after the Agile transformation. They did not understand exactly what we were doing — so we asked them to trust us and, in return, we promised to update them regularly and honestly.
This gave us the breathing room that we needed to learn from failures, iron out the kinks and eventually get better and deliver what the executive team DID understand: results.
We Did All of the Scrum Things
Agile Scrum is not a smorgasbord or buffet. You can’t just do the things you like and drop the others parts of the process. The rituals (meetings), roles and artifacts (documents) support and reinforce each other.
For instance, doing sprint planning ensures that you have well understood stories and tasks that you use during the daily standups. We had heard that picking and choosing select things to do was a common reason for Scrum failure . So we made it a point to do ALL the things that were prescribed.
“Fake it Till You Make It”
We persevered. The Agile Scrum process is well documented; the roles are well defined, meetings are simple and the purpose of the documents are clear. We just started doing it according to the rules and kept doing it according to the rules — even though most people didn’t understand the ‘why’s’ behind what they were doing.
After a while, we started getting results, and then we started to understand the why. This understanding enabled us to refine how we were doing things and get even better results. I firmly believe that this is the only way to ‘get’ Scrum and then get good at it — start by faking it and persevere until you make it.
We Selected the Shortest Sprint Length Possible
We chose the shortest length of time for our sprint duration — 1 week — so that we could get as much practice as possible with all of the Scrum rituals. We figured that since everything was new, the only way to get good at Scrum rituals was to do them often and, that way, have more opportunities to practice and to get better.
We Got What Was Advertised
It was hard to see, but 30 days after the transition, there were signs of progress: we were doing all the rituals. At 60 days, we were getting good at planning and realistic estimation. At 90 days, we had figured it out and started to show real results.
We got all the things that Agile Scrum advertises as its benefits:
- We got efficiency by eliminating the waste and rework that we always saw when we were handing over projects from product management to development to QA.
- We got realistic predictability that let us confidently make promises to the rest of the company.
- Finally, we got transparency that enabled us to engage stakeholders, see steady progress and get an early warning if a project was running into trouble.
But Wait, There’s More…
Previously, we had scaled the Product Development team by hiring people: developers, designers, product managers and testers. The problem was that as these siloed teams got bigger, doing projects got slower because of the planning and coordination overhead between teams.
After switching to Scrum, we had cross-functional teams that were self-contained and had all the skills to complete a project; no more complex planning and coordination required. With the Scrum team as our unit for scaling, we grew without slowing down.
The transparency of sprint demos forced designers, programmers and QA team members to show their work to other parts of the business, to their stakeholders and to each other. They had not done that before. Routinely sharing their work fostered a sense of pride that was infectious.
When we got good at Scrum, product managers felt satisfaction at being able to actually participate in delivering software. Previously, they felt hopeless as they watched their pile of requirements documents get higher and higher. Scrum also unleashed the creativity in all of our programmers since they weren’t just coding to a set of requirements dumped on their desks. Now programmers were being invited to collaborate in UI design and business decisions as well. This added up to a much happier team.
This was a big one and one that took us by surprise. Previously, we had a bunch of people who were sitting beside each other but really working independently. I now refer to it as “parallel programming”, since it looked like you were working with the person beside you, but you were really on your own. Agile Scrum practically forces teamwork and collaboration, and once the forced teamwork became ingrained (see “Fake it Till You Make it”), we started to see results.
Teamwork allows you to tackle ambitious projects because you are not limited by the capacity of a single programmer to execute. You could argue that one person will just take longer to do the same thing than a team will — if one person can build a small shed in a day, then that same person should be able to build a more complex shed in two days. Unfortunately, one person could not build the pyramids — they wouldn’t live long enough, and even if they did, they would not be able to move even one of those massive limestone blocks on their own.
Some projects just need large teams to accomplish in a reasonable time frame — and Agile Scrum unlocks that teamwork.
Agile Scrum has revolutionized the way we build products at FreshBooks and has made our product development team a kickass execution machine. If any of the benefits we got would help your organization, you should go for it.
Before Agile Scrum, we would start or complete less than 20% of the projects that we had promised to get done in the quarter. After the Agile transformation, we started or completed 90% of the projects in the quarter that we promised — a dramatic increase in the results we were producing for the company. And really, results are the only reason you would go through such a traumatic experience as an Agile transformation.
Who says riots are all bad?