All Posts in Metrics

|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

|In: Metrics|Last Updated:

Business cycles are speeding up, yet businesses seem to be slowing down.

So here’s something to ponder: For decades, businesses have focused on their processes, using techniques like Lean, Six Sigma, and Theory of Constraints to reduce process cycle time while improving quality and reducing incremental costs.

Making products flow off an assembly line is nice. But assembly-line-like processes aren’t what slow a business down. It’s the inability to make fast, accurate decisions and act on them that gives so many businesses the appearance of a swimmer immersed in molasses.

Last week’s KJR discussed some of the particulars, with suggestions for speeding up decision-making by reducing committee-induced decision sclerosis.

But committees aren’t the only source of business slowdown. As a CFO of my acquaintance phrased the cure for another one, “Pick up the damned phone!”

Back in the days of Mad Men the cycle time for interoffice memos was measured in days. It started with hand-written or dictated text, handed to a secretary or sorted and transported by the mailroom staff on a (typically) twice-a-day schedule to the typing pool.

After a couple of edits, transports, and re-typings, the memo made its way to its intended recipient or recipients. The process took, in total, several days from initial dictation to final delivery.

Email replaced this with a process that took, in total, several minutes at most, while reducing the need for administrative assistants and typists at the same time.

Strangely, the committees that made decisions about such things back then didn’t jump on the new technology, yelling to IT, “How fast can we have this — the checkbook is open!” Go figure.

Anyway, everyone knows clogged email inboxes are a problem. But the ramifications of this indicator of email’s success go far beyond reductions of personal effectiveness.

Email has slowly slid from business accelerator to decision-bottleneck.

The cycle time for any process includes intrinsic cycle time, also known as touch time, and queue time. For email, touch time is how long opening a received email, reading it, clicking or tapping on the Reply button, typing your own message, and clicking or tapping on Send takes. Queue time is how long an email sits in your inbox before you open it.

When email was first introduced it shortened both of these compared to interoffice mail. Queue time has been lengthening ever since. Email has become a victim of its own success.

Compounding the felony is this: The distribution of interoffice memos was subject to the limitations of carbon paper, or the time and expense needed to make copies, added to which was the time and effort needed to fold the paper, insert it into interoffice mail envelopes, and address the envelopes.

With email there’s little burden associated with making sure it’s sent to everyone who ought to know about its contents. This isn’t something to stop, either. Sharing information with everyone who ought to know about it is a virtue, not a bad habit.

But, all these cc’s do add more clog to already overstuffed inboxes. For some folks, the time needed just to decide which ones to actually read and do something about has extended from a glance, to minutes, to, over the course of a busy day, as long as maybe an hour.

Or else, the messages that have scrolled down far enough are ignored entirely until the sender becomes frustrated enough to either re-send the original message or to pick up the damned telephone.

But I oversimplified, because if this was the total impact of queue time, it would be a livable problem.

Here’s why it counts as a major source of business decision slowdown: Queue time has to be totaled over all the messages in an email thread. In total, cumulative queue time can result in multi-day delays when reaching even simple decisions.

What’s to be done?

Picking up the damned telephone is hardly a cure-all: You’re more likely to reach voicemail than your target, and voicemails take longer to process than emails.

What telephone conversations will do is eliminate most of an email thread’s queue time: Instead of hitting the Reply button you converse.

Use your calendar system to schedule the call and attach whatever background material is essential, so you don’t just replace exchanging voicemails for exchanging emails.

One more thing: The organization as a whole has to find an alternative to cc-ing everyone who ought to know about something. This is far from easy. As a stopgap, consider installing Outlook with a default rule that yanks every email for which the recipient is on the cc-list and stashes it in a separate “cc for review” folder.

It ain’t pretty. But sometimes, less ugly will just have to do.

Comments