Unstructured and Unclear Musings About Agile Teams

At PeopleNotTech we always have a full design backlog. While we’re still working hard on designing the “EQ Trainer” feature in our team performance Psychological Safety solution, as a PO, I always try to slide in incremental design exploration tickets for other upcoming major bits and pieces just in case we manage to turn any of the ideas into a proof point or an MVP. I’m telling you this because one of the tickets is a “Project Aristotle Pack” which we’ll get done sometime in the future and as we sneak some exploration, we get to think about it a lot and one of the topics I find fascinating with my Agile anthropologist hat on, is how Google’s findings map to what we see in the field in other industries and non-digital-native non-VUCA-ready places.

Please note the following is the opposite of last week’s reality-connected exploration in that it joins the “emperor is not naked, let’s go on holidays” vibe and discusses the topic in theory, disregarding the fact we’re still 2020ing. 

We knew we thrived on structure and clarity before Google told us so at the end of their massive research on what makes teams successful, but I wonder if we had stopped to wonder what kind of tension this need brings when we’re Agile. 

Let me explain. 

Let’s start with the easier one - “clarity”. At a superficial level, where we simply need to be clear on roles and purpose it is attainable and a hygiene issue. Just communicate and over-communicate on everything from roles to expectations and we’ll be fine. 

But what if we need more than that? If we actually need full, complete visibility? To everything. Every rationale, every decision, every sharp-turn motivation, every instinct, etc? What if, to be truly invested each and every member of the team needs to read the product owner’s mind? Or that of higher management if decisions on the product are centralised that way (although I hope that’s rare!)? Or that we need to understand intimately the thought process of anything of consequence to genuinely rally behind it. 

Rapid change is the essence of what Agile is about. Ideally, it’s there to facilitate building good things fast, but this is not always evident how the change maps to the building and when that becomes obscured it makes things harder. How much clarity and visibility do we really need is the question. And also, shouldn’t we need them less the more flexible and resilient we are? I don’t have answers or formulas - just a suggestion that you should think about it. What it means in your actual bubble. How much is needed, how much is given? 

When it comes to "structure", it’s tempting to say Scrum (or any other corseted flavour of processed Agile (TM?)) takes care of it but if we’re truly Agile at heart and willing to question and adapt everything, it doesn’t really, does it? Or oughtn’t. 

So does that mean that we don’t actually need them and they were wrong or that it’s all in the definition and if we can extrapolate them to frameworks only at a superficial level without wondering what that actually says about our Agile minds and hearts than we’ll be fine? Maybe the latter. 

How the team experiences these and to what degree and how it rhymes with agility may be less straight forward but I like to think of this one as Google’s answer to the topic of leadership - so much is being lyricised about the opposition between “command and control” and “servant leadership” and there’s so much ignorance around EQ and “fluffy” human topics that many take the latter as it being the hands-off, laissez-faire side of management when instead, it still never excuses a lack of “leadering” with the structure and clarity that needs to bring.

Structure and clarity are only two of the 5/6 elements Google identified for high performance alongside “dependability” - funny one that, it needs its own exploration, let’s talk about it some time- and “meaning and impact” - which they strangely list separately, not a logical conceptual delimitation to my mind- with the main one, of course, being “Psychological Safety” and that one we have you covered on just shout, as it’s a lot of deep work and utterly unavoidable. 

All the clear visibility and the solid structure in the world won’t make a difference in a team that has low levels of Psychological Safety so fix that first. 

If you're still reading (doubtful) and your head is spinning from thinking of the many Aristotle nuances and crave a “doing” to cleanse the palate, take a look at this article and this video we put out earlier this week in our other newsletter about a few tips and tricks including organising a B!tch Fest to prep the soil for Team Relaunches and start on the high-performance work and feel free to add an eye-roll around “What really got my goat was… how we’re still 2020-ing hard but we take the time to indulge in sterile explorations of what does structure and clarity mean in Agile teams”.

--------------------------