The Agile Architect

Will Crushing Expectations Make an Agile Team Non-Agile? DUH!

We are warning you! Our Agile Architect is in a pretty cantankerous mood. Read this at your own risk.

• By Mark J. Balbes, Ph.D.
• October 10, 2019

One of my colleagues asked me a question so stupendously stupid the other day that I just had to dedicate a column to it. Now don't get my wrong: My colleague isn't stupid, and I'm totally taking his question out of context for comedic effect, but still. Come on!

His question was, and I say this with a straight face as I type:

"Will unrealistic crushing expectations from management make an agile team lose their agility?"

My internal reaction, in the order I thought them.

Response 1: Duh!!!

Response 2: Doh!!

Response 3: No. Crushingly unrealistic expectations from management stimulates a team to become even more agile so they get more done! Doofus!

Response 4: No. The team simply needs to set appropriate expectations by transparently showing their backlog and their forecasts predicting when the work will be done.

As I thought about my unverbalized Response 4, I realized I was the doofus. In what kind of world where management is already unreasonable do you get to pull out your metrics and calmly show them how they are wrong? Life just doesn't work that way.

And so I started asking myself, what is a realistic answer?

Let's start by assuming the team has good intentions and wants to deliver on time. 

Of course, you would try Response 4 first. That's the stock answer. Let's use past data to forecast a completion date. We can cut scope to bring the date in or we can, maybe, add some capacity to the team in a smart way. Everyone who's rational will agree. But managers aren't always rational in our eyes. They have other pressures, like wanting to please their managers, wanting to hit a delivery date promised to customers, or being big puffed-chested bastards who think if they put high pressure on the team that they'll get more out of them. (We've all worked for at least one of those, right?)

So what, realistically can we do? I mean, besides quit.

Real Options
Capitulate. Give up agility. Miss the deadlines anyway and have to deal with all the crap you've created in your wake.

Have the satisfaction of going to your boss after you miss the deadline and say, "Hey, we tried according to the rules of your game and we failed. See, we were right. It didn't work." My, that is satisfying.

OR

Stick to your agile principles. Know that you are providing the most value you can and that you'll miss the deadline by less if you don't give up on agile principles and the technical practices that support them.

This is really hard to do. Here are some of the dirty tricks I like to pull:

Press the manager to tell you how you should go faster. Likely (s)he's going to tell you to give up pair programming, automated testing and/or test-driven development. I like to counter this by saying something like, "Yes, we can do that. We'll add 30 percent to the estimate for that." When they push back on adding time to not do things, that's the opportunity to explain that any time savings on the front end of the schedule will be more than offset by the extra time needed for testing and bug-fixing at the back end.

Start challenging the requirements. Use a scalpel not a sledgehammer. A lot of fluff can be trimmed from requirements at a level that upper management won't know or care about. Of course, the product owner needs to be in the know. Hopefully, they support you.

If the product owner doesn't support you, interpret the requirements as minimalist as you can. If the product owner complains, let them know it'll be their fault if the deadline is missed because they are increasing scope.

Force prioritization of the work. If management won't do it, then do it for yourselves. Make the prioritization extremely visible so everyone can see. Hopefully, this will generate some management displeasure that leads to a more productive conversation.

Final Thoughts...
Sticking to agile principles under pressure is the real test for an agile team. We know more about our craft than non-practitioners. We know that what might seem reasonable to the casual observer is actually quite unreasonable and vice versa. So stick to your guns and don't capitulate. Duh!