Read just about any book on Agile software development, and you will be told that iterations must be two weeks...
in length. But we all know that when working with embedded systems, and their intimate relationship with the hardware that they run on, it just isn’t possible to have engineering turn around board releases in that kind of time frame. Does that mean that you shouldn’t even try Agile development? No. Instead, work your teams in iteration lengths that make sense, each according to their needs.
Why should we iterate?
Iterations are the secret sauce for successful Agile development. They allow us to accomplish three very important things.
First, having a timebox defined helps give a team the focus to develop working software that addresses a defined set of features with a defined stop. This is helpful to insure that needless gold plating of code does not occur. The team is forced to focus on providing features giving business value at the end of every iteration heartbeat.
Then, by measuring the amount of effort that a team can achieve in these iteration heartbeats and applying this velocity against the size of the product backlog, we can derive project duration estimates that get better and better over time. We can then get an early indication of how well the project is tracking against a desired completion date, and adjust either dates or features so that the project always makes sense.
And, finally, we reduce risk by gaining missing knowledge early, including the risk of late integration. We may not know enough about whether the product we are building has a market. A quick feature preview product may answer that. Or we may not know enough about the effort it will take to implement a feature using a particular framework. Nothing helps raise everyone’s comfort level like actually trying out some unfamiliar framework. And, the big risk that everyone faces is the risk of late integration. If we follow the traditional waterfall V-Model, we are betting that the components we build in their entirety will integrate easily and without issue right before final testing. That never fails, does it? (Note the sarcasm!) Personally, I’d rather see the Agile concept of successive development of small slices of vertical software functionality to insure that my “architectural wedding cake” does not resemble the Leaning Tower of Pisa.
I hear that my iterations should be two weeks long…
That is correct. The common wisdom is that teams who have never tried Agile before should probably try two-week iterations. That iteration length has been found to be a good place to start and a fairly common balance of iteration overhead (iteration planning, demo, and retrospective) against iteration benefits (continuous flow of business value that comes from iterative delivery of working software.)
Much of the benefit that comes from these relatively short iterations accrues from the ability of a delivery team to estimate and plan their work for the next two-week period with far greater accuracy than for a much longer iteration period. The effect is very much like lifting the haze of limited visibility when flying, as things with uncertainties suddenly become much clearer because we don’t have to look as far into the fog of development.
But I develop hardware, too. This isn’t going to work for me!
But there is a problem with the two-week iteration suggestion, as it applies to embedded software development. The unique problem facing many embedded software development projects is that the software being developed is very tightly coupled to the hardware that is controlled by the system under development, especially those components that are analogue (and very often non-deterministic) in nature. Often, hardware engineering cycles extend 90 to 180 days. Too many times, it is just impossible for the hardware folks to show any working hardware changes in a two-week iteration cycle. Does this imply that Agile software development iterations must be 90 to 180 days as well?
If we adjust our point of view, we can easily see that the problems being worked are simply different in nature. We still want to be able to take advantage of Agile’s ability to help reduce risks by having “check points” that are relatively small in length, and avail ourselves of the benefits that the Agile iteration feedback loop provide. The benefits that we are speaking of here are risk reductions to address such problems as poor project completion date estimation risk and costly late integration rework risk. But we must come to grips with the concept that our teams for software and hardware are going to be different in the way that they work together.
The best way to cope with the problem is to cleave the project into the two development camps and work to a virtualized conceptual model of what the product will ultimately be. Software developers can be working against an emulator for much of their time, developing and testing (hopefully, in an automated fashion) against the virtualized hardware presented to them in a software emulation of the target hardware. Meanwhile, the hardware folks are developing the actual boards to match the emulator’s functionality. This style of developing is very similar to the best practice that we see when doing object oriented development: Depend on an interface, never on an implementation.
In Agile terms, when we plan a release and go through “Iteration zero,” we must agree on two things. The first is the iteration lengths. For a product with a 12-month development window, this may require 90-day iteration lengths for the hardware folks and two-week iterations for the software folks. The rule will then be that fully integrated testing on the integrated system can be done every 90 days, so we can catch issues (such as race conditions) related to hardware early. Meanwhile, the software people can enjoy the benefits of their very rapid two-week iterations. The second thing that we need to agree on during “iteration zero” is the interface that the software will use. By this, I mean that we have to agree on which devices will eventually have drivers written for them, and how they will work with the software. Emulation of the hardware portion may then be performed, and both teams can be set into motion.
Suggestions for determining iteration length
Here is an unordered list of things to consider when deciding what an iteration length should be:
- The release length. You need to have several iterations to allow changed requirements to be incorporated and defects to be resolved.
- How long priorities can remain unchanged. Normally, software changes more rapidly than hardware.
- The cost of iteration overhead. Normally, Agile software iterations carry a small amount of sessions that get held. But hardware prototypes are usually far more costly.
- Experience of the team. For teams that are new to Agile, you should err on the side of shorter iterations, while they adjust to the new modality of collaborative development.
Embedded software development is usually much more difficult to do in an Agile framework. But the benefits will outweigh the pain, and allow your teams to reduce project risks early as they develop product.