Speaker: Mark Wilson
Venue: Hamburg (June 1st 2015), Copenhagen (June 2nd 2015), Stockholm (June 3nd 2015), Helsinki (June 4th 2015)
It seems that systems engineers are continually being assaulted by the word “agile.” Our software engineering colleagues use “agile methods” to develop software-intensive systems, and there is no shortage of advocates exhorting us to apply agile methods to systems of all types in order to build “agile systems” that can easily and rapidly adapt to continually changing requirements. Is “agile” merely a buzzword that will soon be replaced by another engineering or management trend promising better success with less effort?
Agile development/engineering is not a new idea. Some industries have practiced what we now recognize as “agile development” for decades. Some of the techniques described in the agile development literature, such as schedule-driven, incremental deliveries of value, have been common practice in some industries for many years. Nevertheless, the classic project management and systems engineering fundamentals—planning, organizing, directing, and controlling a project to satisfy stakeholder requirements—have not changed and are inextricably tied to the development of the technical solution.
Some people passionately argue that the underlying fundamentals of agile methods are significantly different from those of more traditional development methods. Even the United States Department of Defense has embraced the idea that “requirements-driven development” has become unaffordable. This has set up an “either/or” debate, pitting agile development advocates on one side versus traditionalists on the other.
It is clear to us that there is no “right” answer on whether agile or traditional development methods are preferred for delivering good quality systems. However, it is also clear that some system development efforts lend themselves to one approach or another at various levels of the system hierarchy. The choice of technical strategy depends on, among other factors, the existence of a collaborative development environment that includes developers and eventual system users, the volatility of stakeholder requirements, the number and complexity of interfaces, and the competence of the development team.
We take a pragmatic view that, as with other management techniques, there are agile best practices that provide value across a spectrum of situations to improve one’s opportunity for satisfying stakeholder expectations. Some efforts lend themselves to a more agile approach, while others are best served by a more structured, top-down development method.
This presentation presents the case that there are agile development best practices that have value and should be embraced by systems engineers. We explore agile concepts, suggest a working definition and responsibilities for “agile systems engineering,” discuss the increased responsibilities of stakeholders in agile projects, and suggest ways of assessing project status in the absence of a traditional, requirements-driven plan.