Describe Agile without describing Scrum

  • Agile does not specify a way of working, but typically it is used interchangeably with “Scrum” which is a more accurate definition.
  • Agile itself is most accurately described as a manifesto and a set of principles. It should be noted that:
    • These are now 21 years old
    • They were written by 14 white programmers at a ski lodge.
  • These don’t make it any less good, but note that as of the era (2001, see Tech industry) this was a time quite different to the current time, before the emergence and maturity of UX and research and product management practices, before the iPhone, before space billionaires, etc. The manifesto/principles still largely hold true because they are now almost self-evident. At the time of writing tech as we know it was nascent, unregulated, and largely immature. Fundamentally these artifacts attempt to describe a value system where high quality work is valued over the other necessary but ultimately annoying parts of software associated with capitalism/exchange of labour/goods for money (”contract negotiation”, “following a plan” etc).
  • Agile is typically described in opposition to Waterfall, which is defined by up-front planning, management of resources across multiple streams, dependency management and mapping, futile risk mitigation and the delusion of knowing everything and then efficiently delivering everything.
    • Of course Waterfall exists for a reason - namely that the manufacturing process or other real-world creation process (including building houses, etc) do not have the luxury of infinite re-dos.
    • Software development, as the Agile authors realised, was different, in that it could be reversed, refactored and rewritten, allowing for the decision making to be spread out over the course of the process rather than made all in one go at the start.
    • As a bonus, by spreading decision making out over the process, the Agile authors realised they could empower the “non-business” types to be able to actually decide some of the important things. With an obvious chasm between the business and the tech team in 2001 (tech is magic), having plans made by the business and implemented by the tech team was a recipe for disaster.
  • Over time these themes - democracy, equality, inclusion and flexibility - have been transformed, weaponised and re-integrated as a buzzword which is typically used so loosely it has ceased to be particularly helpful. This semantic bleaching is why I find it much more useful to refer to the specifics of the implementation (usually Scrum) than Agile itself.