It comes up on almost every consulting project I’ve worked on as a pivot, but this particular conversation was memorable. I was surreptitiously ushered into a room by the product manager (PM). Once inside, he shut the door:
So, I know you guys don’t do crunch time… but we really need to ship by Monday.
I empathized with him, knowing that the pressure to hit the looming (and somewhat arbitrary) deadline was coming from upper management; and that a terrible gnawing fear was settilng in, threatening to drive all his decision-making.
But we don’t do crunch time.
At Labs our culture revolves around a handful of axioms. Perhaps chief among these is sustainability. It is because we value sustainability – seeing the developer and PM as real-life human beings with real needs and limitations – that we place a high emphasis on pairing, TDD and data-driven product management.
Let me explain.
On pairing:
Because we pair 100% of the time, 40 hours a week, we are producing at close to peak efficiency during working hours. There isn’t much time spent on distractions and there isn’t much time wasted going down yak-hair-strewn rabbit holes. We get stuck less often and we keep each other honest striving to balance rapid forward progress with clean maintainable code.
Outside of our lunch hour and a daily 15-minute game of ping poing, we’re writing code and (ideally) delivering business value.
Why do this? Because we believe that putting in a solid day’s work – day in and day out – is a deeply satisfying and humanizing experience. We’ve also found that 8 hour pair-days, 5 days a week – week in and week out – is close to the limit of what’s sustainable. Tacking on an extra hour or four at the end of a long day just leads to diminishing returns; doing so regularly risks dehumanizing burnout. Squeezing much more out of developers just isn’t sustainable.
On TDD:
Because we test drive all our code, we are our future-selves’ best friends. Tests help us write cleaner, more maintainable (and therefore sustainable), code. Tests make future refactors easy and stress-free. Tests keep bugs from creeping in and, when written well, can obviate the need for much traditional QA.
Writing and maintaining a test suite might seem like a wasteful time-consuming effort in the short run. But it pays massive dividends in the long run – both in terms of development speed and developer sanity.
Again: sustainability.
On data:
Because we pair and test drive all the time, a small team of pivots can sustainably maintain a relatively consistent level of productivity. We measure this productivity not in lines of code or number of tests or hours worked. Rather, we measure it in terms of delivered complexity.
We do this using Pivotal Tracker. Tracker allows us to annotate stories (units of feature work) with points. These points are a proxy for complexity (you could also say difficulty) and are determined not by a rigorous formula but, rather, by the gut-sense of the team working on the project. As stories are completed and delivered by developers, and subsequently accepted by the PM, Tracker is able to compute a running average of the number of points completed per week. We call this running average the project’s velocity.
Velocity, then, is a measure of the rate at which the team, in its current configuration, can deliver code complexity. The point is not to compare one team’s velocity to a different team’s velocity — different teams may converge on different notions of complexity. Rather, the primary goal of all this data is to do one simple thing sustainably: to give the PM predictive power.
With this predictive power Tracker allos the PM to see, given a project’s velocity, which features will land within a given time frame. Understanding this is crucial to our process.
Putting it all together
The PM who asked my team to enter “crunch time” was, effectively, asking my team to increase the amount of complexity we could deliver in a given period of time. Complexity delivered is proportional to velocity multiplied by time, so he saw a few options for doing this:
First, we could try to increase velocity by “working harder”. But, because we pair all the time we are already working at close-to-peak efficiency. We might be able to get 5% more by “rallying the troops”, so to speak, but generating a dramatic increase in velocity by fiat will simply isn’t possible.
Alternatively, we could try to increase velocity by accumulating technical debt (“stop writing those silly tests!”, “just throw the feature together!”). But because sustainability is a core principle, we are loathe to do this. Corners cut today will have to be pasted back in tomorrow. Doing so manifests as an artificially high velocity today at the cost of a depressed velocity tomorrow. This is terrible as it diminishes the predictive power that our velocity provides our PM.
Since complexity delivered is the product of velocity and time, we could try another approach: we could increase the amount of time we spend working. Again, we are loathe to do this precisely because sustainability is a core principle. Pulling extra hours leads to an unsustainable culture whose zenith is burnout.
No.
Consistenly, Pivotal’s answer to this problem is to clarify the PM’s role. The PM has many knobs at their disposal but velocity is not one of them.
Instead, given a velocity, the PM is tasked with reordering or simplifying stories (features) to ensure that the stories they want arrive within a given timeframe.
The beauty of this approach is that it brings data to the table. Instead of flying blind and generating requirements that must be accomplished in fancifully short periods of time, the PM is empowered – by data – to make informed decisions about what is feasible within a given timeframe. Even better: the PM can take this data back to his or her superiors and help them reason rationally about the progress of the project.
In short: velocity allows PMs and product owners to make decisions grounded in reality. No suprises. No crunch time. Just a sustainable working environment for everyone involved.
Oh the hubris!
Confession is good for the soul.
The vision I’#8217;ve articulated here is, at best, a Platonic (i.e. idealized) description of how the Pivotal process is meant to work. Reality is, of course, messier. Pairs go down rabbit-holes less frequently than solo-developers – but they still go down rabbit holes. Test suites can vastly improve code maintainability – but writing good test suites takes skill and a poorly written suite becomes a maintanability problem of its own. Velocity is a reasonable predictor of future productivity – but it is most decidedly not a precise science. And while all this sounds so reasonable on paper – communication is one of the hardest things we humans try to do and, invariably, the supposedly clarifying properties of data must first make it through layer upon layer of misunderstanding.
Nevertheless, we aim for this ideal world – striving to improve our process and our selves as we do so. Because the best way to handle crunch time… is to avoid crunch time.
About the Author
