Get certified - Transform your world of work today


Why Agile Does Matter in an Embedded Development Environment

3 March 2011

Bent Myllerup

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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Sabine Canditt, CST,CEC,CSP,CSM,CSPO,REP, 3/8/2011 10:13:13 AM
Hi Bent,

thank your for the nice article. It is very encouraging for others to try cross-functional teams across disciplines like HW, mechanics... The embedded world has big potentials for Scrum which have hardly been explored until now.

How big is such a cross-functional team you are talking about?

Kind regards
Bent Myllerup, CST,CEC,CALE,CSP,CSM,CSPO,REP, 3/9/2011 2:49:39 PM
Hi Sabine,
Thank you for the feedback. I agree there are big potentials in the embedded world for use of agile practices. I also notice a rising interest for implementing Scum in those environments (in my own portfolio the embedded clients will soon outnumber the pure software clients).
Depending on the size of the projects, the typical team size is usually between 6 and 10 developers. It varies from organization to organization were-either functions like sourcing, PTA and so on are part of the team or not. I prefer having persons that are concerned about production in the team, but due to organizational constraints, that is not always possible (at first).
Rosa Olafsdottir, CSM,CSPO, 3/10/2011 7:37:52 AM
And thanks for an interesting post.
We are considering our options for embedded software teams where I work and I have these questions:

How does the team commit to finishing a sprint - probably not as a whole or?
Do you have a separate definition of done for each field (HW/SW)?
How do you play planning poker? (Developers separately?)
How much does the team understand each otherΓÇÖs work?

We have actually decided to have "pure" developer Scrum teams. Our idea is to have the electronics and mechanic engineers participate in the Scrum teams planning and review sessions. They are planning on running their ΓÇ£thingsΓÇ¥ through a Kanban wall (visible to the Scrum team). Everybody is co-located and sitting in the same space.

Thanks, Rosa.
Bent Myllerup, CST,CEC,CALE,CSP,CSM,CSPO,REP, 3/10/2011 2:32:22 PM
Hi Rosa, thank you for your feedback and questions to the article.
Regardless of the teams are functional or feature teams, it is most important that the team commit as a whole, because it is the results and the value the teams brings to the customer that counts - not the effort in doing some technical activity. As you indicate, it can be quite challenging to get a mutual commitment in a feature team that have members with different professional skills like mechanics, electronics and software. One of the key points in achieving this is to set a shared goal for the team as a whole. Another important matter is to go beyond the basic mechanics of Scrum by forming the team through teambuilding and coaching. You can read about some of the approaches I usually follows in my article: or, for further readings: dig into the book ΓÇ£Coaching Agile TeamsΓÇ¥ by Lyssa Adkins ΓÇô it is simply a great book!
Regarding the definition of done: I distinguishes between ΓÇ£Acceptance criteriasΓÇ¥ ΓÇô the agreement between the development team and the Product Owner, and ΓÇ£Done criteriasΓÇ¥ ΓÇô the criterias agreed by the team for each of their development tasks. I believe that there should not be different acceptance criterias for hardware and software because the context here is value for the customer, but I can easily support different done criterias for hardware and software if you see those criterias as described above.
I usually explain the term cross-functional team as a number of persons with a common goal and mutual commitment, who all together has the skills and capabilities required to get the job done. Individually they are experts, but they should also be capable and willing to fill in for each other. Therefore, team members shall have a basic understanding of each otherΓÇÖs job and estimate by Planning Poker as one whole team.
Your idea sounds interesting and I hope you will share your successes and challenges at some point.
Eigil Myrhøj Nielsen, CSM,CSPO, 3/13/2011 4:21:46 AM
@ Rosa
Regarding planning poker in cross functional teams. We have a team of 6 developers, evenly distributed between HW, SW and mechanical engineers. They play planning poker all together with success. It was a little bit complex from the beginning, but now, I see it as an advantage, not big, but anyway. Mechanical engineers learns, what challenges the SW developers has and they can easily challenge the SW developers and vice versa in the complexity discussion of a specific backlog item. When you have no direct share in a task, you often have a total other view on the complexity and therefore, brilliant, unforeseen questions, can surface.
We run 3 week sprints and try to do some rough planning 3 sprints ahead. The rough planning is made only in the specific teams, as the rough planning is only used for foreseeing a trend in the overall long time planning.
Edward Newton, CSP,CSD,CSM,CSPO, 3/29/2011 12:29:50 PM
Thanks, Bent. Our company is also investigating Scrum for our embedded work. We use scrum in all of our other software development but, of course, there is skepticism and confusion as to how Scrum can be employed to help our embedded development. Keep writing!
Samuel Hedinger, CSM, 4/15/2011 10:26:44 AM
Hi Bent, thanks for your article. We use scrum since Feb 2011 in our R&D electronics department. We work on an embedded project which includes hard- and software. We are firmly convinced that scrum helps us made better progress in the project! One problem we figured out is until the platform hardware and basic software modules are developed the product owner, member of the product management team, is sometimes helpless of preparing the backlog because he do not have the technical background. How do you solve this problem?
Bent Myllerup, CST,CEC,CALE,CSP,CSM,CSPO,REP, 4/20/2011 6:46:42 AM
Hi Samuel,
It is important to remember that, even though the backlog is the responsibility of the Product Owner, preparing and grooming the backlog is a collaborative process that should be carried out by the Product Owner, the team(s), domain experts, customers and stakeholders (Roman Pichler is describing this very well in his book: ΓÇ£Agile Product Management with ScrumΓÇ¥).
The approach I follow is to let the Product Owner work with the team and domain experts on the product vision in order to have the overall key selling points, features, interfaces etc. defined. From there, the team(s) can work on block diagrams for software and hardware (FPGA blocks might be in a separate artifact) and drafts on mechanics. We usually use sprint zeros with spikes in order to make investigations and define those blocks. When the block diagrams are defined (and remember: they do not have to include every little detail ΓÇô like the backlog, they will evolve over time), you can have your backlog writing and estimating workshop as a collaborative event (it might take several days).

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up