Thursday, June 16, 2011

System engineering and agile

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,
Delicious
 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.

2 comments:

  1. We've got the write something around "connecting all the dots." Rarely in agile is there an exprienced, trained, and qualified Systems Engineer (present company excluded).

    The SE framework would be a great way to connect all the dots. You've got most of it in your book, but now that DoD NDAA Section 804 is out, all the agile folks are rushing to provide solutions, ignoring all the past processes that are known to work for their specific problem domain.

    ReplyDelete
  2. Unfortunately, there's not much in the way of system engineering empathy or sympathy in IT, whether agile or not.

    ReplyDelete