I’m Agile, Therefore I Ask

If you read nothing else about Agile this week then read this article entitled “The Death Of Agile?”. It’s so amazingly well written, clear and heavy with personal experience that it will make you think. Guaranteed. 

Amongst the many clear points, Mike Loukides makes, the all-too-ignored topic of feedback loops.

“Agile is not, and never was about getting developers to write software faster. (Scrum might have been…) Agile is about getting developers in touch with the people who are the actual users and customers, regularly and repeatedly, so that the project doesn’t inevitably wander off course and produce something (in the words of Douglas Adams) “almost, but not quite, entirely unlike tea”.

Ask - but who?

How remarkably true. The biggest obstacle there is that, with the exception of the teams that are in one of the famous digitally native Valley set-ups that wrote the playbook on how to organise and self-organise with an Agile mind and heart, the rest of us have had to, at one point or another, make a clear decision as to whom the customer was, ideally following careful consideration because how are we meant to always ask for feedback if we don’t have whom to ask. And I put it to us that we have woefully skipped that step in many teams. I have often written about “You Can’t Have Agile If You Don’t Have A Customer” and I stand by the damnation and sadly see it in the field more often instead of more rarely these days. 

In particular in organisations where Agile was rolled out as a consultancy deck and without any real examination, employees everywhere would struggle to point to who is it that they build something for, or should serve, starting with the inability of discerning between internal clients and external ones and often relying on pointing to the end consumer of the organisation despite their work having nothing to do with them. The amount of times I’ve met teams telling me when challenged that “we have often user surveys in our company” when not only were they unaware what that entailed but their work having nothing do to with the end consumer, is staggering. 

Ask - but how?

For reasons that stem from organisational structure and the gap between what we have and where autonomy should land, teams everywhere are deprived of feedback from the actual user if they even know who that user is. 

If we were to poll most people working in Agile teams as to what their feedback gathering mechanisms are, the answers would be worrying. Most teams have none. The ones that do rarely were involved in the process of creating them and as a result, blindly accept limited information and measurements that are unhelpful. That is if they pay attention to them at all and realistically they do not after a while so the entire premise of finding out what works and what does not is out the window. 

The only way that a communication channel with the consumer is valuable is if it has been designed by the team that delivers for them and if is protected and reinforced at all costs, obsessively.

Ask - but how often?

The first principle of Agile is the frequent interactions but unsurprisingly there’s no predetermined answer as to what that means because that too ought to be part of the design that pertains to a respective project if not the team. 

A good guiding principle ought to be “often enough to make a difference” i.e. to allow necessary and blessed mid-course corrections. If that means once a story, once a sprint, once a feature, once a month or once a near-crisis, that’s personal and varies but the point is in instilling the repetition, the curiosity and the openness to do it “a lot”.

Why don’t you just ask, FFS?

Here’s an insidious and yet all-encompassing reason as to why the entire feedback process is broken - at times we don’t want to know. Mid-way course corrections as described above are often unpleasant if not downright painful and we are all overworked and tired so there’s a lot of appeal in just taking the advice on all those mugs of tea and “carrying on” avoiding any information that may inform us we should have changed anything. 

The only antidote to putting blinders on is reminding ourselves that should something truly have jumped off the rails and we’ve ignored it, the impact when we inevitably crash and burn will be massively bigger if not lethal as compared to having stopped, examined, asked and built new tracks ever so often when we hit a bump. 

Lastly and I would say this, it seems to me (and one day we would have amassed enough data to prove this, we do keep asking) that only Psychologically Safe teams ask and that’s because they have the empathy, courage, resilience and flexibility needed to do so and to trust that together they can and will, not only course-correct but find new and exciting paths so that everyone’s happy. 

And seeing how I’m writing this from paradise (in Mexico for the IT Masters Forum where I’ll be keynoting about the WoT (Way of Thinking) to get the WoW (Way of Working) tomorrow, come say “hi” if you’re reading this and will be in the audience) I have to add that it’s not all doom and gloom and when we have psychologically safe teams we will have natural asking because they can afford to gather honest feedback and they relish what awesomeness they can build together.

So if you want to win at Agile (and one final point Mike makes that is sublime is that Agile would have succeeded when we forget it exists and just do it) get yourself a customer, design and protect that communication channel at all cost and then be psychologically safe enough and team enough to obsess with the asking.