Finding Flow
The initial "Finding Flow" stage involved an extensive evaluation across three core dimensions: the Technical Operating System, the Management Infrastructure, and the prevailing Mindsets, Capabilities, and Behaviours. This diagnostic phase was crucial for creating a 'Releasing Flow Map' by identifying the primary obstacles to efficient and effective product development.
Several significant challenges were identified:
- Flow Fog: A pervasive lack of clarity was evident in multiple areas.
- There was no standard approach to defining or capturing customer value, especially for larger development programmes. Requirements documentation was often incomplete, with low levels of collaboration, making it difficult to understand how work was flowing towards delivering value.
- The process for decision-making was informal, particularly concerning product and programme risks. Issues were frequently escalated to steering committees without clear Key Performance Indicators (KPIs) or a record of decisions, leading to frustration and ambiguity.
- Handover points between teams, particularly with engineering, were described as "time-consuming" and a "black hole," indicating a lack of visibility into work status and process flow.
- There were no clear, consistently communicated business targets or KPIs for Product Development. While data existed in systems like Jira, reporting was not always visual, engaging, or shared widely, limiting transparency and data-driven decision-making. This sometimes led to what could be described as Dusty Dashboards, where metrics were compiled but not effectively used to drive improvement.
- Misaligned Priorities:
- Cross-functional interactions, vital for learning and knowledge sharing, were not managed effectively, leading to disconnects between departments such as R&I, Services, and Product & Process Development (PPD).
- The alignment between overall business strategy and product development activities was not always clear, with an overabundance of products and platforms suggesting a diffusion of focus.
- Process Variability:
- The application of quality management practices, such as Failure Mode Effect Analysis (FMEA), was inconsistent and not standardised.
- Learning from experience was largely individual and not formalised into systemic improvements. Different teams employed varying development methodologies (e.g., waterfall for hardware, Scrum for digital and electrical teams) with difficulties in integration.
- The application of Agile rituals and behaviours was inconsistent across the organisation.
- Problem Percolation:
- While risks were noted informally, there was no structured approach to proactively managing them or making robust decisions early in the development cycle. The prevailing sentiment was a focus on current issues rather than proactive risk mitigation.
- Missing Materials:
- Crucial information for defining customer value and capturing regional requirements was often missing or not systematically gathered, hindering the start of an effective workflow.
The overall Lean-Agile maturity level was assessed as low (1.0 out of 5.0) across the Technical Operating System, Management Infrastructure, and Mindset, Behaviour & Capabilities, indicating a clear need for a structured improvement approach.