Value is not binary
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This is the first principle behind the agile manifesto, and it’s hard to argue that it is not the most important. Especially because it says it’s the most important right there in the sentence.
But it has a huge flaw. Dare I say supermassive even. And it’s so blatant that I’m not even going to save it for later in the article. I’ll give you the supermassive black hole right now. Are you ready? The first principle of agile says nothing about how valuable the software needs to be.
“Continuous delivery of valuable software”. There is one very important word missing. That word is “reasonably”. The software needs to be reasonably valuable! Duh!
Value is not a binary term. It exists on a spectrum. It’s a very wide spectrum that we are all too familiar with. On one end is very low value software and the other is high value. Maybe the spectrum has Wikipedia on one end and, oh I dunno, Candy Crush on the other? (Sorry Candy Crushers). Why is this word reasonably so important when it comes to the first principle of Agile? Because it tells you where to allocate the resources you are spending on the software. Your resource allocation should be proportionate to the level of value they are generating. Make sense? Pretty standard.
Proof the black hole exists
I hear you. You might be sitting there thinking: “Dude, of course it has to be reasonably valuable. The word reasonably is implied in the principle. The requirements wouldn’t have gotten endorsement from management if they weren’t reasonably valuable. It’s all baked into the methodology, don’t beat up the whole methodology because they left one obvious word out of the principle.”
Ok, fair enough. I don’t agree with you, but I see where you are coming from. However, if reason is implied we should be able to see evidence of it in practice, agreed? To see it in practice what would be some telltale signs that it is happening? Typically in order to determine if something is reasonably valuable, there must be logic or reason behind the value decision. That’s what reasonably means right? So to make it simple, in order to make a value decision based on reason, a person must apply a heuristic such as: Is _____ valuable enough that we should spend _____ .
So if we are making sure that software is reasonably valuable in practice, then we should be able to fill in the blanks in the above heuristic for most features being built with software. No news here.
Unfortunately, as you may know, in practice, chances are this not happening on most development teams. Chances are that each feature is not broken down to a dollar cost. Also it’s very unlikely that a particular person or process determines whether money should be spent on a specific development effort down to each individual feature or deliverable. Why?
Well, there are a many reasons but I submit to you that the most guilty contributor is that most development teams are a fixed cost. And if they aren’t completely a fixed cost, their cost is usually tied to a project which is approved over a long period of time. So they’re fixed for a period of time.
I know, I know , the manager is supposed to be doing this. But let me make this even more simple for you. In short, I am saying that in most cases the manager does not have the option to say these words:
“Ok, it’s Thursday, the sprint starts Monday. I am not seeing reasonable value in this sprint so we are canceling it and starting up again in 3 weeks”.
Why can’t the manager do that? With the team being a fixed cost, they are getting paid whether the sprint happens or not, so we might as well have them work on low to medium value tasks (if we are lucky). They aren’t going to sit around and twiddle their thumbs so we might as well give them something to do.
Ouch, that hurts. I know I cringe too. But can you search your soul with me for a second? My guess is that you see the truth out there. Think of the most pointless feature change you’ve seen on iOS, Android or Windows. These are coming from teams that are the best at what they do, yet they still fall victim to feeding the beast. When you have a fixed cost sitting there that will burn with zero value, you’ve got to feed that beast.
Excuse me, Mr. Blackhole, would you stop sucking so much? Thanks.
How do you reverse the pull of the black hole? Well, at the risk of being obvious, you’ve got to create an environment where you can say:
“Ok, it’s Thursday, the sprint starts Monday. I am not seeing reasonable value in this sprint so we are canceling it and starting up again in 3 weeks”.
How do you do that? That is vastly different for every organization.
Chances are you’re organization has created an environment where managers can wield the above “anti-black hole words” currently for smaller pieces of work. Usually where the ABW (anti-black hole words) can be used has to do with the complexity of the requirements for any given piece of work. Maybe the copywriters come in for a few days only, or maybe you have a partner that helps you with configuring some of your off the shelf applications for one sprint.
However, in many organizations as complexity increases so does their ability to use the ABW. Have a look below. Where can you use the ABW right now in your firm? Where can you say – “Ok, it’s Thursday, the sprint starts Monday. I am not seeing reasonable value in this sprint so we are canceling it and starting up again in 3 weeks”.
Whichever level your organization is at now, your next step is to move up to the next level. Or maybe you are at 2.5, and your goal is to get to 2.8. It’s that simple. You must be honest with yourself, in order to say that you have one of the levels down pat, the majority if not all of the projects in that level need to be ABW friendly.
It is possible to have an organization where the ABW can be used at all levels. Many organizations are using new frameworks to move up this spectrum and so can you. Don’t let the black hole suck you in!
Some sources to start with:
https://www.thoughtworks.com/books/edge
Sources to avoid:
Anything that talks about “Agile Trains”. Using the train metaphor for your development team is only food for the black hole. Would the train keep leaving if it had nothing on it? I don’t think so.