What if we rethought what a process framework should be in the first place?

Okay. Now I want to make a crazy suggestion.

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 industry needs to change how it measures and plans and there's no way it will be able to do so without our help.

Story Points as Food Pellets

Ever see a team invest a bunch of time into deciding how many story points they could claim at the end of a sprint?

You get what you teach people to give you.

Positioning story points as valuable encourages people to treat them as rewards. Rather than trying to be productive and "earning" points, time will be wasted trying to claim points for work that isn't really done.

Wasted time erodes productivity, and lowered productivity provides more incentive for credit-grabbing behaviors. A vicious cycle ensues.

This is what you get when you set story points up as these little food pellets meant to modify the behavior of your developers: Developers whose behavior is optimized for getting story points, not writing software.

The solution is simple but very hard: Start tracking what you want.

Not something you think will lead to what you want. Not something you consider to be an integral part of what you want. Track whether or not you are actually getting what you want.

Levels of Done

Previously, I pointed out that an engineer's definition of done should extend at least as far as their software being immediately deployable. That's a step in the right direction.

I think another step is to adopt this simple threshold of done:

Customers are deriving value from this behavior/story/feature.

You can't know you're done without attending to everything that needs to be done:

• Working software.
• Deployed in production.
• Released to customers.
• Validated with feedback.

Making the standard of done customers actually getting value measures all the things that matter without any risk of measuring something that doesn't.

If it's not self-evident, that's because customers actually getting value is the whole point of what we do...

Feature-Branching Defers Work

To quote Homer Simpson: "Did we lose a war?"

I thought we licked this problem in the aughts and early teens. Maybe it was just Seattle or maybe I'm projecting personal victories onto the industry at large.

For some reason, feature-branching is all the rage, again.

The Product Pee-Pee Dance

It's urgent. It's emergent. It's the end of the world!

Get it out now. Right now. No. Now's too late. Get it out then.

I call it the "product pee-pee dance", where an organization hops from foot to foot until they push a product out to production, whether it's ready or not.

Mistrust Squared

Let's say you're testing process/infrastructure/pipeline is something in which you have 80% confidence. That is when you run your tests (however you run them) you think you have a four out of five chance of finding any given problem.

Sometimes, people want to do multiple test passes in order to reduce risk. For instance, if your chances of finding a problem are four out of five on the first pass and four out of five on the second pass, then it stands to reason that the chances of it being found are 24 out of 25 if you do two passes.

Benefits of Focus

Earlier, I mentioned that the done-centric culture of a truly Agile organization is largely about focus.

Focus has a lot of positive benefits and I'm not going to get into all of them.

Here's a short list, that is good enough for this blog entry.

• It highlights impediments by forcing them to be seen as part of the workflow - if you can't switch focus, it's harder to "look away" from a problem.
• It makes large batch sizes more obvious.
• It minimizes knowledge loss in the course of a task.
• It discourages work on less important tasks when more important ones are done.

There's probably an entire series of blog entries about the importance of focus.

Agile Speed

People seem to mistake the point of a lean or agile process's claim to deliver quickly.

They think it means "get people going fast" or "get people working harder". Reduced to its essence, the interpretation is often some form of "get people doing more".

Yet, most of the agile claim to speed is not in how fast someone works. It's in how much they don't do.

Focus Versus Urgency

Many modern software development frameworks emphasize getting to done.

When transitioning to such a process from a traditional project-management structure, a lot of people seem to map this to the old concept of urgency. In other words, they think that "get to done" means "rush".

Done Theater

How done is done?

To me, done means (at the very least) there are no more engineering tasks required for deployment. In other words, as a developer, you can put the software in a customer's hands right this second and the only thing stopping you is some external force.

The Pernicious Racing Analogy

Ever heard one of these?

"Let's get it right this sprint."

"Let's get to the finish-line."

"It's a marathon, not a sprint."

How about it's not a race at all?

The Destructive Power of Conflation

Let's play a game.

Imagine you have two changes that need to be reviewed by another person before they can be integrated into your main code line. These code reviews are done without any context and only against the diff of the proposed change.

Don't worry about whether or not you think this is a good idea. Just set your beliefs on that subject aside and play the game.