The first principle behind the Agile Manifesto is:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
It's the highest priority! This has got to be really important, but why? What good is delivering software that can't do everything the customer wants? Well...
- The customer can tell us if we're building the right software.
- The customer can see our progress.
The first item minimizes our own risk that we might waste time building the wrong software. The second item addresses the customer risk that we might not deliver what or when they expect. It's a win-win.
A consequence of prioritizing early and continuous delivery is that between deliveries, the software should be improved in a way that provides additional value to the customer. This affects the way that we plan our work.
A traditional approach
Traditionally, embedded software is developed in a way where each increment of work does not necessarily create new value for the customer.
Consider a system with some sort of external sensor and a bunch of LEDs. There is going to be some sort of driver for the sensor, a driver for the LEDs and some application logic.
Simple application architecture.
A traditional development plan often takes a "horizontal" approach to planning work, so that we might build the LED driver, and then the sensor driver and then finally the application logic.
A horizontal development plan.
None of these components when "completed" however, provide any additional value for the customer. The customer can't do anything with the sensor driver. In fact, they can't do anything until everything is done. This is the "big-bang," the moment at which we can finally show everything to the customer. Hopefully no equipment or people are damaged in the explosion.
Vertical feature slices
If we turn things around and consider what the system does (i.e. it's features) instead of how it's constructed, we can plan our work to implement features -- the things the customer can actually use and test.
For example, perhaps we want to turn on an LED when the sensor reaches a particular value. Implementing this behavior requires implementing portions of each software layer. This is a "vertical slice" through the whole system implementing a single feature.
A single feature -- a vertical slice of the application.
When this feature is done, it's something we can actually test and deliver to the customer. It provides the customer value. They can see incremental progress and provide feedback. Does it work like they expect it to? It's way better to find out immediately, since we can make a smaller correction to get back on track.
As we identify other features to implement, we plan and deliver them in subsequent increments. Each software delivery is another opportunity to test, show progress and get feedback.
The application can be partitoned into all of it's features with vertical slices.
When we deliver in increments it's also much easier to respond to change or problems.
Using the horizontal approach, we're on fixed path where we need finish everything before we can deliver. Running out of time is not option -- we can't just stop -- we need to keep going until its done. Otherwise, we won't have anything that we can give to the customer.
Using the vertical, incremental approach, we can stop at any point and we still have something that we can deliver. If we run out of time we can reduce the scope by simply not implementing certain features. Hopefully we've prioritized them so that we already did the important ones first.
So, take a look at your software they way your customer does. Incrementally deliver them features that they can use, test and provide feedback for. Both you and the customer will have a better understanding of your progress, and you'll know as soon as possible if there are any problems.