The software industry has achieved great results by introducing agile methods like Scrum. Agile methods create outcomes that benefit customers as well as management and employees of the business. The results have been proven in the form of increased employee satisfaction, higher efficiency and functionality that meets customer needs with greater success. But is it possible to transfer those methodologies into product development projects that also include electronics and mechanics? The nature of such projects, including activities like sourcing, manufacturing of prototypes and so on, does not exactly go hand in hand with methods that use short iterations with frequent deliveries. Anyway, the answer to the question asked is actually: "YES". So far, several Scandinavian companies have benefited greatly from implementing Scrum in their product development departments and I have been so fortunate to work with a good number of them.
When starting to implement Scrum in an embedded environment, I usually work with the Transition Steering Group to design a feasible layout for the organization. Depending of the size of the organization and the product they are developing, the layout will either be functional teams, feature teams or a mixture of both. Large organizations have a tendency to prefer functional teams such as pure hardware teams, pure mechanic teams and pure software teams. Personally, I rather prefer feature teams, and that is also the approach we have used in my local sandbox: The award winning Danish audio-equipment company, TC Electronic. The approach to the adoption of Scrum at TC has been to concentrate on whole-product-development instead of just introducing Scrum separately in software or hardware development. The Scrum teams at TC are truly cross-functional and consist of both system programmers, embedded developers, electronics engineers, mechanic engineers, designers and testers – most of them also have domain knowledge from being performing musicians themselves. So it is interdisciplinary work as homage rather than isolated academic disciplines. The teams work closely with related business managers and their Product Owner.
This approach has created a fantastic foundation for understanding the customers and users of the product, which supports the development of integrated and coherent solutions and eliminates bottlenecks in the teams. This is because each employee has committed herself to the ultimate goal (launching the final product) rather than individual targets related to her profession, and therefore she is filling-in for overloaded colleagues when needed, despite the eventual differences in profession.
There are elements in electronics development that almost collide with the principles behind Scrum. For example, PCB-spins and the sourcing of components, which usually are protracted activities, pose a major challenge for the short and intense sprints. Where sprints are the progress of maximum one-month's duration with well-defined objectives for blocks of functionality, PCB-spins are more like cycles of more than 6 weeks where the engineers work their way towards being so complete as possible with a full electronics PCB. When implementing Scrum in hardware, there is a risk that backlog items related to HW will be stated as ongoing from sprit to sprint or being water-Scrumish phase driven. When trying to map PCB-spins to Scrum sprints, without defining specific goals for each sprint, you can easily dilute the impact of Scrum. If you define the sprint goals of a PCB as "Phase 1", "Phase 2","Phase 3", etc. instead of "critical components sourced", "schematic ready for layout", "floor planning done", etc.; you take away the ability to evaluate whether milestones are actually reached or not. The result: The measurement of project progress is not better than using a traditional method. From my experience, this is one of the most common pitfalls when going into embedded agility.
Another approach to challenge this 90%-done-syndrome in hardware development is to implement an iterative practice for hardware development that is inspired by TDD. Here the HW block-diagram is used as the driver for preparing the backlog, defining done and visualizing progress. The concept is to make potential releasable blocks of circuits in each sprint that will concurrently be integrated into the final PCB.
Scrum is easy to understand but hard to implement. Implementing Scrum in an embedded environment does not make it significantly easier. Despite the difficulties, the benefits highly outnumber the challenges and help your embedded development organization to perform and fight the competition in your market. By cleverly implementing the appropriate practices, forming and coaching your teams plus applying the feasible skills of leadership, your company will be well on its way to success with agile.
Share on LinkedIn
Share on Twitter
8