PDP in the backlog
Scrum teams are self-organised and decide independently how to develop a valuable product. On the other hand, most companies that develop mechatronic products have a cleanly structured product development process (PDP), which was or is an important basis for product development in the waterfall. How does this fit together when such companies take their first steps in agile working? Does the PDP still play a role at all? Or does the PDP prevent agile working in general? We want to show here how PDP and agile working fit together and even complement each other ideally.
The Product Backlog
In agile working, requirements and functional specifications are replaced by the product backlog. Unlike with purely SW products, however, with mechatronic products it is not possible to develop the overall product by realising product features (backlog items) step by step ("sprint by sprint"). In physical products, individual hardware components contribute to many product features that generate specific customer benefits. An enclosure, for example, can offer the customer features such as manageability, design, stability, weight, noise emission and much more. Of course, this is usually done in combination with other hardware components. And it is precisely this combinatorics that makes it impossible to proceed with mechatronic products in which a new product feature or a new product characteristic is realised sprint by sprint.
Therefore, basically a complete product is always developed in different stages of maturity. Starting with virtual samples, through individual functional samples to prototypes and pre-series. It goes without saying that agile working in the environment of mechatronic products also tries to create an MVP (Minimum Viable Product) after each sprint, for which feedback can be obtained from stakeholders during the review. Customer orientation and proximity are decisive success factors.
But in practice it is usually not possible, as with software products, to show a bit more of the product after each sprint, where feature by feature - prioritised by customer value - an overall product is created. A mechatronic product must be complete at the start of production. A later (hardware) update is usually not possible.
The backlog for mechatronic products
This difference between software and hardware means that a different kind of backlog work is required for mechatronic products in order to ultimately develop a successful product. Every type of product naturally combines that all product features are listed in the backlog. Otherwise, the backlog could not replace the specifications.
But on the one hand, as explained above, it is usually not possible to develop these product characteristics step by step, and on the other hand, various specialists usually work on the same characteristics from different perspectives. For example, the noise emission of a product is influenced by numerous elements. And in order to achieve a certain target value, all elements must make a contribution, either in the form of emitting less noise or by having better damping properties.
For this reason, a distinction is often made in mechatronic products between a product requirements backlog and a team backlog. In the former, as the name suggests, all product requirements are kept. In the team backlog, these requirements are broken down. Either into sub-requirements that the respective specialists have to fulfil. Or, since this breakdown is also not possible systematically, at least in the initial phase, into tasks - i.e. activities. The specialists have to complete these activities or tasks in order to develop an overall product that fulfils all requirements.
Against this background, the PDP serves as a valuable task repository for the backlog. In phases, the team discusses which backlog element is useful for the current project and which is not. However, this selection - PDP tailoring - is also useful for classic project management. Because development projects are not necessarily comparable. For example, a different process should be used for small "facelifts" than for a large new development.
Agile teams use this tailoring capability of the PDP for the transition into their team backlog. They decide which elements are helpful to them and which are not. This approach creates a valuable symbiosis between the agile backlog and the past experience stored in the PDP.
CO Improve has supported numerous projects where this symbiosis has been won for the benefit of the companies. We can show you how an agile backlog and a PDP can complement each other perfectly. Talk to us.
Your benefit
- Agile working brings clear competitive advantages also in the development of mechatronic products
- Self-organised teams manage a backlog with high quality
- The empirical values stored in the PDP (product development process) on how good products are developed are usefully incorporated into the backlog work.