Anyone who, like me, has been lucky enough to have straddled the border of the artificial IT vs. business delimitation in their professional life, and see Agile being implemented in both in various ways, struggles to understand how come some things are so easy in some Agile teams and so impossible in others.
How come some gleefully get on with it while others moan and whine?
Why are some instantly in love with the freedom and speed it offers while others are paralysed by the change and daydream of retirement?
Why is it that some companies seem to have it in their DNA at every level whereas others seem to be in a dreaded continuous “transformation”?
One of these is about wondering how come some people struggle with the way work is divvied up, -in particular, the self-assignment aspect of it- and some people just get on with it.
The contrast between a team of developers joyfully -or at least calmly and naturally- grabbing tickets off a board, plopping on some headset and setting off to get stuff done versus the hesitance, endless semi-conflictual talks and impression management happening in sprint kick-offs in Marketing or HR departments of companies rolling out Agile to business roles, is staggering.
There are a few complex reasons why this is, from the expectations of organization and the disjointed implementation of Agile to the environment having been traditionally cut-throat and competitive in these departments and antiquated performance reviews and unexamined KPIs do not help, and many others in between, but I do wonder if a lot of it doesn’t hinge on ego and a hefty dose of Impression Management.
Hear me out.
In a developers’ team, when people grab tickets, how much judging of their speed, skill or capabilities is there with it? Will Developer #1 sit at the back of the room (or in their chair in front of the zoom screen) and think “Look at Developer #2 having taken that ticket! He can’t do that! Not well and surely not in time! He just doesn’t have the skills! What is he playing at? What is he trying to prove?!? This will delay the whole thing! Ohhh maybe he’s doing that because performance reviews are coming up and he’s trying to impress the Scrum Master! I was gonna grab that other one but I have to shoot for the more complicated one now, I’m the superior programmer here and I won’t let anyone forget it!”.
Unlikely.
Will a version of that go through the heads of business users of Agile? All. The. Time.
You could say “well that’s just not a team if they think that way about each other” and that’s very true – ego has no place in a real team and having any impression management (fear of appearing negative, ignorant, intrusive or incompetent) at play, is always detrimental and kills Psychological Safety, as we -hopefully!- know, but outside of the self-evident value of that, we need to take a look at the individual ingrained competitive levers that disallow us to truly apply ourselves to this way of work.
For Agile, you have to be, among others:
- Wide Open;
- Fearless;
- Collaborative To The Core;
- Willing To Fail And Learn;
- Passionate About Making Amazing Things Fast;
- Ego-less, Un-Impression-Managing.
and let’s face it, those are not the first adjectives that come to mind when we describe Samantha in Marketing or Julian in HR. This doesn’t mean it is Samantha’s or Julian’s fault. Far from it. It is simply a function of the type of interactions that had been desirable in that group in the old ways of work and therefore make up the sum total of their experiences.
In software development, the vibe (I can’t stand one more mention of the word “culture” so can we please use this?) is vastly different than in “business” departments as the need for knowledge and collaboration are inbuilt in the way developers actually produce code, the speed of technology and the nature of how the business uses them dictates they have to learn all the time. At break-neck speed. And they are many times more open to criticism than many other areas of the business – what would happen if they would throw a hissy fit for every tester who finds a bug or every code review?
In business there is no equivalent to “test-driven development” or “pair programming” and while there should be, these types of practices are all deeply seated in the work DNA of a developer which means ego has no place.
This doesn’t mean developers don’t impression manage, far from it, if I had a penny for every example of behaviours that make developers’ teams psychologically unsafe, I’d be telling you this over rose on my yacht, but the levels are nowhere near the way they happen in other departments.
Depending on whom you listen to, one by one other functions of the business from Marketing to HR and even Ops and even Finance will tell you that “what we do is different though” so they need waterfall. This is to claim that the nature of their mandate forces intrinsically waterfall-y projects.
That’s of course poppycock – there’s no part of the business that can not find ways to iterate, test&fail, learn to live and breathe by the feedback of the consumer and rinse and repeat that on say a Kanban board. So the nature of the projects is not what is holding them back.
The real culprit, again, is mindset and ego.
As a practical takeaway: if you’re serious about Agile enough to see it succeed in permeating the entire organisation, take a look at the methods and practices that are state of the art in software development as they’re dripping with blessed inbuilt goodwill, thirst for knowledge, willingness to make (arguably “too many” but that’s another post for another day) mistakes and true, ego-less collaboration.
If we are collectively well and truly as seduced by the promise of Agile as we claim to be, as part of our massive work of change to modify the way we think, not only the way we work, we must take good, long, inquisitive looks at our own selves and see when we engage in any impression management and become more and more Psychologically Unsafe because the alternative is that we will never be able to think, feel and do Agile otherwise.
