Tom Breur
27 March 2016
Scaling to capacity is one
of the cornerstones of Agile. The Agile Manifesto stipulates a dozen principles and one of them reads: “Deliver working software
frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.” It is fair to say that our bias nowadays has
increasingly shifted to even shorter time scales, as compared with 2001.
By gathering feedback and
measuring progress in (very) short cycles, we mitigate and reduce schedule
uncertainty. The shorter your cycles, the more o them you will run in the same
amount of time. Hence, you will get more “practice” assessing progress. With
experience, teams “know” how much they can take on (commit to) for the next
iteration (“Sprint”
in Scrum).
It is only natural for
managers to be “impatient”: it is their job to manage resources (mind you: not
just “people”) in order to achieve the best possible results in the shortest
amount of time. So “pushing” for results is management’s understandable bias.
Submitting reasonable requests is fair, and I guess it is only human to be
fallible, and sometimes cross the line from fair to unreasonable.
There’s a reason why we
strive for a sustainable pace, another essential component of the Agile Manifesto. It’s in nobody’s interest
(management the least) to accrue technical debt or burn out people. I’ve
written before about technical debt (like: here on documentation and here on “fudging”, and my post on quick & dirty has drawn more traffic than any other, I believe), and so have many
others since 1992 when Ward Cunningham coined
the term.
When undue schedule
pressure causes absenteeism, more errors, and unhealthy staff turnover, this
obviously harms the team’s capacity to deliver features at a high and steady
pace. Scaling to capacity implies respecting people’s boundaries, and acting
accordingly. You just can’t fit 10 lbs of potatoes in a 5 lbs bag…
No comments:
Post a Comment