2018-07-14

Moscow – not about POTUS #45, for a change…


Tom Breur
14 July 2018

Moscow is an acronym from early agile-related practitioners. I heard it being used myself in the late 90’s, in the context of DSDM, originally developed by Dai Clegg. MoSCoW stands for Must, Should, Could and Won’t. It signifies the outcome from prioritizing user stories or features within a development cycle (a “Sprint” in Scrum parlance). Use of this acronym predates February 2001 (when he Agile manifesto was conceived) by at least five years, to my knowledge (presumably 1994). And although Scrum saw the light in the latter half of the nineties, it wasn’t nearly as dominant and well known at the time, as it is today.

When I read Frederick Brooks’ “Mythical man month”, which was published at a point in time when written specification were still the norm, and well before Rapid Application Development (RAD) (James Martin) & Spiral (Barry Boehm) came to the fore, I was struck by the number of comments that hinted at his “understanding” of agile. Brooks’ fundamental premise is that even if you engage with nine women, they still cannot conceive of a baby in one month. I recently came across this funny Tweet, along the same lines:
When you work in agile mode and try to avoid BDUF, many things change. Work assignment and prioritization has to change. Time can not be compressed or expanded, so you need to scale to capacity. That is where MoSCoW can help to guide the dialogue between the on-site customer (Product Owner in Scrum) and developers. You need some slack in the schedule to creatively ‘solve’ those features that are easiest or cheapest to make. You want to deliver value early and often. Dialogue is the most powerful tool to surface priorities from the PO’s side. Slack is necessary wiggle room to enable teams to ‘own’ the schedule and drive self-organization. Together, they might just create some magic…

2018-05-20

When do you cut your losses?


Tom Breur
20 May 2018


Business and IT never looked like a marriage made in heaven to me. Whether that is because DBA’s and MBA’s don’t mingle, I don’t know. To me it sometimes looks like trying to dissolve gasoline in water. Not easy. For years I’ve been hearing talk about “running IT like a business”, an idea that originated with Gartner, I believe. But I rarely see it happening!

Here’s an observation: what happens to IT projects that “don’t deliver”? Admittedly, due to the oftentimes ambiguous nature of IT deliverables, the notion of “success” is subject to interpretation. But here’s the rub: when the going gets tough, divergent perspectives on what constitutes success are bound to drive stakeholders apart.

Sometimes struggling projects are abandoned and turn into zombies. If you ever find yourself on one of those projects with insufficient resources to succeed, but just enough to continue in “maintenance mode” – run for the hills! Or as one of my friends once joked: “Oh wait! I am just reminded I urgently need to go floss my cat at home”

The reason why I am skeptical about the premise of “running IT like a business” is because of investment and management considerations. In IT I see projects sometimes being descoped to the point of not (no longer) delivering any real value. No business manager would eve dream of doing that to their operation.

The most significant telltale to me, however, is that failing IT projects are driven into the ground. Not a pretty sight. Show me an IT project that gets canceled halfway into the timeline (like a business might get “restructured”), before using their entire budget, and I’ll have another think.


2018-01-21

Kill the Zombies!

Tom Breur
21 January 2018

Zombies are horror figures that are neither dead nor alive. “Zombie projects” are those that are not valuable enough to merit assigning sufficient resources to, but then are placed in a kind of “maintenance mode.” This typically means people have grown attached to investments already made, but are not willing to assign resources to it because they are needed elsewhere. The reason for that is telling: some other effort is deemed more valuable or pressing.

Zombie projects are a horrible drain on valuable resources, as this HBR article explains. In many cases they are actually largely hidden, or invisible, since they aren’t supposed to usurp any resources, or at least as few as possible. So “nobody” is working on them! In a perverse way, zombie projects fascinate me from a corporate planning perspective, when I think about cycle time, WIP and Kanban principles.

An enterprise is a set of value creating processes, or in Kanban this would be referred to as "a set of interconnected [value creating] services." Over time, as business opportunities wax and wane, the “holding costs” for WIP fluctuate. The economic reason for that is because the “optimal” WIP is a function of the value of output – which goes up and down as business circumstances change. This gives rise to emerging and disappearing bottlenecks. When resources are urgently needed somewhere because the economic value of reducing cycle time for one of the value creating processes has gone up (a business opportunity or threat), they need to be pulled from elsewhere. That is where projects are “put on hold”… I have often experienced there are few things as permanent as a temporary quick fix – that is where zombies are created.

For all businesses except maybe manufacturing processes of tangible goods, bottlenecks are always in flux. This may explain why the Theory of Constraints (ToC) appears to have gotten such a strong hold in manufacturing, but not so much outside of it. In software development, for instance, bottlenecks are rarely as fixed and stable as they are in manufacturing. They come and go, pop up and vanish. Cross training enables swarming to dissolve any bottlenecks as they arise. Assuming you are working in iterations rather than a flow based process, within any given iteration, the beginning will be dominated by business analysis tasks. Towards the end, most people in the team will be devoted to testing the iteration feature.

As Don Reinertsen pointed out in his (fabulous!) book “The Principles of Product Development Flow” (2009), when you picture an organization as a set of interlocking processes, there are many ways (pp. 150-157) you can cope with emerging queues (=accumulation of WIP). But whichever way you turn it, when you squelch resources form a less economically valuable process (a lower priority), it still maintains it’s original WIP, contributing to overall holding costs. You can either cancel the effort (with the option of later starting anew), or it will consume resources that economy has shown are a suboptimal use of resources! Shedding earlier efforts is always difficult, although all managers are familiar with the concept of sunk costs. The problem is rarely financial, almost always “political”: someone losing face, difficult conversations with reallocated staff, etc.

An organization that seeks to maximize shareholder value has little choice but to allocate resources where the payoff is highest. If output value has changed, you work to reduce WIP and drive down cycle time (see e.g. Little’s Law, explained for data warehousing here) for the most valuable products in your portfolio. When business opportunities change, you continue to do so, forever maximizing (economic) throughput by shifting resources.

When the value of a workstream has dropped below economic par, it’s a horrible half measure to transition that project to maintenance mode. It’s a disservice to shareholders, and an outright insult to people you assign to that work. Weak, ineffective leadership. Companies exist for business reasons, and senior leadership needs to take responsibility for “following value.” As Willy Sutton famously said in response to the question: “Willy, why do you keep robbing banks?!?” “Because that’s where the money is!” Likewise, senior leaders sometimes “have” to take painful measures, like cutting losses (“Killing Zombies”), to be effective.  

If you ever happen to get assigned to a “zombie project”: run for the door! Or as a friend of mine used to joke: “Oh! I just remembered I need to go home to floss the cat.” J