Using Agile Development Concepts to Help Manage Organisational Change (Part 2)

Whilst incremental and iterative development underpin Agile Development, and Whiteboards and Stand-up meetings are often seen as the public face of Agile, there are plenty of other ideas that we can bring into Organisational Change Management to help us do things better.

But just before I get into the details, I want to make a clarification. This set of articles is built around the premise that there is no such thing as Agile Change Management. I recently attended a Agile Change webinar organised by the ACMP and the guest speaker was Tim Creasey from Prosci. I’ve had a lot of support from Tim in respect of these articles, so I was intrigued by his take on the matter. He talked a lot of sense, and from my perspective, we appear quite closely aligned in our views. But one idea he emphasis really stood out for me. This is my interpretation...

There is Agile and there is agile. If you’re talking Agile, you’re either talking about the Agile Manifesto and Agile Software Development. If you’re talking agile, then you are looking at ways of being flexible, being nimble, quick, spry, sleek, ... go find a Thesaurus and find the words that best suit what you want to be! Just be clear about whether you mean uppercase or lowercase agile. There is a huge difference!

For clarity in future I shall be as precise as this. When I’m talking about Agile Development, I shall use the capitalised noun. Anything else if referring to the concept of being able to things better in general.

In this post, I want to focus on two Agile Development practices which are critical to becoming agile but don’t get very much airtime in the popular write-ups of agile (the ones most likely to be read by people who then decide they must ‘do agile’). One of these is Frequent Customer Feedback and the second is the Definition of Done. Without both of these practices being used properly, I would argue that your agile Initiative is doomed. Both these practices are designed to overcome some of the fundamental problems with more traditional development methods, and I would also argue that in many organisational change management initiatives neither of these is practised and help to explain why change programmes are sometimes less successful than their owners either expected or wanted.

Over the years, before I became an independent consultant, I’ve been on the receiving end of dozens of change programmes, some of which cost a royal mint and appeared to achieve very little. In one global organisation, a three-year programme of enormous changes was superseded by a second programme with a similar name which appeared to undo everything that the first one did. This may be an extreme example of change mismanagement, but neither Definition of Done nor Frequent Customer Feedback were evident to the majority of people in the organisation. To be honest, I’m not entirely sure that the objectives of the change were publicised other than the launch of the programme by the CEO but that’s a whole different story.

Internal change programmes are notoriously bad at obeying the project governance that is in place for customer facing projects. Requirements and objectives are often sketchy and based in terms of pre-determined solutions to perceived problems rather than by establishing genuine problems and defining workable solutions using the methods that are mandated for use in customer projects. Most importantly, few quantitative checks are made during the course of the initiative, other than the costs and adherence to a usually arbitrary schedule or set of milestones. And rarely is there a definition of done. Without this DoD, how do we know when the change is complete? Is it when there is no more budget? Or maybe when all the tasks on the project plan have been ticked off? Or maybe it’s just when the initiative gives way to the next one? If we don’t know what the end point of the change is, how can we possibly begin to understand whether it has been successful? How can we start to measure the return on investment and cost benefit or any other benefits?

In a development environment, it’s relatively easy to create a definition of done. Most good Agile Development teams will have created their own which has been agreed with the product owner. It might include items like:

- All code in the release has been code reviewed, unit tested, and meets the agreed coding standards
- All code in the release has been through integration and acceptance tests
- All user documentation has been written and peer-reviewed
- All releasable material has been secured into the production environment
- All story criteria have been passed by the product owner

If the team, including the PO, do not agree that the conditions for Done are met, the code cannot be shipped. This is a commitment that is made up front and cannot be reneged on, and is the primary guarantee that only good quality product is released into the world.

When you start talking about business change, the DoD is much harder, and if you don't have clear objectives and requirements about what the change is expected to deliver, you haven't got a hope of defining when you’ve achieved it. And yet businesses still seem to think that this is a smart way of working. (Just as an aside, and based on my earlier comments about Agile vs agile, I wonder what organisations use to understand what their goals are for their Agile (agile) Transformations? Let’s not go there now!)

I’m not going to even attempt to provide you with a list of some potential criteria for helping create the DoD for a change programme. Doing so would be futile because what might work for me won’t work for you, but most importantly your DoD will be completely dependent on the context for your change and your organisational structure and culture.

Regular customer feedback should really be a complete no-brainer for a change programme. 99% of business leaders acknowledge that successful change programmes are built on engagement and discussion with all the critical stakeholders, especially the people most impacted by the change. But the reality is that a much smaller percentage actually do it, or do it effectively. Telling people that a change is coming and then telling them sometime down the line that the change will be effective from next month does not count as engagement. It barely counts as communication.

There are two clues to solving this regular customer feedback problem in a change programme, and using Agile Development concepts actually makes it a bit easier. The first clue is the use of the word 'regular' which suggests that you may have to perform this activity more than once at the beginning and once at the end. The other clue is the word 'feedback' which suggests that telling people is only part of the story. You need to listen to what they have to say as well, and preferably act on it. Ignoring feedback is bad management, poor leadership and quite honestly simply bad manners, and yet it is still a standard business practice.

How can Agile Development practices help us better deal with regular customer feedback in our change projects?

By splitting our activities into time-boxed chunks (you might be more familiar with Sprints but this is a scrum specific term) we actually automatically provide those regular feedback points. Again, to borrow terminology, scrum talks in terms of Retrospectives. But since I want people to stop mixing Agile Development and agile change metaphors, I’d rather not dwell on terminology. Call things what you like, but just make sure that everyone understands what you’re talking about. The point is, at the end of each timebox, you make time with the stakeholders to understand what you have achieved, what has worked, what hasn't worked and what can be done to improve things in the future.  You can also get a feel about what new information might be pertinent to the next set of timeboxes and what activities might need reprioritising.

I'm not suggesting these activities are easy to do in a change management initiative. They are certainly easier in an Agile Development environment, where you have a clearly defined deliverable, namely working software that adds value to the user.

But no-one ever said Change Management was easy - it's just that there are things you can do to make it less difficult and to minimise the risk of things getting out of control. If you want your organisation to be agile, it's going to require some serious thought about how you approach change in the future.

Yes, folks, it is true; agile is about a changing mindset and changing the way you do work. There are no blueprints you can follow and make it happen overnight. There is no such thing as Agile Change Management!

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!

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.