Playing the Agile Theater

Why firmware development cannot and probably should not be really agile.

Everyone wants to jump the Agile train. It is an industry pandemic and a good one. Although it was originally designed for software application projects, other disciplines and industries have tried to apply its principles with various degrees of success. In the context of this article I would like to answer the question: can hardware-embedded software, namely firmware, like the one developed in many hardware companies, also benefit from this approach?

In order to answer this question we need to distill the main problems of the software environment as well as the essence of software development the Agile movement was designed to solve and analyze to what extent, if at all, it applies to firmware.

The main software development’s characteristics Agile movement was designed to address are:

  1. Dynamic requirements (largely stemming from the hard-earned truth that customers cannot elaborate upfront what they need and keep that steady)
  2. Complexity-induced implementation risks (divided into technical risks (further divided into technological and architectural risks) and information flow deficiency)
  3. Solution progress’ opacity, and as a result – low customer confidence in the ability of the project to meet its commitments
  4. Business value and technical possibility of a piecemeal delivery
  5. Quality (i.e. maintainability) cannot, by and large, be added late in the process

Let’s look at these one by one.

  1. In embedded world HW products which the firmware runs on usually have their full requirements up front. So does the firmware. They are usually driven by Marketing department after having analyzed the current market trends and possibly after having also received requirements from customers. Even if firmware requirements are not elaborated early in the process, the overall requirement frame is pretty stable from the early phases of a project. So the benefit that Agile provides in terms of flexibility to address changing requirements does not have any advantage here simply because of the fact that requirements are not dynamic. A clear evidence for this characteristic of the firmware’s environment is a long-term planning: it is required and expected by the upper management to define the content of many sprints ahead – all the way to customer qual!
  2. Except for a few simple cases, software development is a complex activity which involves several risks: there is a technological risk of choosing the wrong technical direction for a solution; then there is a risk of choosing a poor architecture that will not hold the building for long; then there is a major risk of miscommunication between different stakeholders, mainly between users and the team as well as within the team. In firmware works the technological risk is pretty low unless a language or a processor changes, each of which is rather rare event. Architecture and information flow risks are indeed high and tend to repeat themselves in every product. This is one topic where agile methods (e.g. trying different architectures and frequent face-to-face communication) can bring real value.
  3.  During the development phase the only reliable indication of a progress is a working software. In our case firmware cannot be validated as working correctly before it runs on a real hardware and passes all the tests. Until later in the product development the hardware is not available and the second best option is running it on top of model. While this can be a partial indicator of progress it is not flawless since often model is not readily available where the firmware needs it or not verified. Moreover, this is an internal indication and real customers are not aware of this progress. They are really in the dark until delivery and are often surprised by unexpected delays or poor quality of initial samples.
  4. There is very little value for customers to get a partially working firmware. Customers qualify a final version and deliver to end users only after it passes successfully. Although there are several milestones (WS, ES, CS) they do not reflect evolving features (all of which should be finished by the first milestone), but rather the level of stability and number and severity of acceptable issues. Delivering earlier than that and with less functionality is not really possible or valuable.
  5. Since no partial firmware is delivered to the real customer mid-program there is a higher risk of not adhering to quality standards and a tendency to compromise quality by postponing it to a later phase when internal milestones are (or under thread of being) missed

In summary, a traditional, closer to a Waterfall approach (with some adjustments) seems to better suit FW development than purely Agile one.


Leave a Reply

Your email address will not be published. Required fields are marked *