I was hooked when the author wrote that “velocity is the function of speed and direction.” Too often, we don’t remember that there is tremendous value to planning an activity prior to embarking upon it. I am known for saying that your chances of getting somewhere are a lot better if you understand where you are going, but the Thomas Merton quote, “People may spend their whole lives climbing the latter of success only to find, once they reach the top, that the ladder is leaning against the wrong wall reads better in this context.
My observation is that agile teams too often mistake the idea that the team should define the goal as they develop the application as permission to “make it up as they go”. I know, I am being a bit harsh here. But I believe that taking sufficient time at the beginning of the process improves velocity (for those not technical readers: productivity) without sacrificing the benefits of agile, i.e. points the team in the right direction, but allows for the flexibility to refine the product along the way instead of at the end of the process. There is a balance here, you don’t want to turn your agile process into waterfall, but at the same time you can’t ignore the need for enough detail to make sure you ladder isn’t up against the wrong wall.
In the context of product development, this means that the product team needs to think through (and document) the product in enough detail to inform software engineering’s agile process while not handcuffing them with too much detail encouraging the interaction between the product team and software engineering team thereby filling in missing details and polishes the product of the collaboration.
I haven’t quantified the cost of avoiding this advice, but I can say that I have seen the most productive programmers look like laggards and that isn’t good for morale or retention.
https://queue.acm.org/detail.cfm?id=3352692
Copyright 2019 Howard Niden
— you can find this (days earlier) and other posts at www.niden.com.
And, if you like this post: 1) please let me know; and 2) pass on your “find” to others.
The velocity of an object is the rate of change of its position with respect to a frame of reference. (Wikipedia) Frame of reference=direction?
Howard,
Whatever work is undertaken, without knowing the intended outcome, how can the end result be what is needed or desired? Agile or not, someone needs to define the expected outcome. Just finishing something quickly does not mean you designed or developed the right thing.