“Agile” is the latest buzzword in systems engineering. It has a fair share of both adherents and detractors, not to mention a long list of companies offering to sell tools, training, and coaching. What has been lacking is a thoughtful discussion about when agile provides value, when it doesn’t, and how to adapt agile practices to be effective in complex systems engineering projects.
I don’t claim this to be the end-all guide on agile systems engineering, but hope it will at least spark some discussion. Please comment on the articles with details from your own experiences. If you’re interested in contributing or collaborating, please contact me at benjamin@engineeringforhumans.com, I’d love to add your voice to the site.
Part 1: What is Agile Anyway?
A broad overview of Agile as a concept, including the difference between Agile processes and being agile and critical discussion of how Agile most often fails. Also, adapting the concepts which have been successful for software development in order to find success in a systems engineering context.
Part 2: What’s Your Problem?
Henry Ford’s apocryphally faster horse, a solid example of how customers can misunderstand their users, and requirements myopia. In short, requirements-based acquisition is terrible, let’s refocus on solving problems and providing value.
Part 3: Agile Contracts and the Downfall of Requirements
Requirements are the antithesis of agile1: impractical, time consuming, prone to misinterpretation. But, they are the foundation for every large DoD acquisition. A major paradigm shift is required for true agile systems engineering.
Part 4: Digital Transformation
A slight detour to discuss an important enabler. Integrated digital engineering has enormous benefits by and of itself. It also addresses many of the objections to agile systems engineering and agile hardware engineering.
Part 5: Agility on Large, Complex Programs
Putting together all of the above to describe how to implement agile systems engineering. Includes discussions of key roles, cross-functional teams, and the critical value of SE on this type of effort.
Footnotes: