What to Do When Agile is Failing (“We’re Doing it Wrong”)

Nothing is quite as frustrating as putting all your time and effort into an agile transformation and not achieving the expected results.

You wanted more management of changing priorities, more project visibility, more team productivity.

Instead, you’re getting less. Seemingly on every front.

So where’s the problem?
      A. Agile doesn’t work
      B. We must be doing something wrong

If you chose B, that’s great. There’s hope. Because once you acknowledge you’re doing something wrong, you can fix it. The challenge is in discovering what “it” is. In this post, I’ll share some of the most common struggles I see with agile, so you can determine where your own fail points are… and fix them.

It all starts with leadership

Your leadership team must be “all in” when it comes to agile. Otherwise existing cultures and philosophies will wash out those changes you’re trying to make.

If you see your agile efforts failing, take a look at your executive team’s support. Are they setting a positive tone, encouraging success, and eliminating obstacles? If your team is divided, you need to address that first… even tacit resistance from leadership will be sensed throughout the organization.

The executive team also needs to make sure that agile teams receive enough autonomy to perform their duties. They must stand ready to enforce that autonomy in order to keep outside influences from slowing down the work.

Fix any problems in the team’s self-organization

Are Product Owners and ScrumMasters fulfilling their roles properly? These are the caretakers of your agile process. If they lapse into the more traditional roles of business managers and project managers, then you are no longer following agile principles.

Product Owners are in charge of organizing and managing the product backlog. ScrumMasters are in charge of maintaining agile processes and coaching team members through it as needed. And while these roles are tremendously important within the agile team, they do not bestow any authority “above” other team members.

Problems arise when “leaders” take on too much “leadership” within the agile team. Some people will exert too much influence, or simply drown other voices out – whether they mean to or not. This may seem like efficiency at first, but the quality of team discussions will steadily decline. And so, too, will the quality and pace of their results.

Another factor to consider is whether personal issues or conflicts are causing stalemates within the team. Decisions must be made and everyone won’t always agree on the course of action. Usually, this is handled with an appropriate degree of professionalism. But sometimes it’s not. Sometimes, bitterness and resentment linger on, impacting future decisions. When this happens, you’ll need to act accordingly to help the team work through it.

Checking in with team members on a regular basis—as well as making sure the team is holding a retrospective after the conclusion of each sprint—are the best ways to obtain feedback on internal team dynamics. They can also point out external problems such as micromanagement and undue influences.

Assess the level of support from the organization

Agile teams may be self-organizing, but they don’t exist in a bubble. They still need plenty of inputs and resources from the organization. All those touch points become problems if they’re delivered grudgingly, or if the organization doesn’t respect the agile timetable.

At the same time, agile teams can create these problems for themselves if they fail to give advance warning or to communicate properly. For example, if the Scrum team requests a new environment from DevOps, they can’t expect it tomorrow. On the other hand, the DevOps team can’t tell them it’s going to take two months, either. Ideally, the Scrum team will give advance notice at least two weeks before they need the new environment…and within that two weeks the DevOps team will produce what they need. Then, if either of those two conditions fail, you can identify the problem and assess what needs to be done to fix it.

Hold team members accountable for their sprint process

If the problem is that actual production isn’t meeting your plan, you’ll need to analyze your sprint planning process. Are sprints the right length? Are they resulting in shippable product? Does the team decide on the commitment, and not the Product Owner? Are sprints failing because of poor estimates and the resulting lack of motivation from the team? Or is it a lack of support and resources?

Since the team is responsible for making the sprint plan, they should also be held accountable to doing the best they can to execute against it. If this doesn’t happen, then there’s no incentive to make estimates more accurate. By holding the team accountable, you show them that they truly are in charge of their results.

Go back to basics

Scrum is simple but it’s not easy. So don’t beat yourself up if you’re having trouble. Go back to basics instead.

Look at the agile principles, the Scrum guide, and your project management office’s guidelines. Look for processes and mindsets that aren’t being followed. Look for adaptations that have been made. And for every modification or missing process, analyze the impact on your results.

Get an outside viewpoint

It can be very difficult to see a problem clearly when you or your team is at the center of it. That’s why an agile assessment can be the right tool at the right time. At Ascendle, we hate seeing people frustrated with agile when the gears aren’t turning smoothly. We’ve seen agile work so many wonders – and transform so many organizations – when done right. An agile assessment puts all that experience to work for you.

So if you think you’re doing it wrong but you’re not sure where (or if you know what’s wrong but you’re not sure how to fix it), don’t despair. Help really is out there.

Comments