To put my own position into context we have to step back in time to 1995 or thereabouts. I was working for a financial services company in a departmental development group and we had taken the decision to rearchitect our entire portfolio which was bursting at the seams. At the time, it was the height of the Object Oriented versus Structured design, analysis and programming method wars, and we went OO. Speed was of the essence to get the full portfolio re-engineered, so we also decided to model our development method along the DSDM rapid application design route. It would be another six years before the Agile Manifesto was published (2001) and it would take a few more years more for Agile to became the new management mantra that it is today.
In adopting DSMS and the nascent ideas that ultimately became Agile Development, we were looking to do many of the very things that the Agile Manifesto highlights. Primarily, we wanted to deliver value to the customer on a regular basis many times a year. We weren’t big on processes so that wasn’t a big deal to us but we were getting hot under the collar about software quality and all our code was well documented within the source and subject to team code reviews. We had a series of product owners for each application within the portfolio and were co-located with the business people. We weren’t big on project management either - we had product roadmaps and timelines but weren’t wrapped up with project schedules. Ultimately, our overarching goal was to support the business by being part of it, not living a parallel existence as an IT organisation selling to the business.
Looking back to those days we had pretty much got it right. And we kept it simple. The team collectively made the decisions about how we wanted to operate and management let us get on with it. We worked with the product owners and designers, programmers, testers and support staff all sat in on the design meetings so everyone understood what was going on and had buy-in. No-one had any surprises further down the line, and products were shaped collectively rather than passed from analysts to designers to coders and then thrown to the testing teams. It’s a far cry from the Agile Development Industry of today which has become so complex and convoluted that some of the original signatories of the Agile Manifesto and the very early adopters are trying to distance themselves from the agile movement.
If the Agile Development world has gone a little bit crazy and spawned its own supporting and lucrative (if somewhat nebulous and smelling of snake-oil) industry, it’s hardly surprising that other people are jumping on the bandwagon and selling agile as a cure-all. So we find Agile Project Management (surely the antithesis of the original intent of the Agile Manifesto!), Agile Management (the ultimate oxymoron?), Agile Testing (we test small parts of the software regularly?) and of course Agile Change Management.
Let’s step back again for a moment. The dictionary definition of the adjective ‘agile’ is:
having quickness of motion, nimble, active (of body or mind)”
and for those interested in etymology it hastens back to the 1580s, from Middle French agile (14c.) and directly from Latin agilis "nimble, quick," from agere "to set in motion, keep in movement"
All of these attributes are highly relevant to modern business and yet modern businesses are set up to be anything but agile. They are juggernauts whereby the time an order is received and acted on at the far reaches of the empire, it has already been rescinded at head office to make way for the next directive. Modern businesses are siloed complexes where internal departments compete with each other for finite amounts of money and people and bicker amongst themselves rather than doing what is right for the customer. Entire departments are set up to manage cross-charges (funny money?) rather than focus on external customer satisfaction. And modern businesses now want to be Agile by doing agile things that were designed for a very specific group of people with a very specific set of needs and desires. So they have stand-up meetings and whiteboards full of stickers instead of departmental sit downs and project schedules (actually they often do both!) so they look agile.
The point is that they haven’t thought about what agility means. They do Agile, without being agile because they can’t really see that being agile means changing almost all the current ways we do business and the way we do work. And some people will never be able to make that change, because they have too much to lose - because ultimately being agile means giving up the reigns of centralised power, and most senior and middle managers will never be able to do that.
Which brings me back to the title of the piece. Is there such a thing as Agile Change Management? If we go back to the Agile Manifesto and try to apply it to Organisational Change Management, we can ignore the four values underpinning the manifesto, and we can ignore over half of the principles. I would argue that the only relevant pieces of the Agile Manifesto with respect to OCM are:
- Simplicity
- Support, trust and motivate people involved
- Regular reflections on how to become more effective
and all three of these should already underpin any change management activity within the organisation.
As for the ceremonies like daily stand-ups, Kanban boards, these are noise. They are tools that you can use but they don’t make change any more agile, they just make it more visible and more transparent (if used correctly). My argument against Agile Change Management is that if you can't do Change Management given what you already know, you're not going to get better using something you know even less about. I don't really subscribe to the idea that Change Management fails. Organisations fail to do Change Management.
For many of us with a history and good understanding of true Agile Development, the most important aspect of agility is the continuous delivery of value to the customer. And in Organisational Change Management we already have that ability.
It’s known as Continuous Improvement.
Print this post
Posts
No comments:
Post a Comment