Planning remains one of the most common stumbling blocks for the hardware teams that are transitioning to Agile way of working. Generally the statements we hear are either - "we are agile, we do not plan that far ahead anymore" - or - "we are different we need our detailed Gantt chart". As often the truth lays somewhere in the middle and the key is to successfully transition from waterfall to agile planning suitable for hardware development.
The Agile Planning Onion, as a structured concept, was introduced by Mike Cohn in his 2005 book Agile Estimating and Planning. It organizes planning into six levels: Product Vision, Product Roadmap, Release Plan, Iteration Plan, Daily Plan, and Task-level details. Cohn’s model formalized this layered approach in the context of Agile software development. The book further develops into the fact that only 3 out of these 3 horizons, Daily Plan, Iteration Plan and Release Plan, are of immediate importance for the team. This probably is how many teams found a way out of planning for the long term. However when it comes to hardware development this type of planning simply does not fly. Milestones and stage gates exist to synchronize the various involved engineering disciplines across the organization (i.e. R&D with Supply Chain Management, integrators with engineers involved in series manufacturing, and so on).
Hardware teams have different constraints and need long-term backwards planning in order to meet their objectives. You are probably asking yourself now what has to change then? The answer is the level of details and the purpose of the long-term plan.
Backward long-term planning in agile hardware development is a strategic approach that starts with the end goal and works backwards. Nothing new up until now, as any project method with milestones and stage gates has done this since forever. The Critical Path Method teaches us the need to take lead times (e.g. supplier delivery times) into consideration when defining a plan with milestones, key decision moments, or stage gates.
The difference in applying this approach for Agile Hardware teams is the level of detail of this plan. While milestones, gates, or key decision moments are defined and tracked, the Agile organization (i.e. teams, tribes, teams of teams, Agile Release Trains, and so on) has a cadence-based structure to look at the capacity at hand, the remaining time until a milestone, and utilizes the flexibility in the work to do to reach that milestone. Hence, the Agile organization complements the 'backwards planning' with a shorter term 'forward planning'. Depending on the frameworks and techniques used, this is a look-ahead of 2 weeks, 3 months, or sometimes even 6 quarters. Any of these forward looking plannings is highly flexible in nature. The further we look ahead in time, the less granular the forward planning is. Hence, the 'Agile Planning Onion' is a layered approach to planning, from very flexible (inner layer) to relatively rigid (outer layer).
The built-in tension between long-term backwards planning and short(er)-term forward planning emphasizes the need for the parties involved in either of the plannings to come together and align on the challenges ahead to reach product delivery milestones. Work descoping or rescoping, tradeoffs, and the inherit need for transparency is necessary to collectively work towards the build of a viable product which meets market expectations.
Transitioning isn't without obstacles, several companies that have moved to Agile development for their hardware teams have cited that the transition comes with a:
Agile planning for hardware development required two perspectives, long-term backwards planning and short-term forward planning.
Instead of viewing planning as a rigid, linear process, backward long-term planning in agile hardware development is about:
While short-term planning is about structuring work and collaboration between teams and team members and planning for validation and de-risking of the long-term plan.
Agile planning in hardware development is not about eliminating planning, but about creating more responsive, collaborative, and market-driven planning approaches to de-risk your projects.