Somebody asked me the other day about the intersection of system engineering and agile. In effect they asked: what are the common elements between them?
My list is pretty straightforward, and more or less follows the well know V-model of system engineering:
We can more or less go down the list:
- Use cases support the concept of operations, and to some extent, use cases can support architecture development. Architecture, unfortunately, is not specifically represented in most agile methodologies, but it's there, even if not acknowledged.
- Dynamic backlog is the agile practice for managing requirements
- Sprints and iterations is where detailed design occurs, starting with user stories on a card wall and working through test scripts and other design support tools
- Another agile weakness is inattention to system integration and technical verfication of function and performance--a weakness largely due to the small bore focus that drove the original agile thinking. My advocacy is that functional test scripts, written at a more macro level, are the best means to prove integration and verify performance. I wrote a paper about this idea, and you can click here for the document.
- And finally user validation: in the end this one may be the most important for user-intensive systems. Regardless of verification, validation is proof that the user can actually apply the delivered objects effectively to their mission. To keep it short, I won't expound on "effective" or "mission", but they cover a lot of landscape. The agilists put the object in the hands of the users and seek reaction and feedback, hopefully in a timely cycle that is virtuous for the next sprint or iteration.
Photo credit: Federal Highway Administration,
Bookmark this on Delicious
