This is another moment where the context drives the way the improvement project is done. The improvement suggestions are now on the table of the teams to implement them against the background of the improvement architecture (Business objectives, Improvement objectives, Scope, Context and Constraints).
Implementing large changes in one go is difficult and often fails. That is true for software development, but it is also true for process improvement. The agile principle “Working software is delivered frequently (weeks rather than months)” also works for improvements. Improvements preferably are implemented using Agile frameworks or work methods, like scrum and kanban.
Improvement suggestions are put on an improvement backlog. They are prioritised by the improvement owner.
The improvement owner has delegated authority to decide on priorities between software development and implementing improvements in the organisation. The improvement owner manages the improvement backlog.
Improvement suggestions are put on an improvement backlog as improvement stories, which need refinement and acceptance criteria, like software user stories.
Feedback loops are necessary at different levels
- A feedback loop on the improvement stories: are they successfully implemented?
- A feedback loop on the improvement objectives: are the improvements actually helping meeting the improvement objectives?
- A feedback loop on the business objectives: are the improvements actually helping meeting the business objectives?
Improvement implementation heuristics
Scrum? then scrum. Organisations that use a scrum framework for software development can use this framework for implementing improvement stories as well.
No scrum? then Kanban. When the organisation does not have a well functioning scrum or similar time boxed /variable scope work method, kanban is a useful alternative for agile improvement.
Improvement stories. Improvement stories that are written like user stories (AS.. I WANT.. SO THAT..) helps focussing on the ‘what’ of the improvement and what benefits the improvements lead to or which objectives will be met after implementation. The ‘how’ is left to the team.
Ivory tower. The improvement owner does not sit in an ivory tower prescribing how improvements exactly need to be implemented. Instead she provides details about the ‘what’ and the teams determine the ‘how’.
Different view points. There may be differences in point of view on facts, argumentation and conclusions between the different groups (e.g.: testers think unit testing must cover functional aspects but do the programmers agree and do they know how to do that?).
Buy in and ownership. People need to buy in to improvement and need to take ownership for it.
- Senior management showing its commitment stimulates people to do the same
- Buy is worked on in the improvement architecture and during the assessment.
- People understanding the benefits of improvement are open to take ownership for it.
- An improvement owner that has a clear understanding of the actual level of commitment of the people involved are more successful in getting improvements implemented
Visualise, use white boards. Use all instruments that are successful communication tools in software development, like white boards, pictures etc. to discuss and communicate about implementing improvements and its (positive) effects.
Competition with BAU. An improvement owner is successful when the teams involved in the improvements are able to balance efforts on improvements with business as usual.
Great improvement plans, poor results. Big improvements with few benefits for the people involved have little chance on success. Instead:
- break down big improvements into work packages that can be overseen
- let each improvement provide some benefit
- limit the amount of improvements at the same time (kanban)
- establish priorities (improvement backlog for scrum of kanban)
- evaluate each intermediate improvement
- planning matters, not the plan
Traceability. Showing how improvement suggestions link to improvement objectives and expected benefits increases buy in of people.
The pain factor. Great improvement plans have little chance when people do not see how it reduces any pain they feel in their daily work. And vice versa: when there is pain, people support change to get their pain resolved.
Intermediate benefits. Often the goal of an improvement project takes considerable time to reach. Maybe half a year of longer, to get the full benefits from all improvement efforts. It is good practice to plan for an improvement route along steps that also provide intermediate benefits.
Improvement/maturity paradox. There is a relation between the maturity of an organisation in developing software and the ability of an organisation to improve: low mature organisations find it more difficult to change en implement improvements. Higher mature teams are able to improve with higher velocity and with a higher chance on success.