Skip to main content

The Missing Piece to Agile

Yes, let's be agile! Let's "Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.", as stated in The Agile Manifesto.

But there is a LIMIT to how much you can be agile. This limit is defined by this triangle.

Product managemenet triangle

Quality = Budget(cost) x Time x Scope.

There are situations where you literally cannot be anymore agile. Agile fails to acknowledge that:

  • As time goes down, ability to be agile goes down.
  • As less budget is allocated, the less that the team can be agile.
  • As scope increases, the harder it is for the team to be agile.

The problems in most companies is that the variables of budget and scope are fixed, and since an amazing quality is expected, the engineers are expected to work longer hours. But because engineers are working longer hours, the quality inevitably goes down, morale goes down, etc.

The Missing Piece​

How do you prevent yourself from losing the ability to be agile in the first place? Agile does not speak of this. In other words, The Agile Manifesto is only reactionary, it is not proactive.

Prevention​

Truth​

The truth is that requirements will always be in development. Therefore, features can never be fully complete before they are handed off. But in order for the machine to move, requirements should reach a status of having all ambiguity resolved before being handed off. This is called getting requirements to the Definition of "done". Acknowledging this truth will allow teams to optimize agility.

Solution​

To get requirements to the Definition of "done", the solution is to resolve all ambiguity by labeling requirements with a status.

  • luminary
  • possible technical limitations
  • unknown
  • unforeseen
  • gaps in understanding
  • incomplete
  • complete
  • optional

There are many benefits to this:

  • Estimates can be more effectively made - understanding that there are possible technical limitations or some features are frankly incomplete / need more time to be thought through can allow other parts of the organization to plan around these limitations.
  • Saves A LOT of time - Since gaps in understanding will be bridged, this will clarify the constraints and limitations that PM, UX, and Eng have to work with. THis means that their effort will be spent more productively.
  • UX mocks contain a lot of ambiguity, leading to misinterpretations. Resolving this ambiguity will prevent any "UX Audits" from being needed to be done.

I have listed only 3 main benefits, but these 3 benefits have a ripple effect throughout the organizations.

In Summary, Agile is sometimes impossible, as understood by the equation quality = budget _ scope _ time. In order to prevent these situations, we have to optimize for agility (Agile never mentions how you can do so). Optimizing for agility means that requirements are stamped with the Definition of "done" by resolving all ambiguity.