Now that we’re apparently Post-Agile these days, I’d like to take a moment to remember why we — as an industry — were so excited about Agile to begin with. In particular, I’d like to look at some of the practices of Agile, and how they came around in the first place. There was a lot of wisdom and value in the Agile practices, and I’d like to call out that wisdom and value explicitly, as well as acknowledge where the difficulties with these practices were.
Moreover (and most importantly!) I’d like to hear from you about your experiences with these particular practices.
The first topic I’d like to hit is “points” and “velocity”. There is/was a lot of confusion about points, their value, and how they’re to be used. Because of that, the concept of “velocity” is totally lost. So let’s go back to basics.
The Problem:
Development estimates are notoriously difficult, yet are mandatory for business planning. Although developers have a sense of the size of work, trying to nail down a specific amount of time regularly comes with a +/- 100% margin of error. Further, the very basis of Agile is structured around refactoring the development process itself (more on that later), but there is no clear productivity metric out there (SLOCs punish refactoring and reward copy/paste; “tasks accomplish” assume equal weighting per task, etc.).
This Solution:
Create an artificial/abstracted metric of work — a measurement of the estimate itself. By giving tasks point estimates, we can measure how much work can get accomplished based solely on estimates. The amount of estimates the team can accomplish in a fixed time period is called the team’s “velocity”. This velocity naturally fluctuates over time, both in response to the team’s changing sense of the value of a “point”, as well as the team’s changing productivity. And while human tendencies to find patterns and make norms will probably cause points to standardize to some amount of “real work”, there’s no additional value in trying to measure that “real work”: we already know how many points of estimate we can accomplish, and we know how much we’ve estimated our current tasks for, so we have a good sense of expected delivery dates.
Difficulties:
- Bootstrapping the system is tricky, since people need to be given a sense of what “a point” is worth, but equating a point to a time period ends up fixing the value of a point in people’s minds, thereby destroying the flexibility of the system — and that flexibility is the biggest value! So kicking off the first estimation session by explaining “eight points is a task that can be accomplished in one day” immediately undercuts the system.
- Granularity on the system is lacking, and an implied linearity is a bad model for development. Development is by nature non-linear: for example, very simple things may only take 15 minutes, but even moderately complex things might take half a day, and very complex things might involve hours of work, not to mention conversations and meetings that span weeks. Unfortunately, if an average task is 5 or 8 points, 1 point is an overestimate of a one-word change: eights 1s does not equal the same amount of effort as one 8, even at the abstract level of estimation.
- Trying to decide on a way to measure a team’s velocity is non-trivial. Do you use a rolling average? The last iteration’s velocity? Some number negotiated between the product owner and the development team? Without some kind of velocity measurement, the point system’s value vanishes, but a bad velocity measurement results in bad estimates for delivery dates and often in an over- or under-worked team.
What are your thoughts about using a point system? Was this assessment fair? Have you worked in places where it went well? Went badly?
One Comment
Robert,
My experiences with abstracted units of measurement for estimated work have always failed or caused problems when the people in finance find them.
Part of this may be due to poor communication within the organizations that I’ve worked, but I think the natural tendency for someone in the CFO’s org chart is to want to turn those abstract units of work into something that can be used as a planned capital expenditure.
It is my understanding that to accountants, paying software projects are the same as paying for any other durable good. On their spreadsheets they budget purchasing equipment the same way they do for purchasing software.
It’s complicated and there are people who understand that domain far better than I do. What I do know is they want to know how much a project is going to cost when they define their budgets. Changing the cost or the scope seems to be a big no-no. GAAP accounting may be the antithesis of agile software planning.
As a result of the accounting rules; the points, the ideal work days, the glimzarks, or whatever metaphor for work the software people want to call them turn into hours and then ultimately into dollars. Hide the points as much as they will, the people who pay the bills will find some numbers and they will likely adamantly insist that those points have some dollar value.
How do we move beyond agility? I don’t know. It’s a domain that I’ve contemplated for a while. I think the needs of accounting and finance need to be taken into account and reconciled before we can move beyond agility.
In practice, I think that capitalized abstracted planning can be done. What needs to happen though is that the scope of the project must be abstracted sufficiently to allow the project enough room to evolve the details of the implementation as the project is in process. The challenge there is getting everyone on the same page. Getting buy in from people in vastly different facets of an organization can be very difficult in practice.
To an accountant, waterfall is an ideal methodology.