Wednesday, 13 February 2019

Using Agile Development Concepts to Help Manage Organisational Change

If you got a chance to read my last post, “Is There Such A Thing As Agile Change Management”, you may have thought I was a bit harsh on the New Wave ‘agilisters’ (a collective noun for people obsessed with sticking the word ‘agile’ in front of a business practice and thinking it’ll make a difference). I actually think that most people agreed with me, but I wanted to write this follow-up because there are some positives that come from the Agile obsession and it’s really important to recognise these and not to dismiss something because a whole bunch of people are misrepresenting it.

But, let’s not be under any illusion; Agile Change Management is not a real thing. Even more importantly trying to shoehorn Change Management and Agile Development into the same pigeonhole is never going to be useful to anyone.

Change Management is about how we facilitate change activities within an organisation to ensure that we are trying to do the right things, for the right reasons, and with the best interests of the right people as the paramount consideration in our change initiative.

Agile Development, on the other hand, is a mechanism for building software in such a way that it provides a continuous value stream to the people who need to use the software (as well as making life better for the people who develop that software).

With that important distinction in place, we’re now in a better place to understand how we can use concepts from one discipline to get better outcomes somewhere else. So, what can we learn from Agile Development that we can use when we are looking at Organisational Change? Can we cross-pollinate ideas from one discipline of building software to another of managing change?



Since there are so many people who think that ‘agile’ is all about whiteboards and stand-up meetings, let’s start with them and get them out of the way. To be honest, I’d suggest these are no-brainers. Much of our work in Change Management is about communication and these two tools are all about improving communication within an agile team. A simple whiteboard is a great way to visualise what’s going on in a change initiative and helps us to understand flow through the system. A whiteboard is great for the change team or even the leadership team to see at a glance what’s going on and a useful driver for those sometimes difficult conversations. It beats a project schedule hands down and can be understood by most people without a detailed explanation.

In the same vein, the daily (stand-up) meeting is a useful addition to the communication tools at the change team’s disposal, and again could be extended to the leadership team, depending on your organisational context. There’s nothing magical about a daily (stand-up) meeting. It’s what all meetings should be; focused, short, inclusive, and action/outcome oriented. (Daily meetings don’t have to be stand-ups, but to keep them short and dynamic it helps.)

In my previous post, I hinted that only three elements of the Agile Manifesto were appropriate to Change Management. These were:

  • Simplicity
  • Support, trust and motivate people involved
  • Regular reflections on how to become more effective

The daily meetings and the whiteboards are great examples of some ways to realise these requirements. Regular retrospectives (post milestone reviews) are an additional tool that can be used to further support the third of these. But clearly, there’s a lot more to agile. When we go back to the Agile Manifesto, there are (arguably) three principles which underpin the whole ethos behind Agile Development.

  • Customer Satisfaction through early and continuous software delivery
  • Accommodate changing requirements throughout the development process
  • Frequent delivery of working software

There is a really good reason why these are so important in Agile Development. Often, when we create a product which is highly reliant on software, we have very little idea of what the end product should look like. Even if we do, we often don’t know whether it is possible to achieve. When we first started building large software applications we attempted to get around this problem by analysing and defining everything up front, writing huge specification documents, followed by myriads of design documents and finally cutting the code to bring it all together. The problem with this approach is that when you get to the point that you’re writing the code and the customer (or product owner) wants something changing, it becomes very difficult and very expensive to build that change into the system.

Agile Development attempts to circumvent the problem by having a vision of the end product, but only developing small chunks of it at a time. Chunks that can actually be of use and valuable to the end user without having to wait for the complete product. This reduces the risk of having to rebuild vast amounts of the system when requirements change, or when implementation problems arise, and hence reduces the cost of the final product. At the same time, it gets over the inherently human problem of not knowing what we don’t know because it enables us to learn more about what we are building as we build it.

This is where things get tricky when we try and adapt these principles into organisational change (unless of course, our organisational change is all about a large software implementation like an ERP - Enterprise Resource Planning -system). It becomes clear why when we paraphrase the principles in terms of change

  • Customer Satisfaction through early and continuous change
  • Accommodate changing requirements throughout the change
  • Frequent delivery of change

