I’m Agile, Therefore I Ask

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.

Igor Volovich

Security Strategist · Ex-CISO Invensys, Schneider Electric · Security Shark Tank? Winner · Startup Founder & Advisor · Creator of Converged Continuous Compliance?

5 å¹´

The last point brought it home: It all starts with TRUST. If teams are afraid to ask questions, if their leaders don't make them feel safe, if accountability is only seen as liability, then don't be surprised to find functions cocooning themselves into silos, producing "solutions" to problems that don't exist for those who don't need them.

赞
回复
Carolina Marin

Liderazgo de proyectos y operaciones con un toque innovador | Logística | Planificación estratégica

5 å¹´

Wow.... You are right, it is a great challenge to have a team that is emotionally safe. Thanks!!

Maisha Frederickson

Senior Manager Global Learning at Allstate

5 å¹´

Yes! This is the crux that determines if an Agile team will be successful!

I want to clap 1000 times but that's not possible on LinkedIn ?? Great article Duena. I'm always surprised by your thought streams and how you manage to convey your message. Are you sure you're human?

The issue that Duena shares are very common in large development projects. The end customer is typically multiple with different needs, tied into contract delivery and pre sales negotiations. To sort this out the use of Product Managers becomes important but they are internal and not really the end-users of the product/s. The result is difficulty in proving the right feature set. The feedback loop is the other area I have seen time and time again in development where the lack of the mechanisms that really check if the product development is on the right track and course correct is a constant problem.

要查看或添加评论,请登录

Duena Blomstrom的更多文章

  • Why DEI Must Stay: The Differents, the Regulars and the Intersections

    Why DEI Must Stay: The Differents, the Regulars and the Intersections

    Intersectionality: The True Foundation of Safety and Inclusion Navigating multiple views of neurodiversity whilst…

    17 条评论
  • How We -May Have- Killed Agile and What to Do to Revive It in 2025

    How We -May Have- Killed Agile and What to Do to Revive It in 2025

    It’s a new year! Whilst I’m cautiously optimistic that it will be a happy one, I’m also a realist so therefore a big…

    5 条评论
  • DevOps Knows Better but Doesn’t Do Better (Yet?)

    DevOps Knows Better but Doesn’t Do Better (Yet?)

    I haven’t said much in a while for a few reasons - some are good as we are developing cool things - a Belonging tool…

    2 条评论
  • Is Psychological Safety Dead?

    Is Psychological Safety Dead?

    We may have killed Psychological Safety y’all and it may not return until the “new guard” takes over completely.

    5 条评论
  • Is Psychological Safety Dead?

    Is Psychological Safety Dead?

    We may have killed Psychological Safety y’all and it may not return until the “new guard” takes over completely.

    7 条评论
  • The RTO Trap: Ignoring Data and Humanity Will Cost Companies Their Best Talent - Do They Care?

    The RTO Trap: Ignoring Data and Humanity Will Cost Companies Their Best Talent - Do They Care?

    Let's be clear once more: this whole "return to the office" (RTO) charade is absolute insanity. In this (exceptionally…

    3 条评论
  • Forget "Founder Mode" - try "Human Mode"

    Forget "Founder Mode" - try "Human Mode"

    I’m very lucky. I get to speak to incredible people who tirelessly think and feel all day.

    1 条评论
  • Oh no, “Agile is Dead”! Again.

    Oh no, “Agile is Dead”! Again.

    I've been trying to avoid joining the "Is Agile dead?" conversation that pops up repeatedly, as it has once again on…

    16 条评论
  • Open Letter to all the Frightened NeuroSpicy Leaders Still in the Closet

    Open Letter to all the Frightened NeuroSpicy Leaders Still in the Closet

    (Cross posted to both newsletters if you're both in Technology and HR Leadership) Hi there, you ok? Can you believe it?…

    8 条评论
  • Becoming an EQ Shop to Stop the New Burnout Wave

    Becoming an EQ Shop to Stop the New Burnout Wave

    Isn’t life quieter when I’m not "in your ear" moaning about the lack of Agile and the lack of care about the roaring…

    1 条评论

社区洞察

其他会员也浏览了