The Hardest Challenges of Implementing Scrum: Embracing Rapid Iteration

How rapidly are you iterating?

Since the first item in my list of the 5 hardest things to achieve in implementing effective Scrum was somewhat of an intangible, abstract “mindset” switch, then this second item might strike you as rather obvious. After all, isn’t engaging in “rapid iteration” essentially the definition of Agile methodology from the get go? Am I just saying something to the effect of “In order to be excellent at sports, it is essential to play sports well?”
In a way, that’s exactly what I am trying to say here, because the real bar for doing Scrum/Agile correctly is so high that many Scrum/Agile teams only work on short sprints in name only. They still think of how they complete projects in a waterfall of milestones.

What it Takes to Truly Embrace Rapid Iteration

Why do I say that? I think many Scrum teams work hard to adhere to a more rapid cycle of 3-4 weeks sprints. I have no doubt they have subscribed to the core concepts of Scrum in theory, and are turned off by the idea of traditional waterfall projects. But, honestly, there is more to it than simply having short sprints and releasing products often. The reason many teams fall short of reaping the full benefits of Scrum is because in their minds, they do not yet fully embrace rapid iterations and fully savor the process of doing those rapid iterations.
I believe that teams only truly embrace this idea if it permeates everything they do, and they have become such staunch supporters of it that they evangelize other teams inside or even outside of the organization. Even more importantly, their adherence to rapid iteration has to be so strong that they will not budge when pressure comes from above (or below) to force them to give up (even briefly) their rhythm and process.

Why That’s Necessary

Why is it so important for teams to fully embrace this idea? For starters, it is the foundation of Agile, because rapid iterations allow teams to make just-in-time decisions based on new inputs/feedback. But by fully embracing this idea, the team can also begin to think about their project, its goal, and their mission from a very different perspective — outside the limitations of building “X” product according to a “Y” specifications within a “Z” time frame.
When Agile is fully embraced, a project becomes part of an iterative search process for the right answer to a broader, more impactful question — what product will meet the customer needs?
By asking that question, now the team can embark on an important discovery mission. And because they are engaging in rapid iterations they have a built-in flexibility and ability to quickly pivot. That is absolutely key, and far more effective in uncertain situations than following a straight-lined trajectory, even if that trajectory is broken into small stages.

The Two Scenarios Where It Can Be Difficult

Why it is so hard to embrace rapid iterations? You would think that it is just a matter of process and discipline, yet there’s often more to it. I often see two distinct patterns depending on the experience of the team:

Scenario 1: Transitioning from a non-Agile process

If the team was originally doing some form of waterfall/non-Agile project management, there is often a natural tendency to revert to the old ways, especially if the team’s product managers and management still expect them to deliver products based on requirements created far in advance and on linearly projected timelines.
These teams will also have to overcome organizational and technical hurdles as they work to integrate the process of testing and validation as part of the sprint.

Scenario 2: Losing efficiency with growth

However, I also see very efficient Scrum teams gradually lose their focus on rapid iteration as they build out their platform and start having to scale their team to cope with increasing workload.
In the early days, when there was just one core technical team building the product, they would release early and release often, achieving the true 30-days or even weekly release cycle. Later on, it often seems like the sheer weight of the product that they’ve built, and the organization that they’ve developed to support that product actually hamper their ability to rapidly iterate. Sprint lengths get longer, releases start to bleed across multiple sprints, and the team loses the discipline of trying to release as often as they can.
I would not say that this happens all the time — there are very strong engineering organizations that maintain a strong focus on rapid iteration even as they scale dramatically (here is one example) — but for many teams, it can be a real challenge.

4 Keys to Help You Embrace Rapid Iteration More Easily

Let’s see what improvements can help make your team embrace or rediscover rapid iteration more easily:

1) Address your lack of time by adopting the right tools

Because lack of time is often the biggest impediment to shorter iterations, one obvious thing teams can do is make sure they have the proper tools in place (continuous integration, automated testing, etc.) to facilitate the entire cycle of iteration.

2) Address your lack of direction by optimizing your feedback loop

The team can only know how to iterate on an output if there is timely, closed loop feedback from customers, users, and product owners. The feedback process needs to keep pace with the development cycle, so that the engineering team can rapidly see the impact of their work and be more motivated to move even faster.

3) Address your lack of prioritization by bolstering the Product Owner role

When it comes to getting rapid iteration right, the role of the Product Owner cannot be overvalued. Product Owners should be the staunchest proponent of rapid iteration by developing backlogs that are conducive to it. They should also be the most critical eyes on the team’s own plans and rhythms. They need to develop very strict priorities based on impact, and drive rapid changes to the product backlog so that the backlog is conducive to rapid, purposeful iteration.

4) Repetition, repetition, repetition

Lastly, we go back again to the ultimate effect of Scrum — it is so hard and yet so effective because it requires a shift in mindset. In order for that to be possible, rapid iteration needs to be repeatedly stressed and emphasized to the team (during retrospectives and sprint reviews, etc.) until it firmly settles in as a core tenet of how the team thinks about any project or assignment.
Better still, if each team member personally embraces this mindset and not only applies it to the project as a whole, but also to their own individual tasks and discoveries, you will see a remarkable impact on what you can accomplish.
Is there another scenario you’ve experienced that has made it difficult to truly embrace rapid iteration? Share your thoughts below and I can try my best to address it, as well.

1. Introduction: The 5 Hardest Challenges of Implementing Scrum
2. Challenge 1: Developing a truly empowered, self-organizing, and self-examining team
3. Challenge 2: Embracing rapid iteration
4. Challenge 3: Adopting prioritization by impact
5. Challenge 4: Applying realistic but practical estimation
6. Challenge 5: Managing Effective Scrum meetings