The changing face of, er, Change

So, I write a bit on LinkedIn from time to time about the things that interest me in my job: Business Analysis, Agile, Data. But one thing that I've been getting more and more interested in over the last couple of years is Change. I mean, I've always worked in delivery teams, more often than not on the more functional or technical side although I have also done business change and process re-engineering. Change programmes though, big organisational ones, always seem a bit dull don't they? Very corporate. People in grey suits being overly enthusiastic about some motivational posters they're putting up in the boardroom. "Hey, everyone gets a biro and a pad with the name of our project on" - they have names from 70's sci-fi like Spectrum or LASER. And there's always folders, lots of folders, full of paper that people just carry around from meeting to meeting. To keep the plan for the plan to create a matrix of plans close to hand. Snore.

The first time I even heard of change as a discipline, incidentally, was about twenty five years ago when a senior manager at one company I was at was moved into that role and nobody in the office knew what it meant. Believe me, I've worked with some change teams since who did nothing to enlighten me either. But I've recently started thinking about it in a bit of a different way. Why? Well, because I keep seeing Agile transformations that are stalling. I keep encountering people struggling to implement Scrum or create high performing teams. And I know it's because Agile is widely misunderstood, and there isn't enough investment in truly reflecting on the cultural and mental shifts it requires. There are so many rabbit holes you can wander down; a whole industry of buzz words and trendy tooling has risen up around it. It's confusing and faced with confusion people's methods of conceptualisation lead them back to waterfall and what they were doing before. But waterfall with trace elements of misconstrued Agile. So we end up with these weird, uncontrolled waterfall processes masquerading in some fancy new clothes. Terrible working practices with requirements analysis missing because Agile means you just start on a wing and a prayer, with no documentation because we don't write stuff down in Agile, and no focus because we just keep iterating towards, well, nothing - no goal, no benefit, no milestone.

This is the area of change that has been interesting me. Cultural change, behavioural change within delivery teams. And how that links back up to portfolio and strategy. Because there's got to be a better way, right, than the CTO telling us "you're going home tonight as a waterfall team and tomorrow you're going to come in and be Agile"? I mean, how does that even work exactly?

Interesting aside - the Scrum guide, the only official document on the framework, is 14 pages long. It's shorter than the average project status report. I don't think I've yet come across a senior manager who has read it, or properly absorbed it. But they want their team to come in tomorrow as an Agile team. Let's say by some miracle that happened. How would they know it had happened? What's the benchmark they're going to assess their team against?

At this point, yeah I know, we're going to identify professional Agile coaches and they're going to come in and help us make the transformation. Great. I'm not going to disrespect what these guys do because I've seen a few really good ones. But a common complaint I hear from teams I work with is "that's great and everything and if we worked for Spotify I'd be all over it, but I'm none the wiser as to how we make this approach fit this organisation we're in". And that, I think, is the main problem. Conceptualisation again.

What I've been trying to do over the last couple of months is find a way to plug this gap. I've formalised my Agile experience by taking some Scrum certificates, and I've looked to boost my understanding of change methodology by becoming a Change Management Practitioner and an Agile Change Agent. I've taken an Agile Coaching course to boost and form some coaching and team mentoring skills. The primary focus of that course, I think, was how to work as a coach for Scrum Masters and Scrum teams - external to the team, advising and moving on. But I'm approaching it from a slightly different angle. I want to coach from within the team. I want to participate as an embedded team member, an analyst or a product owner, with the skills to better demonstrate and advise how what I'm doing frees and enables the rest of the team to do what they're good at. Because I think this will enable me to better understand and experience the challenges the team faces in their actual delivery environment and help them apply the principles in a more pragmatic way.

Isn't that the role of the Scrum Master? Well yes, technically it is. But does it have to be only their responsibility? There are plenty of Scrum Masters new to the role in need of some support too. Not every team even has a Scrum Master, using Delivery Managers instead perhaps, or even just old school Project Managers. At the very least, it seems to me, someone else in the team who can back up and reinforce what the Scrum Master is trying to do can't hurt right? We're looking to get to a self-reliant, self-organised and self-starting team. We want everyone in the team, ultimately, to be in this headspace and operate this mindset. If we start with more than one point of focus, with the ability to bounce ideas around initially until everyone else joins in, that can surely only be a good thing.

Anyway, this has been a bit of a ramble but it's an attempt to explain where my thinking is at. It's partially an answer to the questions: "what on earth are you doing at the moment with all these courses?" and "have you lost your mind?" Well, maybe I have. I don't know if this is a viable way of looking at it just yet. Maybe a lot of organisations are still too hierarchical for this, maybe it'll be seen as stepping on toes in terms of roles and responsibilities. Who knows? I'm all for testing a hypothesis though and seeing what the results are. And I'm convinced it's possible to trigger change more organically by taking a lead within a role defined for the target state rather than trying to work it out on paper first externally. You can't enforce change, it seems to me, not without having to lose people resistant to it. But you can demonstrate an alternative and prove it works. You can break down barriers and norms and show how previous achievements weren't necessarily founded on them, and how previous failures might have been mitigated. It's convincing people to try a direction of travel I guess, which is easier when you set off with them than it is to just give them a map, point over there and set them off on their own.