When you bring up the topic of feedback in the Agile community, people seem to think along the lines of the kind of thing that happens in a Sprint retrospective. Observations gathered in Sprint retros are valuable and important, and it’s certainly an improvement over the kind of insensitivity that was the norm in pre-Agile IT departments, but there are other kinds of feedback as well.
The Profit and Loss statement, for example. The P&L seems to be considered a bit of a relic in the age of Agile, but it has stood the test of time as a valuable feedback mechanism, especially when avoiding bankruptcy is among your KPIs.
Something about Enterprise Digital Transformation initiatives has always struck me as odd, with everyone looking much like they did before, but acting in ways inconsistent with their former decorum.
I gained some insight into this dynamic through the story of Phinias Gage, retold by Tim Harford in his book “Adapt”.
About 20 years before the American Civil War, Phinias was blasting rock for the Rutland and Burlington Railroad, just south of Cavendish, Vermont. Phinias was tamping down blasting powder in a rock bore when the friction of the metal tamping rod generated a spark which prematurely kindled the explosive dust.
In the moment of ignition, Phineas had just turned to talk to his crew behind him, inadvertently bringing his head in line with the trajectory upon which the rod was about to embark. The pointed tip of the three foot long, inch thick steel rod blasted into Phinias’s open mouth, cut a path behind his left eye, ripped through the left frontal lobe his brain, exiting the top of his skull, tracing an arc through the sky followed by horrified observers. The 13 pound steel projectile came clattering down among the rocks some 80 feet away.
The unfortunate Mr. Gage had the remarkable fortune to not only survive, but remained mostly conscious through the ordeal, muttering on about the circumstances of the accident to the attending physician a half hour later, while the good doctor stared in disbelief at the gaping hole in the man’s skull.
Although the steel rod carried off a not entirely insignificant portion of the frontal lobe of Phinias’ brain, he recovered and went back to work, although not for the railroad. He traveled to Chile and took a job as a stage coach driver on the Valpariso-Santiago line, evidence that he continued in life as more than an invalid.
Other than being blind in the left eye, he looked like the same man as before. But there was some distinctive change in behavior. Before he had been known as a reasonable man, but Phinias missing some particular chunk of his brain was often belligerent and indifferent to social norms that he had previously respected. In short, while he retained nearly all of the abilities of his former self, he seemed to have lost much of his ability to process feedback.
When enterprises embark upon a Digital Transformation odyssey, it sometimes seems as if they suffer a steel rod blasted through the corporate cranium, taking out the part of the brain that processes feedback about profit and loss, while leaving everything else intact. Whereas before we knew vigilant guardians of the balance sheet, we find purveyors of retrospective narrative, turtles all the way down.
If an Agile Transformation Initiative is going to improve the ability to deliver value to the business, then we should be able to tell the story of that value in the P&L.
It’s true that the P&L aggregates expense data while frequently failing to reflect value realized by quality and productivity initiatives. These shortcomings of traditional cost accounting have been taken by Agile advocates as license to just tell a good story in place of doing the hard work of verifiable quantitative analysis.
Papering over the misalignment between Agile initiatives and the P&L is a lot like Phineas without the feedback part of the brain. You can count on him showing up to work, but you might wonder what he’s capable of next.
Closing the Agile Books
It’s only reasonable that the budget be the voice of the customer. Some of the most important work before us today is to strip away the apparent complexity around what we mean by productivity in software and services, including how to measure it, and to put those metrics in alignment from the Pull Request Edge all the way through to the P&L.
When stakeholders are asked to trust the iterative approach implied by Agile, then they should also be able to incrementally verify that they're getting what they're paying for. Just keeping track of how much money is spent is not enough. Fake metrics like Velocity are not helpful. To support management decisions, process metrics are needed that demonstrate responsible use of resources provided, including systematic feedback needed to keep budget allocation in alignment with how resources are actually needed and used.
Bibliography
Art Credits
wikipedia — "Phineas Gage"
Ana Michelle Godeck — "hands (header), Calculator and Pen, Mannequins"
Before we celebrate victory in having met an objective, we should put some effort into verifying repeatability. Problems in sustaining successful outcomes come in two flavors: trouble rooted in the process itself, and the sundry woes that require special attention. Not knowing the difference means management by wack-a-mole.
Knowing what to pay attention to and what might be safely ignored for the moment is the mark of an effective manager. The starting point is in learning what it means to listen to the voice of the process.