Often, organisational change is not something we can easily do in chunks. Rolling out a new organisational structure a bit at a time over several months brings about chaos - I’ve seen it happen on more than one occasion. The endpoint of an organisational change is usually very well understood, and indeed, changing the requirements of a change initiative during the initiative will invariably cause many problems, and may lead to many more issues in the future when trust is lost in the ability of the leadership to deliver change. Finally, when an organisation become a conveyor belt of change with no respite, organisation change fatigue sets in; the people within the business cannot take on more change and uncertainty and they have no more appetite for it. When this happens, their only option is to push back against the next set of changes, regardless of how important they are.

While some changes do require a big-bang approach, it is still possible to structure a strategic change programme into a number of tactical initiatives using this agile approach. And instead of defining a huge change programme upfront, designing all the different pieces before finally implementing them, we can use the agile approach to deliver vital pieces of the overall puzzle and constantly adjusting what gets done next by regularly revisiting the requirements and the urgency of their implementation. It’s also possible to build in slack into the frequency of change experienced by different groups in the organisation by changing the target groups on a regular basis. And of course, it is critical to constantly monitor feedback and engage with the affected stakeholders throughout the programme. And when you take an approach like this, it’s even more important to keep your communications flowing, being prepared to explain why you’re taking the decisions to prioritise certain tactical changes over others, and above all, keep things transparent.

But you know what…Let’s not get ahead of ourselves and start calling this “Agile Change Management”. It isn’t. Because ‘Agile Change Management’ still isn’t a thing!






Friday, 1 February 2019

Is Agile Change Management A Real Thing?

A topic that keeps cropping up in some of the change management forums of which I’m a member is ‘Agile Change Management’ and while I’m happily contributing to the discussions it does seem to me that there is a lot of confusion and speaking potentially at cross-purposes. So I decided to write this piece to help me consolidate my thoughts and hopefully bring some clarity about my own position about Agile Change Management.



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.



Monday, 10 December 2018

A Double Standard Is No Standard At All!

If there's one thing guaranteed to make me mad in the workplace it's the failure of people to follow internal standards or guidelines for internal projects. In the IT world, this appears to be the normal state of affairs. I've lost count of the number of internal initiatives that I've been involved with which have no requirements (documented or not), no clear objectives, no stated business benefit, no plan, and no effective management per se.


These companies often have highly developed processes and procedures covering just about every aspect of their business, and yet internal projects (and programmes) are kicked off on a regular basis without even so much as the back of a fag packet plan.

How many times have you been tasked with creating a tool to monitor some aspect of your organisation without any of the prerequisites demanded by management for a customer-facing tool? You must have had the conversation that goes...

Manager: "Knock me up a spreadsheet to track our widget usage across the organisation. Nothing fancy, but I'll need it for the leadership team meeting first thing in the morning".

You: "You can use the corporate widget monitoring tool for that"

Manager: "I don't need the full monty, just a snapshot - it'll only take you a few minutes. You can do it during your lunch break"

You: "OK, then. I'll have it ready for you early by 14:00" 

Back at your desk, you start banging your head against the wood because you know what's going to happen next. The quick and dirty spreadsheet 'project' is soon going to morph into something monstrous and you'll never get an opportunity to eat lunch again. Soon, everyone will be wanting additional features, customisations and modifications (not one of which will be written down).

I've written and spoken about the dangers of the end-user cottage industry of dashboards in the past but the truth is that major corporations run vast tracts of their business affairs using unregulated and un-auditable spreadsheets. Far more complex initiatives are undertaken in exactly the same way and the outcomes are always the same. And they are not good...for anyone!

Organisational change is still one of the most difficult undertakings for a business, and yet many of them still believe they can perform it without any understanding, planning or proper management. The metaphor of building the aeroplane while it is in-flight is entirely appropriate. You’ll be familiar with the executive who is parachuted into your department and immediately starts to take control by issuing edicts about how things need to be done, despite having no previous experience in anything to do with what your department does.

You might think you’ve got lucky when the exec announces he is setting up an internal working party. And then you find that the working party includes all his management cronies and a token member of your department - the one person in the team who is guaranteed to not rock the boat. A few days later you get the memo about the changes and after shaking your head in disbelief you start plotting with the other reliable members of your team as to how to block the change and undermine the new manager. And businesses wonder why change fails.

Maverick workers may be a pain in the backside, but they often operate for the good of their colleagues. Maverick managers, on the other hand, are often only in it to further their own careers. These kind of parachute appointments are very often temporary, and any damage that is done can often be put right before too long, once the exec has been assigned to another department!

