Outcome Over Output
In the light of what I wrote about reducing the whole agility hoo-ha to just two questions for everyone to ask themselves some time ago, this article has some nice insights on a common misconception that has agility confused with speed of delivery. At a lower level and applied to software development, the confusion often is about project management vs., well, software development. If we measure velocity, we don't measure quality. Ultimately, what we should care about is quality, not velocity. Our customers most certainly care about quality more than about velocity. A prematurely released update that introduces bugs just doesn't land well. Anyone who ever installed a major macOS upgrade before the .1 version came out will know what I mean. But I digress.
Do yourself a favour and read the article, please - and in the two-questions framework, doing the most important thing can also mean to have a measurement in place that actually measures what's being delivered, instead of how much time is invested.
Tags: work