We Are Agile - Let Us Count the Ways

***Warning the following can read very self-serving but it’s really just our reminder of how fortunate we are on what is a periodic self-reflective Agile audit we hope everyone does at times, so if you just wanted to read a rant or some solid practical tips, maybe come back next week.***

This week’s articles on our Chasing Psychological Safety newsletter were about two things: lessons thanks to being Agile and servant leadership and I wrote them both as an experiment. 

You see, last week, multiple people were rather surprised when they realised I was writing two different newsletters. These were awesome people who were up to date with what | was writing week in and week out but on only one of the two. At the risk of sounding both immodest and naive, I had assumed there’s almost complete overlap between subscribers which is why I was double-careful not to repeat topics ad nausea and to adapt the tone to the topics. That assumption was wrong, but thinking about it, it’s not strange, as even if anyone finds my writings through some magical place that says “For clarity: Duena writes 3 times a week in these 2 different newsletters - Subscribe to both” - once people click on one, they won’t go back to look for the other. Before you wonder why I’m not simply checking the data to confirm or infirm this, it’s because LinkedIn offers no visibility to analytics of any kind when it comes to Newsletters. 

As for the experiment, it was yet another one relating to my theory that we’ll never be able to quickly pay off some of the huge HumanDebt? we have amassed before these two sides of “the people” coin - HR and IT (namely DevOps) start truly working together, so I wanted to see if those two topics, which would have seen a lively discussion here, would be creating as much of a buzz on there and unsurprisingly, proving what I was fearing - they didn’t.

Monday’s one was telling the -step-by-step- story of how we kept adapting our product to valuable customer feedback until we realised we ended up making an “accidental servant leadership development tool”, whereas the one on Tuesday has a video on how those feedback-ing customers had deep insights into why this new leadership mindset is essential. 

Why does this matter? 

For one thing, we’re always learning from both communities. Always asking, probing and wondering keeps us churning new stuff at breakneck speed in the product, but we are also conscious that the revelations we are lucky to arrive at, should be fed back to the communities that inspired them, so we can perpetuate learning. 

Then, we’re big believers in self-awareness and reflection and of living our Agile reality mindfully not in virtue of inertia, so here we talk about it in the hopes that it helps others see reasons to do it as well, So allow me to brag for a moment and tell you what 10 things are true for our team today. This thankfully -and self-servingly- will also make for a cultural anchor, and keep us honest as we’ve created accountability, and in case we ever lose our Agile way or any of these stops ringing true, it will help us remember that we should stop, inspect and adapt and -probably- conclude we should return to them. 

We welcome courageous and creative tension. From our very name -which is controversial to some before we explain it is intentionally self-ironic for a software company to be called “PeopleNotTech” and we acknowledge and welcome the raised eyebrow as it sparks a meaningful discussion-, to every debate over the importance of Psychological Safety we ever had with a client, it all encourages dialogue and creates the space for improvement. In the same vein, we always frankly call out what we see as HumanDebt even if that shouldn't make us popular.

We regularly do or measure things that we don’t even know demonstrate agility till we revisit them. We’d look back in a retro and realise we’ve had a “manifesto-like” epic without setting out to do that at all. 

We're rich and lucky. We have so much honest and open customer feedback from such diverse industries that our Backlog prioritisation is mostly an exercise of weeding through the commonalities between them to inform our design decisions. 

We experiment incessantly and only get features in after we’ve A/B tested them these days. To quote John Cutler we “think big and work small” with MVPs completed once every few sprints. 

We move so fast in executing even the big changes that we don’t even mention all new things and even have no pre-pivot screenshots at times. While that’s regrettable and we should do better so we see how far we’ve come and how our story has evolved with clear visuals, it’s an indication that we run fast. 

We thrive on this speed of change and it reinforces the feedback loop because when it satisfyingly closes, both in the software -from data to action, to then interventions and improvement - and in our development -when our recent major change or new feature goes back to the clients that inspired it and they put it to good use- it powers us to keep listening and caring. 

