Agile Manifesto for Hardware Development:
- Individuals and interactions over processes and tools
- Working hardware over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
“While there is value in the items on the right, we value the items on the left more.”
Agile project management is a development methodology which has roots in the software development world, used to improve the quality of highly complex software by breaking it down into bite-sized “chunks” which are developed in parallel. Agile doesn’t work just for software, it has been adapted and implemented in many other fields of engineering and design. Optical instrument design is one example, and the quality of the delivered instrument (especially one with many features) can benefit from this approach.
Why Agile?
The value in the Agile development methodology stems from adaptive pursuit of evolving needs and requirements over the course of a development effort (especially a complex development effort). A more traditional project management model is the Waterfall Method, where the development project is laid out in sequential steps from requirements definition through deployment of the finished system.
The problem: Waterfalls
In a Waterfall-type project plan, requirements are gathered up-front and laid out in a detailed plan. From requirements a plan is laid out as follows:
- (Requirements Gathering)
- (Design)
- (Development)
- (Testing)
- (Deployment)
Accuracy in up-front requirements in a Waterfall model is especially important. This is out of necessity- the requirements set at the start of the effort will be implemented to completion unless a scope change is implemented and a new project plan implemented. No inherent method is available for changing requirements without risking the schedule.
Some of the drawbacks of the Waterfall approach can be summarized:
- The system being designed is not integrated and ready for testing until relatively late in the development cycle
- High-priority or high-risk requirements are developed in parallel with lower-priority requirements
- Gaps or problems with the system might not be discovered until the testing phase, late in the project’s timeline (causing a potential timeline delay)
- The customer or user might not be able to give feedback on the integrated design until late in the development cycle.
- If any requirement gaps are identified during development, it is not easy to add or modify the project feature set
The solution: Iterative Improvement
An alternative to a Waterfall project plan is an Agile project plan. With Agile there is still a need for up-front requirements gathering in the form of requested features, but Agile breaks the development cycle into “sprints” where subsets of features are prioritized, developed, and tested throughout the project. From a set of feature requirements an Agile project plan might look something like this:
- Sprint 1 (High Priority Requirements)
- Design
- Develop
- Integrate
- Evaluate Prototype 1
- Evaluate feature requirements, adjust if needed
- Sprint 2 (Medium Priority Requirements)
- Design
- Develop
- Integrate
- Evaluate Prototype 2
- Evaluate feature requirements, adjust if needed
- Sprint 3 (Low Priority Requirements)
- Design
- Develop
- Integrate
- Evaluate Prototype 3
- Evaluate feature requirements, adjust if needed
- …
This approach provides several key advantages in a development project:
- Iterative prototypes of the system are developed and evaluated throughout the development cycle. Findings during these evaluations can be rolled into the next development sprint.
- Features are developed and evaluated in order of priority. High priority features are therefore developed earlier and tested sooner.
- Frequent prototype testing allows for frequent integration evaluation, catching problems earlier in teh development cycle as features are added.
- Getting prototypes into the customer’s hands early also allows for early and continuous feedback during development
- Continuous feedback from the customer also allows for evaluation and adjustment of requirements during development.
So the Agile method delivers iterative prototypes to the customer for evaluation, and cyclically improves upon the prototype designs. The capabilities of the prototypes improve until the minimum requirements are met, at which point a first release is delivered. The delivered system provides a well-tested feature set, and is more likely to meet all customer requirements (including the ones they forgot to mention at the start of the project) when compared to a system developed with the Waterfall method.