If you've been tracking what I've been saying, this week, then you've probably read as far as this entry, I which I suggest that the basis for bad technical-decision-making is probably a poor understanding of the relative costs of various decisions. I also made the argument that large, complex corporate budgets and success-metrics tend to confound the problem and make it even harder for some decision-makers to make good long-term decisions.
Now I want to explore process frameworks and how they play into this.
I'm not a deep expert on any of these process frameworks but I know plenty about several of them. In fact, I'm probably as much of an expert as a lot of the people who present themselves as experts. I just don't claim to be.
I'm going to list a few frameworks but I think my argument is true for all of the frameworks of which I am aware:
- Scrum
- SAFe
- Kanban
That's enough to make the point. At least from context, I've heard evangelists for each of these process frameworks make the argument that businesses need to change how they measure.
My first experience with this was when scrum trainers told my team to use Story Points for estimation rather than hours. The idea being that we could empirically determine what a story point means for capacity planning and get better at estimating.
Great.
It didn't work, of course, but great.
It still represents an early attempt to shake up how software projects are measured.
Then came Business Value Points. That oughta do the trick, right? Of course, it didn't, but at least people were trying.
Story Points and Business Value Points both generally failed to have a positive impact (within the scope of my observation) because they were attempts to make the traditional spreadsheets work. They were stand-ins for other numbers that were already being used and empirically backing into a meaningful value was supposed to fix...something...but it couldn't fix the corrupt idea at the heart of it all; the model of software development that is, to this day, essentially descended from manufacturing.
To address those ideas, new processes and mentalities were brought to bear. Plan this way, keep these things in a backlog, manage that kind of work in process, favor this kind of effort over that one, et cetera.
Then there were people arguing for no estimates. There were (are?) proponents within seemingly every framework. There seemed to be a lot of them in Kanban. So much so that I began to associate the two in my mind.
I'm not sure if that was ever an official part of Kanban for software development. Nor do I care. What I do know is that it was another attempt to address the measurement problem in software development and it was brought to bear as a supporting change for some other goal (an "agile" process, usually).
Scrum and SAFe both have explicit mechanisms for their "inspect and adapt" principle - which many believe to be the core of their efficacy. I view this as an attempt to bring qualitative measurement techniques into software development.
The picture I'm painting is that luminaries within the software development industry have been attempting to improve how and what organizations measure for...well...decades, now.
Yet, it always seems like it came as a sideshow, though. It always seemed like there was a shrink-wrapped process that (some people claimed) was going to solve everything and, also, maybe, kinda, you might need to tweak how you measure a little bit.
What if we flipped it on its head? What if we defined a new paradigm for managing software development organizations with a radically different message?
The message, right now, is "You know what's going on, we'll help you do a better job."
I think the message should be "You're going a good job, let us help you know what's really happening."
I think what we need is not process frameworks with a side of metrics. We need metrics frameworks and you can buy a process framework à la carte if you decide you need one.
We could start with "Keep managing how you manage but change how you measure" and see where that gets us.
I think it might get a lot more traction because it's more respectful of the skills that most software development leaders do have. Most of them do know how to manage large groups of people and work with large complicated budgets.
Even if it didn't get widely adopted, though, I think the organizations where a metrics framework landed would benefit a lot more than the ones that are trying to adopt or grow a new software development lifecycle. They'd get more out of the effort because we'd be addressing the real kernel of the problem: Not what we do but what we see.
We need to start working with leadership teams, and maybe even boards, to help them define metrics that set software "projects" (products) up for success. We know these things are going to last a lot longer than a quarter, so quarter-to-quarter measurements aren't going to do the trick. Let's get together as software professionals, define a standard for how success and progress can really be measured in software development, and then start pushing that.
The message, right now, is "You know what's going on, we'll help you do a better job."
I think the message should be "You're going a good job, let us help you know what's really happening."
I think what we need is not process frameworks with a side of metrics. We need metrics frameworks and you can buy a process framework à la carte if you decide you need one.
We could start with "Keep managing how you manage but change how you measure" and see where that gets us.
I think it might get a lot more traction because it's more respectful of the skills that most software development leaders do have. Most of them do know how to manage large groups of people and work with large complicated budgets.
Even if it didn't get widely adopted, though, I think the organizations where a metrics framework landed would benefit a lot more than the ones that are trying to adopt or grow a new software development lifecycle. They'd get more out of the effort because we'd be addressing the real kernel of the problem: Not what we do but what we see.
We need to start working with leadership teams, and maybe even boards, to help them define metrics that set software "projects" (products) up for success. We know these things are going to last a lot longer than a quarter, so quarter-to-quarter measurements aren't going to do the trick. Let's get together as software professionals, define a standard for how success and progress can really be measured in software development, and then start pushing that.
The industry needs to change how it measures and plans and there's no way it will be able to do so without our help.