We eat our own dog food -on both accounts, Psychological Safety and Agile. We use the software to measure how much Psychological Safety we have ourselves and obsess with it in every meeting, trying hard not to ever impression manage and always speak up. We are also quick to mercilessly point out if any of us slips into sequential thinking, toxic corporate habits or an -understandable but destructive- need for extensive roadmaps.

We have a mission we arrived at organically. We didn’t start out from any theoretical point of view beyond the firm belief that having Psychological Safety is fundamental to team performance, but we understood and embraced some other rather major facets of the North Star since, such as the importance of the team bubble vs. the organisation; or how improvement is at the fingertips of ever-learning, emotionally invested teams and that makes them autonomous; and how what we aim to do so that we make teams happier and business better, is bridge the gap between IT and HR to lower the HumanDebt.

We’re having fun doing it. I speak for the entire team -I hope!:) how ironic would it be if in the Retro they either hadn’t read this as they hadn’t subscribed themselves, or they disagreed with this point -thankfully I’ll hear it, either way, no holding back and tongue-biting in our meetings- but doing things this way, is immensely satisfying and addictively pleasant. So much of our working day keeps us in flow thanks to it and we employ so many of our individual strengths on a daily basis, that it makes our lives better. 

We’re so grateful it keeps us grounded. We realise we’re very fortunate to be making something we believe in with all our hearts, something that effectively changes the lives of the employees and betters the business in general at the same time and also to be this close to hearing how our customers perceive it through our deluge of feedback. Most people don’t have that luxury and hearing from those who don’t and have to instead live through waterfall and HumanDebt filled purgatories is very humbling indeed. 

Our relationship with feedback is one of a loop so tight, that these days, almost nothing on the backlog is something we thought of a prior, with no data or persistent needs being expressed by the teams we work with. Whether you call it client-driven design, crowdsourced product solutions or efficient common sense, it makes my Product Owner heart sing. 

Don’t get me wrong, we don’t use each and every suggestion or rush to fulfil any request and we do say “no” -“No” we will never turn into an organisation level HR overview tool; “no” we won’t include all other enterprise libraries indiscriminately to make some department tick a box; “no” we won’t allow anyone to see how any team member responded in particular and destroy the safe space, etc- but even having had these requests and knowing we stand firm on our stance forces us to always reexamine it and teaches us a lot. And some times, customers don’t know why they’re asking for certain functionality in particular -although you’d be surprised how many ask for a very specific button, tab or data set:)- or they plain out ask for something that would do them a disservice, but if we isolate the need and comprehend it intimately, we end up creating a feature or use case that solves it in a different way.

Someone asked me earlier this week why do we even have this “eradicate HumanDebt” mission? What practical business sense can it possibly make? Wouldn’t we be better off, as the makers of a software solution to that very problem, to simply pretend it doesn’t exist, adapt our message to the two sides instead of trying to bring them together and give each the features they think they need? Practically they wanted to know why we don’t keep the two communities separated to propagate the issue, as that would be maximising our business value. And the answer is that we couldn’t do that, not only out of a moral imperative but because doing the right thing pays off. We probably do sell less software for not doing what they were suggesting, but sticking to our “noble” stance is a price well worth paying so that each and every one of us sees both “meaning” and “impact” -to use the terms the Aristotle Project included in the top 5 conditions for high performance in teams-and so that we keep making awesome stuff. 

We wish this on everyone! It’s hard at times and frustrating at others, keeps us firmly out of our comfort zone and increases our resilience on regular basis but it’s the most satisfying of hard work I’ve personally ever done and I think that stands for the brilliant minds we are lucky enough to be either a team or be teaming with. 

————————————————————————————————————

Don't send your teams home with a laptop, a Jira and Slack account and a prayer!

Get in touch at www.psychologicalsafety.works or reach out at [email protected] and let's help your teams become Psychologically Safe, healthy, happy and highly performant.