Ask the average person today why they’re currently doing or planning on moving to Agile and they’ll probably say “it’s faster”.
It’s a very popular answer.
But faster at what exactly?
If pushed, they might elaborate “faster delivery“. And then give you a funny look as if to say “What other kind of faster is there?”
So whilst on the surface of it, this sounds like a purely good thing — there is, or at least there can be, a dark side.
This focus on faster delivery in my experience has often led to implementations of Agile which are nothing more than a relabelling of Waterfall, with stand-ups, “stories” and JIRA® added like props.
The “agile” or “Scrum” part is applied only to the bits of the endeavour deemed to be “the delivery”, which in its most extreme form means “The part where the code is written“ .
This is what I believe most people mean when they say “Agile Delivery” — a practice which I would prefer to refer to as “Incremental Delivery” — but more on that in a separate post.
But what if that’s not all there is? What if there was more? What if there was better.? (Even if it was harder)
On the Origins of Faster
As ubiquitous as this “Agile is Faster” belief is today, it’s hard to pinpoint exactly when people started equating Agile with speed. After all, the term is “Agile” not “Speedy” and it’s the “Agile Manifesto”, not the “Go Faster Manifesto” so the origin doesn’t entirely lie with the name. eXtreme Programming also offers no real hints, the scrum is probably the point in a rugby match with the least amount of forward movement and Crystals, well they just sort of sit there. So it’s not immediately intuitive. It’s certainly not misleading.
At a guess, I would conjecture a few things might be casual here:
There are two Agile Manifesto Principles which mildly allude to speed:
- ”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and;
- “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Which both sound at least a little bit urgent. Although they seem (at least to me) to emphasise regularity more than they do raw speed. At least the term “deliver” is there.
And then there is Velocity…
Whilst a Rugby scrum may be relatively static wrt to delivery, one of Scrum’s most (in)famous contributions to the Agile canon along with The Sacred Lemming Mantra is velocity.
If was a betting man, I’d put my money on velocity and it’s cheerleaders being the culprit here. Whilst the Agile Manifesto principles somewhat allude to speed – they don’t outright say it. Whereas the concept of Velocity absolutely does.
How fast is your Waterfall?
OK, so that’s where it might have come from, but so what? Velocity is great!
What could possibly be the Problem with Velocity?
Well, depending on your perspective, maybe nothing. Or maybe everything.
My personal problem with Velocity is that it’s just a raw measure of output. Even its biggest proponent Jeff Sutherland, talks about how he “rates his Product Owners on a dollars per point metric” — which signals very clearly that the Velocity metric itself, is completely devoid of any value or benefit component.
On an Agile Project, that’s kind of a problem. Especially if you’re not tracking anything else except velocity. It’s no good being early and continuous if you’re not being valuable.
But on a Waterfall project, that’s not a problem. Velocity and lots of it, is all you need. By the time we get to the delivery part in Waterfall, value is assumed. Value was pre-determined and fixed really quite early on in the project, sometime around the point when we got our requirements right and estimates acceptable and it was all signed off.
In this situation, Faster Delivery is absolutely a good thing. We know what we want, you just need to get it done.
Faster in this context also often defined as “Faster than your original estimates” — which is why claims of “move to Scrum get hyper-productivity” are so seductive.
It’s less of a state of being and more like a request “Can’t you get it done any faster?”
But what if that wasn’t true? What if the requirements were not in fact right?
What if, <gasp> the estimates were wrong?
And what if, that sort of thing happened on a regular basis?
I mean, that’s absolutely ridiculous of course, and would never happen where you work I’m sure. But let’s just imagine it’s true, just for a moment, and explore what that might mean.
If this was the case, then when would you want to know that a mistake had been made? (Assuming you have rational and not political goals and additionally don’t have a job lined up at a competitor)
As soon as possible right? Would that be valuable to you?
Damn right that would be valuable. The more time that passes between having made a mistake, and finding it and correcting it, the more damage we do. We humans have a tendency to compound our errors — and this is doubly true with Software.
Therefore, in a world where we only have imperfect information and mistakes are made, then early detection and correction of those mistakes is something we’ll definitely want.
Work it harder
So how do we discover that something is not as we’d like it to be?
Perhaps we should just rely on our people to tell us.
Because people just love to show you that they’re wrong don’t they? I mean, if a developer suddenly knew that a requirement was wrong (and they’d know surely?). Then they’d ask somebody.
And if and when they asked, they’d also be taken super seriously too, I mean there is no chance at all that they’d be branded as a whinger and told to get back to work and mind their own business? (Which is of course delivery)
And further, even if the problem detected was nominally in their realm of responsibility, say the implementation approach or the estimated time to complete. Then there is no chance that said developer would be branded as incompetent having revealed this information?
It’s a good thing we have professionalism, because if any of those things were true people might be tempted to hide problems rather than face the possibility of criticism and ridicule.
Not to mention the fact that a great many people just don’t like feeling incompetent. So they tend to hide the truth not just from others, but also from themselves. Oh right, professionalism totally fixes this too, I forgot.
So considering all of this, there would therefore be absolutely no need whatsoever to say, stop development every two weeks, on the regular, so that we could give feedback on what had been done to date, and then immediately act on that information? And there would also be no need to share a common definition of what it means to be done with something; because there is absolutely no chance that something might work on a developers laptop, and not at all once integrated with all the other changes and put into production. And that we showed you it now, because, well you were here, and we assumed that there would be no problems. Because we are, of course, professionals.
None of this is required obviously, because we don’t ever get angry with each other, not even passively and as a result people never want to hide their mistakes (because we’d also never decide to just stay back and fix them quietly) and because none of this ever happens, none of this is necessary.
The Horror of Harder
Because if you did do that, if you did stop to fix the issues when you found them, then that would impact your delivery schedule.
And that would be terrible. I mean, fixing mistakes slows down your delivery. (As does quality and testing, but that’s a story for another day)
Much better to simply raise a ticket. So when a stakeholder says “You better raise a ticket on that” you can professionally reply “I already have”. And then you will get a serious nod, so that you know that you have been sufficiently professional.
After all, a ticket is as good as a fix. Ask any user!
Raising a ticket allows the Developers to Continue On With Delivery and let some business proxy representative Showcase just how on schedule we are to anybody who doesn’t have anything better to do that afternoon.
Unless of course we interpret the “early” in “early and continuous” to meaning gathering feedback early and continuously?
And not “early” as in “earlier than your pessimistic original estimates you lazy bastards”
Even the delivery focussed “with a preference to the shorter timeframe” principle could also be interpreted to being about getting real world feedback on what we’ve built ASAP as much as it’s about Capital D Delivery.
“Delivery” has such a ring of finality to it. A ring of correctness. Which is the way we like it in Waterfall. A land where everything is perfect and there are no mistakes. Just disappointments and failures.
And ironically if you focus on delivery, you’re more likely to be predisposed to ignore feedback you’re getting from your production users (assuming it’s going to the delivery team at all and not to some BAU or maintenance function)
So putting stuff into actual production quickly and regularly is really just another way of gathering feedback, really really meaningful feedback, as to whether what we’re doing is working or not.
The concept of Early from this viewpoint means “in time for it to be easily and cheaply corrected“.
Time to make it Better.
One of the key characteristics of “Agile Delivery” is that it runs off The Engine of Acceptance Criteria. When I first tried XP as a practitioner, a User Story was a sharpie scrawl on an index card. Most of the User Stories I see today would probably need to be printed out on a roll of toilet paper there are so many details and acceptance criteria. Which is why I guess, these days, User Stories rarely dare to venture outside of their JIRA® branded fortress. Where they are very safe indeed.
In this case, “working” can and usually is, defined as “meets all the acceptance criteria” (or in some case “provisionally meets” as there will of course be a giant test phase at the end of the Project after the “Agile Delivery” is over). Once said “stories” have met these pre-contracted and comprehensively documented criteria, then and only then is it considered safe to “demo” them, as we are now sure there will be no surprises. And surprises are of course awful.
But what if there was another way to define working? One that actually required people directly affected by the software to use to the software before they could make the determination? I dunno, in some kind of regularly schedule review?
If we did that, we could save a bit of time on all these acceptance criteria, sure we might still need a few, but instead we’d be tracking towards whether or not we’d done something useful, instead of merely what we had been told (or could justify having done).
But that sounds like it would slow down delivery! I can hear at least some of you cry.
The good news here is that there is a different kind of faster available to us, not of delivery, but of faster problem solving.
This is what it means to me, that Agile is faster.
It does however mean that we have to start measuring from a different point. Faster Delivery by definition only starts at the point that you’re declaring that you’re ready for “delivery”.
At best, Agile Delivery looks something like this:
We are timing how long it takes from the point we’ve defined and designed our solution to when it makes it into production. You might be overlapping some of those “phases” and I hope you are, but we’re still tracking the same two endpoints.
Sometimes thou, Agile Delivery does not include deployment. In some places, that belongs now not to Agile (apparently) but to some newer, younger, cooler thing called “Dev Ops” — and thus Agile Delivery has in these places been redefined to this:
Or God Help us, this:
Faster Problem Solving on the other hand is measured from two different end points. Two points that are not even on the above diagrams — because they sit directly before and somewhat after Define and Deploy in our above
Waterfall Hybrid Agile examples. Something you might hear referred to in Lean Circles as Concept to Cash.
To navigate down this little stream will require a degree of iteration. The linear left to right arrow is, I apologise somewhat misleading, and merely represents the passage of time, and not linear, even progress.
But problem identification and value realisation are not typically seen as IT issues, that is the domain of The Business! If you define the project like that, then we’d end up with Business People and Developers working together daily, and what would that lead to!
A prominent head of contract negotiation at a major bank once declared it to me as total madness. And pointed out that collaborating with the
enemy IT Department is considered in many organisations to be treason. Punishable by lack of career progression.
Solving problems creates value. There is nothing more valuable to a person, or an organisation, than solving a problem for them.
Everybody likes to talk a big game about “value” and as a result the term has become a little abused and ill defined. I’ve seen BA’s argue until they’re blue in the face that the requirements document that they just spent two years writing is VALUE. (Even thou 30% of the original users have now retired). Perhaps this is a legacy of the term “Value Add” (as in Value Added Reseller or VAR) — a world where simply doing extra things, was regarded as “increasing value”.
But my guess is that the problem with the term “value” is that it people take it personally. Deep down most people want their work to have value, so that they themselves feel valuable. If you’re a BA in the 21st century workplace, maybe you feel that you have to “declare value” at the point of writing your requirements, because the chances of you seeing them make it into production are terrifyingly slim.
Which is why, for reasons of clarity and equanimity, I’m talking about Problem Solving. But if you’re a traditionalist, you can think of it as Value Creation if you like.
Either way, it’s a far bigger deal than just quicker delivery.
Makes us stronger
To me, the Working Software alluded to in the Manifesto has never meant software that merely compiles and runs. Software that can stay up for the 5 minutes required to “demo” it.
Frankly I’m not sure why anybody see it that way, but they do. I guess it’s easy. (See Harder)
To me, Software is only Working when it’s solving the problem that we originally hoped it would, or other problems that we didn’t even know we had, but are glad to have removed from our lives.
Software that is working for us.
Software like that does not live in isolation, but is part of a bigger thing. Part of a solution that makes us all individually stronger, capable now of achieving things we could never have done before without it
Now you might end up with a result like that if you just focus on faster delivery.
But is that a risk you really want to take?