Agility
Jasdev had a great post on moving too fast:
But, Agile almost entirely misses the other side of the coin: regimented rest. We can’t expect teams to knock out a monotonically increasing amount of story points, sprint after sprint. Sometimes, you have to move slower now to move faster later.
Somewhat adjacent to this is the best advice I’ve ever received as a developer:
Focus on being the highest order derivative you can be.
As an entry-level developer, you’re a simple function: you take time as an input and produce business value as an output. 1
Then as you mature as a developer, your work doesn’t directly produce business value: it produces an increase at the rate at which others can produce business value. Suddenly, you’re a first-order derivative.
And then you go further than that, becoming a second-order derivative: transcending from velocity to acceleration. Your work helps others increase the rate of change.
And so on and so forth.
I think this trajectory of increasing abstraction — stretching out your objectives over a longer and longer timespan — is natural, and good. Don’t worry about how to accomplish this week’s work; worry about how to accomplish this year’s work. Decoupling yourself from short-term inputs, like speed and time, is good: it’s a sign that your concerns are larger than the day-to-day.
Put more succinctly: agility isn’t about distance — it’s about nimbleness.
Or, to quote Murakami in What I Talk About When I Talk About Running:
Sometimes taking time is actually a shortcut.
- Of course, there are other factors: your team, your codebase, your goals. But all of those are, at least starting out, constants. [return]