Agile Adoption – The Struggle is Real

Leadership has influence over teams. Those leaders that have adopted Agile are influencing teams by empowering them, removing burdensome practices and resolving organizational impediments. Leaders that don’t trust Agile are imposing what they believe are “best practices” for project management. Micro management is usually prevalent.
Woman's Hand Placing Last Alphabet Of Word Trust Over Wooden Block

Why is the adoption of the Agile mindset so difficult? There are many reasons. According to Digital AI’s 14th Annual State of Agile report, the top 5 challenges faced by Agile adopters are:

  1. General organization resistance to change
  2. Not enough leadership participation
  3. Inconsistent processes and practices across teams
  4. Organizational culture at odds with agile values
  5. Inadequate management support and sponsorship

To me, all of these items have a common root cause – lack of trust. I’ll explain…

General organization resistance to change
Change is hard, and generally we all resist it. What we know is what feels comfortable. Anything new requires some level of trust in order for us to try and adopt it.

Not enough leadership participation
Why isn’t leadership participating? There could be many reasons. In my experience, many don’t participate because they don’t believe it will work. Said another way, they don’t trust it, for whatever reason(s).

Inconsistent processes and practices across teams
Leadership has influence over teams. Those leaders that have adopted Agile are influencing teams by empowering them, removing burdensome practices and resolving organizational impediments. Leaders that don’t trust Agile are imposing what they believe are “best practices” for project management. Micro management is usually prevalent.

Organizational culture at odds with Agile values
If the organization has not embraced concepts like team self-management, giving teams the space to inspect and adapt their own processes, and embracing failure as a learning opportunity, the organizational culture will work against agility. In order for any organization to turn toward agility, they must have some level of trust in the growth process.

Inadequate management support and sponsorship
If management doesn’t believe in the Agile mindset, how can one reasonably expect them to trust it enough to support/sponsor it?

So now we’ve established at least one possible root cause for these difficulties. Let’s next try to understand the why. Then we’ll focus on how we can change it.

Imagine you are a manager. You’ve worked for a long time to attain your current position. And to get this position, you’ve excelled at the game, under the rules of a non-agile paradigm. Your ability to delegate to and direct people, and gain control over situations is what qualified you for your current role. If you’re not in charge, people screw up. So it’s up to you to prevent that from happening – because “failure is not an option.”

In several ways, those in management are just like those in teams. They have bills and responsibilities. They likely have families to support, car and mortgage payments, kids in college, retirement considerations etc… In these ways management is just as dependent on their jobs as anyone on teams. Therefore, job security matters just as much to them as it does to you. Now imagine that after all that time perfecting the art of delegating, directing and controlling to achieve current levels of success, along comes Agile. And what Agile is saying to them is essentially “forget all that you learned to get here, because Agile doesn’t work that way.” Under that lens, can you blame management for resisting this change?

So what can we do about this? How can we gain not only management’s trust, but also their support and full buy-in? The answer is simpler than you think. Earn it. And that’s where Scrum comes in. The Scrum framework can help solidify the Agile mindset. Here’s how…

Empirical Process Control
This is a fancy way of saying once you have data, use it.

<disclaimer>
Before I continue on this thread, a note about velocity; this metric is often misunderstood, and consequently misused. In the traditional sense, velocity is the sum of “story points” completed by a Scrum team during a single sprint. Although velocity can also be measured in other ways, such as number of stories (or product backlog items) completed in a sprint. Velocity is meant to be a planning metric strictly for teams to consider. This metric is designed to help teams plan future sprints. Velocity can be useful to management and the organization at large in helping to understand how much work can be delivered over a period of time in the future. That is the extent to which management should consider velocity.
</disclaimer>

Here’s one example of how historical data like velocity can be used/misused. How many times have you witnessed something like this? The team’s velocity in sprint 1 was 10 points. But the team “thinks” it can deliver 20 points in sprint 2, so that’s what the team plans. The vast majority of the time, the team will not successfully deliver those 20 points. Let’s say the team plans for 20 points in sprint 2, and only successfully delivers 15 points. The results are 1) the team feels like they failed and gets demotivated and/or nervous. And 2) management starts doubting the team, asking questions and begins to feel the need to micro-manage. The other side-effect is that team members will start to feel the pressure to earn back their perceived lost credibility. This generally causes what I like to call the double down effect. In this scenario, as humans, we tend to double down on a bigger over-promise in sprint 3, so we can wow management and earn back the credibility we lost in sprint 2. This starts a self-defeating cycle. Think about it… If you fail again after the sprint 3 double down, now your credibility is likely lost beyond repair. If you happen to succeed in the double down, you’ve likely crushed yourself to pull it off. You’ve probably worked nights, weekends and put your life completely out of balance, in order to deliver. And in the process, you’ve set the expectation with management that they can expect this level of effort from you all the time. This is clearly not a sustainable approach.

