Developing embedded software using Agile methodology

With the development of embedded hardware, careful attention is dedicated to the design and creation of highly detailed specifications that can be used to source board components. This is usually followed by a phased delivery set of milestones including: prototype, implementation, test supplier qualification and final release to production. This regimen offers the advantage of ensuring quality and functional requirements being met by the time manufacturing. Taking a waterfall approach to hardware development can minimise any risk of downstream issues once hardware goes into volume production.

Software development is perceived to be completely different. The "soft" part in software implies there is an inherent ability to change along the way. Unfortunately, this can give management a false impression that software projects can easily accommodate change with little to no additional cost or schedule impact. The perception of a software developer is further glamourized in Dilbert cartoons by Scott Adams. [1] A programmer is considered to be a breed apart—working in a world combining art, technical inquisitiveness, social discomfort and sometimes even magic. All you need is creative talent, endless hours, lots of coffee, a PC and a handful of software tools.

As hardware development projects are perceived to complete on a timely basis, software development projects are often late and cost much more than was originally planned. Just ask any project manager in the embedded industry who has worked on both hardware and software projects. Given the choice, many project managers would rather manage hardware projects.

Since both software and hardware projects may be under development at the same time, both sets of teams must collaborate. As hardware developers tend to work in a very structured and organised manner, software engineers tend to perform a lot more trial and error. This "software way of life" can be quite a challenge for management and I've seen more than one attempt in my career to convert more-disciplined hardware engineers to become programmers. This rarely works due to different skill sets and a radically different mindset.

Rather than demand that software people conform to hardware design approaches, a better way is to take lessons from enterprise and mobile software computing. We must identify the right approach for software development that marries the way software developers like to work with how work is performed.

Audit your software development lifecycle
Years back, my Datalight software development team was having a tough time juggling incoming product management requests making project schedules difficult to achieve. At the time, any mention of changing our process methodology to agile (specifically, Scrum) was met with, "no way! That stuff is just a fad."

I found it was easier to let the team identify what didn't work at the time rather than force fit some newfangled agile methodology on them. So, I asked the team, "OK, what can we improve with our software development process?" Through rather intense brainstorming, we were able to compile a list of improvements to be made:

1. Decisions made throughout a project lifecycle appear ad hoc and reactive.
2. QA gets involved way too late.
3. By the time the customer sees the product, it isn't what they originally expected.
4. Some features being developed aren't getting completed on time. We usually find this out way too late to course correct.
5. Handoffs at key milestones are ill-defined and by the time the project is completed, the original specifications and design documents aren't even close to what was actually implemented. And yet, we never have time to update them.
5. Requirements are often too abstract with little to no mention of priority or guidance for validation.

Comparing project management approaches
In the software development community, there are two competing schools of thought for managing the process of motivating a team to deliver quality products: waterfall and agile. Figure 1 illustrates the differences between the two extremes with waterfall being more structured and less adaptable, while agile (Scrum and eXtreme Programming shown) is less structured and more adaptable.