TPP #008: Exceptional Agile

Hey there! 

• Why agile teams make exceptions in their process 
• What happens when you make exceptions 
• And how to start dealing with underlying problems 

Exceptions just delay conflict

I’ve worked with dozens of different agile teams. 

And they all had one thing in common. They all had exceptions in their process that went against well-established principles. Almost like having a game with “house rules.” But these exceptions never came from trial and error. That is, they were not improvements to the teams’ process. 

Instead, they were like pain-killers for some underlying problem. 

And that’s because, it’s easier to make an exception than solve the underlying problem. 

Underlying problems like: 

• The business isn’t bought into the process. 
• Stakeholders don’t know how to get what they need. 
• Your team lacks the skills to do what the business needs. 
• The people responsible for making decisions don’t know what they want. 
• Etc. 

Because solving these big problems is really hard. 

First, you have to involve other people. And you have to convince those people to think or behave differently. Which means describing a different future, and path to get there. Then you have to execute on that plan. All while keeping everyone aligned and on board. 

It’s really hard! 

Just ask yourself which is easier: 

1. Get business stakeholders aligned on a strategy and roadmap. 
2. Accept late additions to the sprint and change priorities every sprint. 

If you picked option 2, you’re right. That is easier. 

But it’s not going to help your team. 

Exceptions lead to mediocrity

Making exceptions in your process leads to mediocre outcomes. 

The path there will be more comfortable, for sure. But the outcomes will not be great. They may not even be good. 

Just acceptable. 

That’s because most teams make exceptions instead of trade-offs: 

• Allowing new work mid-sprint. 
• Skipping retrospectives to get more work done. 
• Decomposing work into functional areas to save time. 
• Relying on requirements documents instead of focused planning. 
• Etc 

So, while these exceptions are easy to do, they produce mediocre outputs. 

Seek compromise through trade-offs

You’re tired of making exceptions. 

You’ve been pushed to your limit. 

You’re unwilling to bend any further. 

Now what? 

To get back to a principled and disciplined approach to building software, you’ll need to dive into some conflict. 

But let’s break it down into three actionable steps: 

1. Identify the underlying problem – Use a technique like “Five Whys” to get to the root cause. Work with everyone involved to identify and align on the problem. Clearly define what the problem is and how it impacts the team’s outcomes. 
2. Come with solutions to resolve or improve it – Do not wait for help to arrive. Actively propose and experiment with solutions to resolve or improve the problem. Maintain a bias towards action. 
3. Find a compromise where everyone has skin in the game – When the problem cannot be eliminated, seek compromise. Look for areas of natural tension and come to a conclusion that requires each side to “give a little.” 

Clay’s Notes

My key takeaways are: 

• Don’t avoid conflict, embrace it 
• Mediocre teams make exceptions 
• Great teams discover trade-offs