All Posts in App Dev Methodologies

|In: App Dev Methodologies|Last Updated:

Does Agile speed things up?

As we discussed last week, when it comes to IT App Dev, just defining what “speed things up” means is a non-trivial task.

And then there’s the definition of “agile,” which isn’t about speed in the first place. If we use automobiles as a metaphor, agility has more to do with a car’s suspension, steering and brakes than with the drive train.

If the question is whether Agile makes IT more agile, the answer is an unequivocal “Yes,” because with Agile, requested changes go into the backlog with no muss and no fuss, where with waterfall they’re submitted to the project steering committee as part of standard project governance.

A process step that doesn’t involve a committee is always more agile than one that does. Q. E. D.

There’s another way to answer the question, which leads to an even more emphatic affirmative. As pointed out last week, according to the Standish Group’s annual Chaos Study, across application development projects of all sizes, Agile methodologies yield higher success rates and lower failure rates than the waterfall alternative.

How does this translate to speed?

For a change of pace, this one is easy. If by speed you mean throughput, failed projects have no throughput. They deliver zero requirements — aka user stories — per month. And if by speed you mean cycle time, for failed projects the cycle time for delivering a user story is infinitely, or at least indefinitely long.

It’s Q. E. D. all over again.

But (you knew “but” was the next word, didn’t you?) …

There’s no such thing as an IT project, so whether you measure throughput or cycle time, if the units being delivered are software features you’re measuring what amounts to the production of work in progress, not finished goods, the finished goods being the intended business changes.

And it isn’t true that if you speed up the creation of work in progress you automatically speed up the process as a whole. For example:

Imagine a team of process re-engineering consultants has marched through a business, completely redesigning one of its core processes. Almost certainly a process change of this magnitude will require radically different or completely new enabling software.

Now it gets complicated, because to make sure the new software will properly support a process that’s been completely defined from one end to the other, for all major branches and contingencies, there’s no alternative than to design the software from one end to the other and for all major branches as well.

This is what waterfall does. To get Agile to do the same thing a business has to adopt what’s becoming known as “scaled Agile,” which defines software in terms, not only of user stories that are small and self-contained, but also in terms of “epics” that are, as the name implies, large and expansive.

You start with the epics, decomposing them into release trains, and release trains into user stories. Voila! You’ve turned Agile into waterfall, except for the design of user interface details and perhaps some underlying algorithms.

Which leads to the question, when it comes to large-scale business change is scaled Agile a necessary evil or a self-inflicted wound whose root cause is a failed change in culture — the retention of waterfall mental habits that relegate Agile techniques to the trivial.

I think the answer is, neither of the above. The view from here is that the root cause was the decision to re-engineer a process in the first place. Once a business decides to design and implement a large-scale process change in one big bite, there’s little point trying to build the supporting software in small increments.

Instead, businesses need to adopt the mental habit of incrementalism — to make a continuous stream of small changes the centerpiece of its management culture.

Because as Lao Tse once said, a journey of a thousand miles starts with a single step. What he didn’t explain is what IT and its business counterparts need to understand the most: Those who undertake journeys of a thousand miles and fail are the ones that, after they take the first step, try to cover the rest of the distance with one giant leap.

Those who succeed don’t take journeys of a thousand miles in the first place.

They take journeys of 2,100,000 steps, which they cover by walking briskly.

Comments

|In: App Dev Methodologies|Last Updated:

As everyone knows, when compared to waterfall application development, Agile speeds things up, and DevOps speeds them up even more.

There’s just one little gap in what everyone knows: exactly what these things are that Agile speeds up.

When it comes to optimizing business processes and practices, speed has two very different and independent meanings — cycle time, which is the time that elapses between an average item entering the function as an input and the time it exits as an output, and throughput, which tallies how many completed items exit the function in a given unit of time.

For application development, I’m guessing most businesses care more about cycle time than throughput, but that’s just a guess. I’ve never seen any survey data to confirm it.

On the other hand, managers who want something from IT mostly ask and then gripe about is when they’ll get it. They care about cycle time and want it to be small.

So for the sake of argument, accept that the goal of supplanting waterfall development with Agile is to improve cycle time.

But as cycle time measures the time that elapses between something entering a function and exiting it, we’re back to the question of what are these things of which we speak?

Back in the days when waterfall held sway, the closest anyone came to nailing this down was the function point. Function points were (and are — the discipline still has adherents) supposed to correspond to business functionality, and so they do, in the sense of corresponding to software functionality business people use.

So we could ask the musical question, do Agile methodologies speed up the delivery of function points?

And we’d have our answer, which is the same as the answer to the question, “What’s the difference between ignorance and apathy?” which is, “I don’t know and I don’t care.”

That’s because Agile methodologies don’t deliver function points. They deliver user stories, each of which is assigned a degree-of-difficulty weighting factor, typically the aforementioned story points.

So on the subject of velocity we now find ourselves asking which delivers a user story more quickly — waterfall or Agile. But as waterfall deals in function points, not user stories, aren’t we still stuck with incomparables?

Well, yes, but not insurmountably, because a user story is, if you squint a bit and don’t worry overmuch about the details, pretty close to what in waterfall terms we’d call a requirement.

Al fin, nous arrivons! as a Parisian shopkeeper said to me many years ago as I was attempting, in my very limited French, to explain what I needed and he was attempting to make sense of my near gibberish.

At last, we’ve arrived: To compare the speed of waterfall and Agile, “all” we need to do is compare how much time elapses between the first articulation of an average requirement and its appearing in production some time later.

Interestingly enough, Agile doesn’t measure this. It measures throughput — story points delivered per week, or some similar metric. Why? Probably because throughput is what’s easy to measure never mind what matters most.

Superficially, cycle time doesn’t seem hard to measure. Except that with waterfall methodologies the early steps aren’t atomic: Business Analysts talk with a bunch of people (ConsultantSpeak: Stakeholders and subject matter experts), try to make sense of it all, and write up the result in a requirements document.

Average cycle time for this step: Total step duration (first interview through requirements publication and ratification) divided by the number of requirements described in the document, weighting each requirement by its degree of difficulty.

Agile equivalent: Time needed to rephrase someone’s requirement as a user story and add it to the backlog.

This isn’t an entirely fair comparison, though: Waterfall business analysts are expected to filter out low-value requirements. With Agile, they just sit in the backlog, never important enough to be worked on, either forever or until someone decides it’s time to clear all the dead items out of the backlog.

Which means with Agile, cycle time will have to be, shall we say, dynamically recalibrated from time to time to remove Worthless Items Never Worked On from the calculation.

Clearly, app dev cycle time measurement isn’t for the faint of heart. And we haven’t even begun to explore how to account for project failures.

Given the Standish Group’s current statistics — that Agile projects enjoy roughly three times the success rate of waterfall projects — accounting for this is an important piece of the puzzle.

Comments