Chris Travers
Nov 2 · 1 min read

There’s another side too which is a sort of hammer syndrome which comes out of agile: “Agile works in the following cases therefore everything should be agile.”

The problem is, if you want to achieve Agility, then most of your software should not be Agile. If everything is Agile, then stable contracts between components are hard to maintain and you end up spending a lot of time trying to reason about what a change probably broke. But if you have a stable platform, you can be very, very agile in the areas where the requirements are not well understood yet or may be subject to change.

So here are my own efforts to formalize my views:

  1. Subsidiarity is key. Teams should be as autonomous as possible and management exists to coordinate teams with eachother, facilitating knowledge sharing.
  2. Components with known stable requirements should be engineered to be stable, should be tested as to their known requirements, and should have those requirements and interfaces based on those requirements well documented. In most systems this will be a majority of the code.
  3. Where there are unstable or unknown requirements those may be tested but should not be documented. Test cases for these should be separate to facilitate situation awareness on test cases.
  4. The same people should be involved in requirements gathering, design, coding and testing of any component. This is one of the most important insights of agile.
    Chris Travers

    Written by

    Software developer and database architect. Strong ties to a SE Asian culture. Come here for rants against globalism, code, and more.