Select Page

In our many years of consulting at PM Power, we have found one thing in common. While many customers exhibit similar patterns, say, in goals for agile adoption, their business and product context heavily influence what agility means to them. Nowhere is this clearer than in the case of organizations engaged in embedded systems development and trying to be more agile to meet customer needs, market and technology trends.  It is not just hardware coming into the picture that makes context more important. The very nature of even the software components  – embedded in this case – requires a nuanced view. Agile needs to adapt to the embedded context and not the other way around.

Our consulting engagements provided us a lot of actual data on what works and what does not work in agile adoption in embedded systems development. Many traditional approaches and long-professed practices handed down from non-embedded domains needed a ground-up review. Some of those traditional handed-down approaches are:

  • Scrum as an approach has the first right of refusal
  • Daily Scrum must be daily!
  • Relative size and story points are always a must; estimating in days & hours is bad
  • Every sprint must have a demonstrable, meaningful chunk of value
  • True agile means you need to have cross-functional teams
  • An independent Validation & Verification function is an agile anti-pattern

So, context is everything for agile in embedded systems even as Agile Values and Principles universally apply.

Over time, we have assembled a set of contextual agile adoption guidelines, artifacts and curated external references collectively called Agile in Embedded Systems (“AinE”).

One of our artifacts is the AinE playbook under “Contextual agile adoption” in the diagram above. The playbook is organized along agile topics and FAQs from our customers on “how to” in the embedded space. Here are some excerpts from the playbook.

Q1: We are organized as specialized component teams – not as cross functional feature teams. How does it affect our agile adoption?

Our guidance:

  • Starting the agile journey with disruptive changes upfront is not a good idea
  • If specialists are scarce and vital for the entire development lifecycle, the guidance would be to go in for / continue with mostly component teams; otherwise, if “flow” of features is more important the guidance would favour more of cross-functional teams
  • You can surely experiment with cross functional teams down the line, taking stakeholders along in the decision process; in short, for large organizations, a hybrid of team structures would be the norm
  • You may re-look at the current team structures with the following guidance in team topology options:
    • Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
    • Enabling team: helps a Stream-aligned team to overcome obstacles in technology aspects and actively assisting improvement in capability gaps
    • Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed (for example in AI, Data Analytics etc.)
    • Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams (these are the folks who develop frameworks, introduce tools and transition / support the Stream-aligned teams in usage

Here is a very useful reference on the topic:

Another good reference on feature and component teams is from Roman Pichler.

Q2: We often hear that we must adopt relative size estimation and story points as a core agile practice. We feel our current planning & estimation are working ok; what is the benefit of a new approach?

Our guidance:

  • Firstly, nowhere does it say use of relative size estimation is an acid test in agile adoption; the Scrum Guide makes no reference to how to estimate; also, refer Mike Cohn’s excellent blog and our point of view in another blog
  • There are different levels of planning: portfolio, product, release, sprint and daily plan. The estimation technique used at a given level should be appropriate for that level; for example, at release/Program Increment level, with only high-level information available on requirements relative size estimation (say, T Shirt sizes or Epic points) would be appropriate rather than absolute estimates in days)
  • At sprint planning level, as more information is available (through backlog refinement), work estimates in days/hours are recommended at sub-task level for team members; as team’s mature teams, they may just use story points and dispense with effort estimates
  • Relative size estimation technique does offer a number of significant benefits but concepts like story points may be a bit hard when they are estimating effort as well (why both, they would rightly ask); what estimation technique to use is essentially the team’s call (with some org-level guidance as needed)

There you have it – a couple of excerpts from the AinE playbook. Hope that gives you an idea. Some of the other topics covered in the AinE playbook are:

  • Collaboration in the embedded system eco-system, covering Customers, Partners and Service Providers
  • Agile and Compliance
  • Agile in Automotive Embedded Systems
  • Agile in Hardware
  • Good practices in engineering for embedded systems
  • Equipping roles for Agile: System Engineer, Release Train Engineer, Security & Safety Engineer
  • Podcasts with industry leaders & practitioners on emerging trends

We publish blogs regularly in our website A recent blog for you to take a look. Please post your comments and suggestions for new topics of interest. We would love it if you could contribute blogs and be guest speakers in our webinars & podcasts on AinE. Let us know.

Do feel free to share your views. You can reach us at Thank you!