If you are an established business working in an Agile way can help you react quickly to market changes, save money and have happier staff. But how do you actually go about it?
There are two main approaches to change management:
1. A hard change: Boom! Today we are working in a different way, forget everything you have ever known.
2. An evolutionary change: Small, iterative changes that cumulatively make a big change.
I have experienced both of these changes and if you are persistent they will both get to the same place eventually. However if you want to keep the momentum up whilst you transition, then I recommend you follow an evolutionary approach.
This is because the key to any big change is the associated change in culture. You can’t just tell people to be different, you have to show them.
We recently implemented a change to Agile in a large department of 50 or so employees, comprising around 10 teams. Here’s a breakdown of how we did it:
Set objectives
At the start, work out what you are trying to achieve. And why? What result do you expect to see?
We wanted to increase productivity, speed up the pace of delivery, reduce risk and increase quality. At this point we took a baseline of all of these KPIs so that we could track progress as we went.
Pick a change management approach
We used a kanban approach to change management. Kanban is a theory that has come from the Japanese automotive manufacturing industry, focused around lean processes and just in time delivery.
It has been adapted to software development and to change management. So you can use it to manage a project or your individual tasks.
You can also use it to implement large scale change. Really you can use kanban to organise anything, it is now applied to enterprise, not just software.
These are the basic principles:
1. Start with what you do now
2. Agree to incremental, evolutionary change
3. Respect the current roles, responsibilities and titles
4. Encourage leadership at all levels
“Don’t change things for the sake of it, make sure that everyone knows what is going on and that everyone is able to feed into the change in a useful way”
In summary: don’t change things for the sake of it, make sure that everyone knows what is going on and that everyone is able to feed into the change in a useful way.
This all sounds great, but what do you actually do?
There are no set processes in kanban, no rigid meetings, documents or labels. As long as you follow the general approach you can do whatever you feel is right within that.
These are the core properties for kanban:
Visualise your workflow
Everyone who forms part of the value chain needs to be able to see the workflow – from the team actually doing the work, to senior management, other departments and customers.
How does work come in? Where does it go within your teams? How does it leave? In the simplest form this is a white board with some post its. Or you can use online software (kanban flow is free ).
Looks simple but it might be different to how your teams actually work. We certainly found this to be a surprisingly high-impact change.
“Suddenly the rate of work is realistic rather than optimistic”
Instead of a manager giving work to team members (‘pushing’ the work into the team), the team members are responsible for picking up the work at a pace that suits them (‘pulling’ the work into the team). Suddenly the rate of work is realistic rather than optimistic.
This simple change from push to pull can have a fairly big change immediately on your work.
The pace of work probably stays the same but now you know exactly what that is, rather than what you would like it to be.
Limit the work in progress
An individual can only really have 2 tasks on the go at any one time. One thing they are actively doing now and another thing they are waiting on (they are thinking about it, they are waiting for some information, they are running a script etc). As the implementer you have to enforce this quite strictly.
We found that people like to collect tasks and soon you see someone will have 5 or more tasks with their name on in the ‘doing’ column. You must take all but 2 of them out and put them back into ‘to do’. Sounds simple and even a bit pedantic – but this makes your work transparent. It doesn’t matter what people say they are working on, you can now see what they are really doing. And so can your stakeholders. So your communication radically improves.
Manage the flow
Once you have done the above two steps, you can now see exactly what is happening. The first thing to do is watch it – see how the work moves from ‘to do’ to ‘done’, this is strangely exciting.
The second thing to watch for is bottlenecks, where work is backing up and causing a blockage in the system. Previously we might have just given the affected team member more work ‘you’re going to have to take on another project Dave’. But now, Dave is controlling the rate of work. So if there is a bottleneck then Dave is either lazy or Dave is at capacity.
Let’s assume Dave is not lazy, Dave is working at capacity. The productivity of the whole team will never increase if you don’t sort out the Dave Issue. So you either add another Dave to increase the available resource, or you lessen off the work upstream in order to prevent the bottleneck, or you find another way of doing the work that means it doesn’t always have to go through Dave.
Once you’ve decided on your solution, tell everyone what it is. Do it. Watch it. Has it unblocked the flow? If so, high five yourself, you Agile legend. And move on to the next improvement.
When you have solved a problem and seen it have a positive impact on your teams (measured against your baseline KPIs), move on to the next most important issue.
We went from solving critical problems to installing best practice in a fairly smooth way.
Make policies explicit
The basic rule of kanban is that everyone needs to know what is going on. The work must be visible to everyone as in rule one. visualise the workflow. But also everyone needs to have the same understanding of how the work is done.
“The basic rule of kanban is that everyone needs to know what is going on”
A really good example of this for us was the use of the word ‘done’. For some engineers ‘done’ meant ‘I’ve completed my bit of code’ to a project manager ‘done’ meant ‘the work is finished, it is live, the end user can use it and this is going in a report to management’. These are fundamentally different meanings of the same word and this had unknowingly been causing us problems for a long time. By making things explicit and by ensuring everyone knew what these policies were, there was much less misunderstanding.
Collaboration
This is critical to success.Don’t make these changes at your team, make the team part of the decision making process. To start with the problems were large enough that everyone could see what needed tackling. But after we had fixed those we were on to smaller issues.
Suddenly people started suggesting improvements, simple changes that would make a difference to their personal efficiency. The effect was cumulative. On their own none of these changes were that noticeable but combined they took the system to the next level of efficiency.
What was the result?
I was genuinely surprised at the impact this approach had. Firstly we successfully implemented Agile working (scrum for products/projects and kanban for support). It was successful because everyone was using it, we were delivering faster and better and we were set up in a way that meant we gathered data (with no additional admin burden) to monitor progress.
Secondly we had no drop in momentum during this period of change, instead we had gone from the starting baseline to faster and more efficient production with no change in headcount. Thirdly, the culture changed organically. The teams were responsible for the culture change and the atmosphere in the office was very different. It was positive and happy. People were motivated and supportive of each other.
“Using the Agile approach meant the culture changed organically. It was positive and happy. People were motivated and supportive of each other”
Finally, productivity increased because team members worked at their own pace, completing whole tasks before moving on to the next one. There was clear visibility of the work completed which gave everyone a sense of progress and a positive acknowledgement for colleagues of the work they had done. The result of all of this was that we could all clearly see the strategic direction of the department and see how our individual efforts contributed to the overall success.
We were all aligned with the business objectives
This process was not without mistakes, or wrong turns. Every change management process will have an element of failure. As long as you get to where you wanted to be. We went further than that, we had gone beyond just Agile working to a culture that fostered success, quality and innovation. This particular case changed me from being someone who was proficient in delivering in an Agile way to a true believer.