So what about an alternate approach that makes use of empirical data? Why reach for 20 points in sprint 2? Why not plan for what you have proven you can do (based on the 10 points delivered in sprint 1), and if you do happen to speed up, that will get reflected in the velocity achieved in sprint 2. Here’s how… when you finish the 10 committed points (which the team knows it can achieve, based on past performance), with time left in the sprint, the team will pull more work from the product backlog into sprint 2. In this scenario, the team planned for 10 point and delivered (for example) 15 points. But in this scenario, let’s examine the outcome. 1) the team feels good about accomplishing 15 points because they over-delivered on their initial commitment of 10 points. And management is now impressed because the team delivered more than was planned. Said another way, management is going to start to trust the team.

In order for Empirical Process Control to work, you need 3 things. Transparency, inspection and adaptation. Here’s why…

Transparency
Making your data visible to yourself is the first step in noticing patterns and identifying areas to address. Data always tells a story, and it is a story worth reading.

Making your data visible to the organization (whether the data is good or bad) tells the organization that you’re not hiding anything. As sprints progress, the organization can also begin to understand what they can reasonably expect from the team over a longer term, based on prior data. This also builds trust.

Inspection
Once the data is available and visible, we’re compelled to inspect it. Truly get in there and understand the story. There will always be patterns, events and noteworthy specifics that can generate insights for the team and for the organization.

Adaptation
Once you’ve read the story the data is telling, opportunities to adapt will become more apparent. You’ll see things you can change in order to improve the process. And as you continuously improve (or fail and learn what not to do), your delivery will ultimately improve. And this will lead, yet again, to increased trust from management.

Adopt the Entire Scrum Framework
Too often organizations make the decision to “cherry pick” and use the things they like about Scrum, and disregard the rest. This is a mistake. Why? Because what Scrum is best at is not necessarily solving your problems, but rather identifying them. This, I believe, is one of the root causes for failure in Scrum implementations. Too often, we don’t want our problems or shortcomings shoved in our faces. The more pieces of the Scrum framework that are taken away, the lesser are the chances for identifying important impediments that need to be solved. As vital impediments get identified and resolved, teams are able to deliver more, more frequently and with better quality. And that equals trust from the organization.

Definition of Done
Nothing will degrade the trust a team gets from management quicker than poor quality delivery. And if customers are the ones who find the bugs, the consequences are significant. Customers stop trusting the organization, and the organization stops trusting teams. Investing in the creation of a rock-solid Definition of Done is the best antidote. The Definition of Done is essentially the standard of quality the team is committed to when building product. A thorough Definition of Done may make it “feel” like finishing one product backlog item can take forever (due to all the standards one has to meet). But that is a short term vision. The biggest slow-downs teams and organizations face do NOT come from slowing down and doing things well. They come from rushing and having to do things over. A well constructed Definition of Done, that is fully owned and adhered to by the team is the single most impactful way to earn the trust of the organization.

Invite Managers and Customers to Sprint Reviews
The sprint review is an event that takes place toward the end of the sprint. The purpose of it is to inspect the increment of product that has been produced by the team, and to solicit feedback about it from actual customers.

Managers tend to measure team performance based on that team’s velocity. As we stated earlier, velocity is a metric that the team uses to plan future sprints. What the entire organization should be focused on is value delivered to the customer. THAT is the metric from which all other metrics should derive. Regardless of velocity delivered, if management can see for themselves the reaction of customers based on what they are shown in the sprint review, they will know how the team is performing.

Another impact of commingling managers and customers in the sprint review is less interference from management in terms of product backlog prioritization. If you have ever witnessed management injecting themselves in priority decisions that should be left to the product owner, you know this is a prominent problem. If management hears directly from the customer about what they feel is high priority, during the sprint review, management will be far less likely to interfere with the product owner’s priority decisions. And as all of what is contained in this article continues over time, management will witness an increasingly happy customer base. And guess what this leads to? Trust.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email
Scroll to Top