Agile at scale transformations rely on alignment between support and business functions on the scale of a whole organization.
As illustrated in the figure below:
- An operational process can be described as a value chain whose starting point is a request/trigger that flows and finishes hen some value has been delivered to the customer. It can (combine business and support functions (HR, financial, purchase)
- The various steps of the process can rely on systems (a set of tools including IT)
- Finally, the specific alignment between IT and business consists of putting the IT delivery process(es) to improve the systems in front of each operational process. (visualized through development value chains)
Several experiences of implementing Agile at scale transformations have demonstrated this very first step of value chain modelling, often neglected or accelerated. It is a key step for the success of the transformation’s success and for its sustainability, particularly through the onboarding, in other words the implication of the businesses.
This value chain modelling is carried out during a collaborative workshop, which requires to ensure that:
- All the stakeholders, or at least a representative group, covering the overall process are attending
- The boundaries (starting point and ending point) of the value chain must be clearly identified
- The Workshop must go beyond a value chain modelling and must continue through a real analysis of the process phases
- The value chain should not only describe the processes but should also enable the visualization of each process/sub process by stakeholders and users
The benefits of such approach fulfilling these 4 criteria are:
- Collective awareness and ownership of the overall process
- Identification of flaws, bottlenecks and possible improvements of the business process, covered or not by IT systems (for example, a manual office automation task performed by only one knowledgeable person)
- Support for prioritization of futures developments based on sound argumentation evidence and feed of the architectural roadmap (functional and or technical). This may have an impact on sequencing and designing the transformation
- Identification of stakeholders, persons or entities to involve in the product management setup
- Identification of external dependencies and misidentified processes boundaries
My recommendations are set out as follows:
- Delaying the follow-up steps of the transformation and saving time to launch every action resulting from this first analysis may constitute a blocking trap for the transformation.
Indeed, if some of the leverages must be activated soon for fear of later cost, it is appropriate to separate them from other elements which are likely to be carried out later during the transformation
- As part of continuous improvement, the modelized business process must be visualized and monitored as long it is evolving? and enables global improvements by avoiding local optimum trap.
- It is not a question of applying a specific transformation target model: The value lies in conducting a collaborative exercise facilitated by coaches using adapted postures. These two factors are essentials to allow stakeholders to become as a group the committed actors of their own transformation and allow them to improve their processes. This is the prelude to agility in business and support functions beyond IT
Member of inspearit Agile@scale community (community designing an Agile@scale transformation approach)