But if organisations really want their employees to react positively to change, senior executives must keep an eye out for double standards, where managers expect others to behave a certain way, but fail to do so themselves. If managers can’t follow internal processes then their leaders should be asking why not. If the processes are wrong, then fix them. If managers won’t follow internal processes, then either re-educate them or get rid of them.

A double standard is no standard at all.




Friday, 30 November 2018

Collaboration and Innovation: “What we’ve got here is failure to communicate” *


Show me a recent company mission statement or a set of corporate values and I'm willing to bet that it'll contain the words collaboration and innovation. It'll probably also contain the word agile and maybe lean as well but let's not get sidetracked in the first paragraph.

Whilst I don’t dispute that innovation and collaboration are ‘good things’, when they appear in high-level mission statements and value propositions, they are usually little more than words plucked off a jargon bingo sheet, fairly meaningless and probably not understood by the people who wrote them any more than the executives and managers tasked to make them happen.

The biggest misplaced assumption about innovation and collaboration is that these things can be made to happen on demand. Secondly, there is the rather suspect assumption that for businesses to succeed everybody in the organisation must be an innovator and a collaborator. Thirdly and finally I take issue with the assumptions that innovation needs to be centralised and that collaboration and teamwork are synonymous.

My main issue with these assumptions is that both collaboration and innovation are organic. They cannot be turned on and off like a tap and management cannot force people to do either (at least not successfully).

I’ve spent quite large portions of my working life as a remote worker so I’ve always been interested in the way ‘home-based working’ falls in and out of management favour. As a remote worker, generally you become a natural collaborator, otherwise, you tend to go slightly deranged. You also become something of an innovator, because there are times when you are the only person who can come up with a solution to a problem you face. Yahoo, IBM and HPE all made headline news when they announced an end to home working because they needed everyone in the office to ensure maximum collaboration. As if being in an office in San Francisco is going to make you any better at collaborating with your colleagues in Bangalore than if you were at home (actually it’s more likely to be the reverse, but let’s not go there).

I recently came across a question asking how to enhance Global Collaboration in an organisation. The question pertained specifically to a situation where the business comprised a significant itinerant workforce. But regardless of the specifics, I was intrigued by what was meant by “Global Collaboration”. Was there an expectation that management could force people across the world to collaborate, regardless of their role, department, or whatever other artificial organisational constructs you’d care to add? Even if that were the case, why on earth would you want it? It sounds like a recipe for disaster in terms of organisational productivity. You could spend all day in meetings collaborating with people you’d never heard of before about subjects you know nothing about!

Collaboration needs a driver and a context. Groups of people need to collaborate from time to time - some more than others. And a failure to collaborate is exactly what causes organisational meltdowns on occasion.  Organisational failure often occurs at the interfaces within those artificial organisational constructs I mentioned earlier, and more often than not is brought about by the very creation of those constructs such as setting conflicting objectives for sales and marketing teams and engineering teams. Or trying to create an agile organisation one project at a time. When individuals or groups of people understand that they have mutual goals like deliver a product to the customer in the fastest time, it’s amazing how quickly they learn to collaborate.

In the same way, it’s amazing how people will collaborate in order to innovate a solution to solve a problem. But management doesn’t generally see this as good enough because they are constantly being told (by people who don’t have a clue what they are talking about) that they need to innovate faster to stay ahead. So soft drinks manufacturers, for example, constantly come up with improvements to their age-old, much-loved recipes that no-one likes and no-one buys. They’ve innovated their way out millions of dollars of marketing, R&D and customer loyalty. Of course, they could have gone to their frontline workforce and asked them if they could come up with better solutions to create their existing products (yup - that’s also innovation!), but that’s not enough to satisfy greedy investors and analysts.

The relatively new fad of creating Centres of Innovation, where good ideas go through various filters before they get approved or rejected and then end up in the hands of people who implement something completely unrecognisable from the initial proposal, sends out an extraordinary message to employees. It says - we don’t trust you to be able to take an idea from nothing to implementation; we need someone better qualified to do that. And in so doing it stifles innovation from the very people who know best what needs to be done.

If you take a dozen people and put them on a desert island with no interaction with the outside world, they’ll innovate a way to kill each other, after the strongest have collaborated together to find out which of the others to kill first.

* Quote from the 1967 film, Cool Hand Luke by The Captain (played by Strother Martin)