Fractal V Lifecycle

At the drinks after Ivar Jacobson’s talk, I was speaking with a project manager from Honeywell who’s about to adopt a more agile development approach.  Honeywell is in the industrial automation business – they do systems engineering to deliver solutions for things like building automation and factory process control.  Their business context is one of the most challenging for agile methodologies:

• Mature technology/problem space where customers can accurately define most of their requirements up-front.
• High integrity systems that have regulatory demands for “heavy” process documentation to provide assurance.
• Many/large development teams.
• Large systems where no single customer can represent all stakeholders.
• Customers who don’t have time to be “on site” with the development team full-time during development.
• Customers who want (or who are required!) to only sign contracts where they know what they’ll be getting.

The last four are standard problems for agile.  Ivar had actually discussed how agile approaches don’t fit some business conditions, but that nonetheless you can often adopt “30%” of the agile practices.  One of these practices is iterative development: it’s certainly been popularized in recent times by agile methodologists, but it’s not unique to agile methodologies.
Ivar presented the waterfall lifecycle as a strawman “unsmart practice” in his talk.  I was surprised by the number of hands that went up in the audience when he asked how many people were using it!  However, Honeywell (like most systems engineering companies I know) doesn’t use the waterfall lifecycle – instead they use a “V” development lifecycle.  The V lifecycle is like the waterfall, but is bent upwards in the middle, with coding and unit testing down at the bottom (pointy end) of the V.   The well-known advantages of the V lifecycle are that it shows how testing lines up with planning at each level of design abstraction, and shows how you can progress test planning early in development, concurrently with design/coding.

The Honeywell project manager had a problem – how could he do agile development in his business context?  I suggested that he adapt the V lifecycle he was already using.  The structure of the V lifecycle can easily support iterations. Normally people think of the V lifecycle as a “big V”, spanning an entire development project.   The first obvious way to have an iterative V lifecycle is to have lots of sequential “little Vs” – each cycle up and down could be done as short V sprints.

But that exposes the customer to each iteration, and the Honeywell project manager told me that his customers don’t want to run an acceptance testing and sign-off process every 2-4 weeks during development!  To address this, you can use a less obvious approach, which here I’m calling the Fractal V Lifecycle.
Let’s work our way there in small steps.   So to start with, consider that instead of iterating the whole V in each iteration, you can instead iterate some of the lower parts of the V more frequently.  So if you had two low level iterations, you’d have a W lifecycle!

To generalize to the full Fractal V Lifecycle, you can see that it’s possible to have many internal iterations at various levels of design abstraction. giving you a (quasi-)fractal V.

I call this “fractal” because it reminds me of the Sierpinski Triangle.

The Fractal V Lifecycle is really only quasi-fractal, because there’s only a finite few levels of recursion in a development lifecycle, and because the internal iterations don’t have to be regular or symmetric over the course of the development lifetime.
The Fractal V Lifecycle solves a problem – it lets you do iterative development when your customers only want to be involved at large infrequent milestones.   It gives you the flexibility to adapt your iterations to suit your business conditions and technical environment.   But it also retains the shape of the V, which lets you keep using your existing systems engineering disciplines to comply with customer/regulatory requirements for process assurance.
There’s one thing that the Fractal V Lifecycle doesn’t explicitly decide for you – when should your iterations finish?  This is a major difference between iterations in agile and traditional plan-driven methodologies: agile development approaches have time-boxed iterations (usually between 1 and 4 weeks long), but traditional development approaches have iterations defined by scope.  The Fractal V Lifecycle is consistent with either approach.