Be still (fr)agile heart

The story of the head and the heart

Spurred on by Duena’s many amazing articles on agile (here, here, here, and here), in particular about not being able to do agile without heart, coupled with my own experiences of the fragility of agile implementation, I wanted to write my own story about the struggles of the head and the heart.

I speak often that agility can’t be born without true understanding of what we mean by agility, which in turn brings about true engagement and true buy in to the endeavour.

This is still true as without these it’s faux transformation wrapped in the framework trap (see Matt LeMay’s great article here) and jargon hunting — the end result is a shadow of its potential.

Though another related realisation also dawned on me — moving towards agility is scary as hell and doing it properly is really, really hard.

The story of the head

Working with agility is hard because you need to be comfortable with challenging your assumptions, states of affair, your “this we know for sure” foundations — every. single. day.

You need to react and change to every single environmental factor, from user feedback (yes, this is actually important) to measurable business gains (yes, these are also important), and every single bit in between including the dreaded “My VM went down and I can’t do anything”.

These are immense calculations that are required of the human brain to be able to constantly (re)re-reprioritise and to still be able to gain traction, build momentum, and deliver valuable outcomes to users and the business.

And because the calculations are constant, continuous, incessant, it’s really difficult to keep up and maintain momentum without falling into a fatigued state.

You’re not only managing the team dynamic and work flow, as well as the throughput, work to be done, work in progress, and x number of environments and sets of testers — the “sausage machine” — you also need to be able to make tough decisions like stopping mid-sprint to respond to a priority issue and fix something of more immediate value, or to push against a new stakeholder feature while trying to explain that it’s a nice to have, even though they believe it’s the one and only thing they need.

You need to decide whether that bug will be fixed now or later, does it block the release of a whole feature or can we fix it in an upcoming release.

You need to keep in mind that there is no such thing as phase two and stakeholders want what they want not just what they need, because to stakeholders they are one and the same thing.

All the while you still need to actually get things done, the business as usual of development, the day job, the actual sprints or next-off-the-line ticket preparation to make sure developers have something to build and testers have something to test.

But then you need to explain and justify why stakeholders and programme leaders can’t have it the way they want it, though shouting “You can’t put everything in the world into a deadlined plan and expect it to just be delivered,” yields no results.

You need to be able to explain to stakeholders, sponsors, programme change boards, the Board, and senior leadership why the scope has changed, why deliverables are delayed, and why they’re not getting what they signed up for on the five year plan they developed two years ago.

You, by the way, are the whole Team, Capital-T.

We’re in this together.

And that’s why agility without understanding is disastrous — because it’s them (the business and leadership) versus you (the vogue agilistas).

But actually, we, together, need to do all of these things.

We need to be in it together and it’s difficult.

It’s really difficult.

And that’s one why agile is blamed when it doesn’t work as easily as we’ve got daily stand ups now, so we’ll now start delivering at lightening speed and at a fraction of the cost, yay!

Execs doing agile for the first time invariably end up finding a deep-seated fond nostalgia for waterfall because it feels safe, easier, it’s more structured, planned up front and delivers what it said it would (and if it doesn’t, you can blame someone!).

But waterfall only feels “easier” because you assign accountability to everyone else to deliver your plan and hold them accountable to those expectations, regardless of how flawed or impossible planning a project of scale with any semblance of certainty really is.

Then, the dirty secret, you end up with a few dozen change requests and the politics of arguing about who’s going to pay for missed requirements.

Oh, the business requirements have changed since then as it’s now three years later and your product is now irrelevant.

But actually, we’re all responsible, you’re responsible.

There’s no accountability in Team, but Teams can and should be responsible.

When you remove responsibility all that’s left is accountability, and accountability breeds containment and risk averseness — that wasn’t in the original brief / that would require a change request / you didn’t put that clearly in the statement of work…

Responsibility, on the other hand, is what drives us to strive for greatness.

So, why can’t you do agile or work with agility without heart?

Because the heart holds the courage, and you need bucket loads of courage to be able to make yourself and everyone around you responsbile instead of accountable.

The heart

Working with agility and “doing agile” needs courage.

The courage to look ahead and see the turning of the tide and plan against change rather than counting on pie-in-the-sky certainty.

The courage to accept that the budget you planned looks nothing like the scope you planned.

The courage to know that you control time, quality and cost and that these are not place in time calculations, but rather a constant wrestling match to gain the most value from the least amount of cost.

The courage to understand that working with agility allows you to deliver the most contemporaneously relevant value to end-users.

The courage to know that Teams are organic ecosystems and not production meat machines, and that you need to treat them with empathy and humility.

The courage to truly trust in the honesty, integrity and abilities of your Team.

The courage to believe in your Team.

The story of the head and the heart is one of the ability to do (the head) and the courage to believe (the heart).