I got something along these lines from two different CTOs over the last few months: “I love what you write and I read it religiously myself but I stopped sharing it internally, it’s demoralising to eternally go back to basics and clubber people over the head with how important it is to be doing it from the heart and as a way of thinking, that was needed while we were changing but it’s been years now, it’s done, we’re Agile, we got it, we’re doing it, we’re living it every day, do we have to keep talking about it?”
While -as always- very grateful for their honesty, I have to admit it made me pause. Do we? Have to “keep talking about it”? When it comes to Psychological Safety and our work on that, we’ve accepted that it’s new and it will need years of awareness-raising, so it’s likely we will be saying the same things over and again way past the time when they are just applied common sense to most, but in Agile’s case it has genuinely been tens of years of having it around and it is so much more than just a concept, so does it need the constant advocacy? It does. We do. Need to “keep talking about it.” Here’s why.
Not only is the proportion of the enterprises who “have it at DNA level” low, but it’s also a non-set-in-stone, precious and fragile thing. This is a different kind of fragility than the term we use to accuse clear anti-patterns such as rigidity of process or trying to hide tech debt, but it’s there nonetheless and in some ways, it’s more insidious as it refers to how easy it is to lose one’s way.
Consider how long Agile has been around. Why isn’t it “IN-IN” and why does it at times falter? Because as long as we still have so much HumanDebt™ we can’t have it “in-in”, there was too much impression management for people to reject it explicitly if they needed to at the beginning, there was too little Psychological Safety to acknowledge the times it hasn’t worked out and mistakes were made, there was too little sense of team magic to really feel the times when it went well and did what it said on the tin intensely. There was too much fear and too little sense that the team deserved any of the joy of running fast together. And too little real organisational permission. Too wobbly of a commitment to change. Too scarce of real support for a new way of thinking that transforms our very thought.
And it may also be that our intellectual “set-point” is waterfally after what would have been most of our professional lives for most of us. Even the most Agile of us. The charmed structure of it all, the perceived comfort of requirements and stages and planning, it’s all familiar from our long “other lives of Prince” and it’s enticing when we’re tired. Command and control play right into our organisational Stockholm syndrome so yes, we still crave it at times. Continuous learning and improvement can feel exhausting, even if fun. And it’s not that when we’re burnout, or wary, and we wake up one morning and decide not to be Agile that day or to go back to our old ways of thinking, no. It’s a lot more insidious than that. We’re a little less excited for new here or there. A little less understanding of sudden changes. A little less interested in the impact. A bit too processy. A tad too keen on automated piloting. A smidge too unengaged and less inclined to be fully honest and open.
If we pay attention we can all always recognise when we slip Agile wise, we feel it in our hearts of heart that we let some essential fundamentals slip here and there in how we thought about them, there’s always that niggly feeling that it was wrong when we feel any of the above, but not everyone has the time or the EQ to be in touch with their inner Agile superhero and feel that hero slipping. I’ve written about slipping leaders before but we can all do it.
Just as we don’t hear anyone with a real self-care practice say “Nah, I’m good, no need to meditate again, got some good sessions in last month” – “being Agile instead of doing Agile by numbers” does need us to be present and intent on staying so at DNA-level, it needs mindfulness and it needs the constant, conscious effort, so talking about it is necessary yes, even if it has us loathe the repetition at times.
We have a play in our Playbook called “The Catch Yourself” Counter” and it’s built to aid against Impression Management (the negative behaviour of Psychological Safety when team members don’t speak up for fear of being perceived as incompetent, ignorant, negative or disruptive). In essence, when a team notices that Impression Management Alerts go up on our Psychological Safety Dashboard they are to get in one of these sessions where they reconnect to what it is they need to look out for and start being alert to recognise the behaviour and “catch themselves” next time when they engage in it.
The same principle applies to “being Agile” – we can and should all have an internal mental counter to stop ourselves from ever being “waterfally” and slipping. Better yet, do it as a team, confess when that abrupt change got on your nerves, admit you thought about covering up a mistake, tell your teammates you’re in no mood to be vulnerable or eternally “undone” this sprint. That you’re temporarily unbothered by what the end goal is, or what the customer wants. That you’re envious of the people who coast and function as if it’s 1990, clocking in and out, writing code they don’t know the point of, and spacing out in long requirements meetings for a paycheck. That it’s been hard. That it’s taken effort. That you have had to subconsciously recite the manifesto to yourself to keep yourself going. And remember the point of fast and better and magical.
If you do both the counting, the catching yourself and the sharing with the team, yes, you would have been on and on about it still like an apparently broken record, but it will have guaranteed been worth it.
And because we don’t know each other from Adam, this is not yet another thing I’m just talking about, we’re living it, we’ve just traversed a couple of really intense sprints at PeopleNotTech (all worth it, an awesome new front-end and courageous principles applied at the end of them) and I am looking forward to our next retro and next team action because I have had to resort to my own “catch yourself unAgile counter” a fair few times so I have no doubt all of the team did as well, as none of the discomforts we traversed would have ever happened 20 years ago in a waterfall project.
Lastly, this week and in preparation for my book dropping next month, I’m adding a video to this – it’s where I’ll keep the examples, anecdotes and more extreme rants, as well as the saccharine sweet DevOps superheroes, fanning. This is Ranty/Soppy Agile Tales.
The 3 “commandments of Psychological Safety” to build high performing teams are: Understand, Measure and Improve
Read more about our Team Dashboard that measures and improves Psychological Safety at www.peoplenottech.com or reach out at firstname.lastname@example.org and let’s help your teams become Psychologically Safe, healthy, happy and highly performant.