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!
Print this post
Posts
No comments:
Post a Comment