Agile for Systems Engineering
20 August 2010
An ex-colleague recently asked me what would an "agile toolbox" of techniques that were applicable to systems engineering projects. After some thought, I came up with the following:
Remember that the contents of such a toolbox are biased toward software engineering projects rather than system engineering (SyE) projects. I've put comments in italics to point out the additional thinking required for SyE projects.
The overall philosophy of an agile project is to focus on the early delivery of real business benefits, that are aligned to clearly defined strategic goals. All parties must buy-in to the fact that in order to deliver the right capability, at the right time, and at the right cost may result in delivering less than 100% of the possible solution. For projects with dozens of stakeholders, what constitutes a "successful project" will differ between stakeholders and you will need to uncover any capability requests that conflict. In addition for SyE projects, a business benefit may be a model or prototype that all stakeholders agree on, rather than working software.
Determine the appropriate level of governance, including the amount of documentation required and obtain buy-in from all parties. There are various checklists available to help with this. An important point is to ensure that if there are multiple layers of governance then these are aligned to ensure that one product serves for multiple simultaneous milestones. For example, a design model could serve as a PRINCE2 stage-end product. For multiple suppliers, alignment of governance will occur across contracts.
Incremental delivery. There are fixed, regular delivery dates, agreed at the beginning of the project. By delivery, we mean production-quality capability. Two key points in agile projects:
- business stakeholders can change their mind about what capability they require. How this change is handled varies between agile methods and is agreed at beginning of project.
- the delivery date is always met; if time is running short, then lower priority features are deferred to a subsequent increment.
For SyE projects, "delivery" may be a model or prototype and may involve commercial stakeholders because delivery activities will be likely to involve multiple suppliers.
Prioritisation of capability. The business stakeholders determine the priority of the delivery capability. This would happen in a workshop – a good technique is the dot-voting method.
Collaborative working. The favoured method is facilitated workshops which are held throughout the project. The key to success is getting the correct people (involving business stakeholders and the development team) in the room and to clearly define the workshop objectives. The objective may be one of: capability definition and prioritisation; design; or acceptance testing prior to delivery. Workshops are also useful in SyE projects, although you may need more commercial involvement.
Other techniques useful in SyE (not necessarily regarded as "agile" techniques in their own right):
- Evolutionary Acquisition. This is a technique whereby the agreed contractual terms vary in different phases of the project in order to reduce risk.
- Competitive Dialogue. This is a technique whereby the customer/supplier contractual terms themselves are iteratively developed - along with sufficient system-scope for a supplier to supply a quotation.
For very large scale systems engineering projects, I suggest looking at the Incremental Commitment Method as an approach that is closest to the agile "ethos".