Tuesday, October 2, 2018

Agile Speed

People seem to mistake the point of a lean or agile process's claim to deliver quickly.

They think it means "get people going fast" or "get people working harder". Reduced to its essence, the interpretation is often some form of "get people doing more".

Yet, most of the agile claim to speed is not in how fast someone works. It's in how much they don't do.

There's a certain amount that needs to be done in order to accomplish a goal. Then there's also extra work we create for ourselves. Put something in the wrong place and have to account for it in the right place? That's extra work. Define something multiple times and have to maintain all the extra duplicates? That's extra work.


a graph showing effort increasing over time because the cost of poor feedback and bad design keep growing
Poor technical practices increasing the effort required for the same amount of scope

All clever designs share a common trait: they attempt to reduce the amount of extra work added, creating room in the schedule for more core work. As a result, it looks like a team goes faster when they truly master these skills. In actual fact, the amount of effort being expended is lower, even though more work is getting done in any given timeframe.

Agile processes work on the same principle at an higher level. Instead of limiting extra work for the scope you have, they limit the additional scope for the goals you have. It creates a similar effect even though less may be demanded of a team in any given timeframe than was expected in the pre-agility days.

A graph showing the cost of poor practices and waste work dwindle as an agile adoption takes hold.
An agile process driving unnecessary scope and poor practices out of the workflow.

Agility is about agility, not speed. It turns out that the quick selection of your next action based on an understanding of your current circumstances leads to more speed but speed is the outcome, not the mechanism.