In my experience, Agile Transformation can be run as any other Scrum implementation. Thus creating an Improvement Backlog which is an ordered list of everything that needs to be done during the transformation can be created.
Some items which need to be considered
Each Item must have a tangible Business Value –
Generally the leadership teams are used to running such initiatives as long term plan-driven initiatives. Thus what ends up happening is that, the list of improvement items becomes a planned list of activities rather than having some tangible business value. The most important thing in a transformation exercise is to define the tangible business value with each item so that everyone knows “Why are we doing this item”. It helps to consciously call out the business value attached with each item. Over time this becomes a habit but it needs attention and focus initially while the team is getting used agile way of working
Ensuring that the Items are small :
When the leadership teams are used to running big-bang transformation items, each item spans across multiple months. In my opinion, each item should be small such that a quantifiable value is achieved within one month time.
Acceptance Criteria should be defined :
Measurable Acceptance criteria defines when an item is successful. This helps the implementation team get confidence about the implementation being done is resulting in tangible business value. In large transformations, there always will be “Skeptical” stakeholders and “Change Resistant” stakeholders. This way of working helps silence such stakeholders.
Consider Creating Themes
For a recent transformation I was a part of some of the initial items in the backlog were
- Increase Scrum awareness,
- Create a supporting organization structure that enables scrum and Increase automation
- Spreading awareness of tools
- Re-arranging of the team-space (working area) of teams
Each of these items needed to be implemented by completely different teams. Hence, managing the backlog was becoming a difficult task and we ended up creating a “sort-of” sub backlog for each of the items in the parent backlog. Another way of thinking is that we create Themes in the product backlog which clearly identify the set of items to be undertaken by each team.