Posted on

Choosing an Agile Scaling Framework

Many larger organizations are considering adopting an Agile scaling framework to help them extend contemporary practices beyond the proof-of-concept stage. Plenty of people stand ready to help them choose an appropriate framework. Or maybe it’s more accurate to say, to help them choose the framework the helper wants them to choose.

I put together a short ebook that addresses the problem of choosing a framework from the point of view of someone who has no product to sell and doesn’t care whether you use a framework at all. Maybe it will help you and maybe it won’t, but either way it’s cheap, and it doesn’t try to sell you anything. See https://leanpub.com/choosing-an-agile-scaling-framework.

Posted on

The Agile Katamari: Sticking things together and pulling things apart

Different people have different ideas about the current status of the “agile” movement in software development. Different people have different ideas about what “agile” even means. Having been involved with “agile” development since 2002, I’ve had the opportunity to observe an interesting trend: We’ve been gluing a lot of things onto “agile.” Now it may be time to pry some of those things off and get back to basics.

Continue reading The Agile Katamari: Sticking things together and pulling things apart

Posted on 5 Comments

Every agile scaling framework in the world

More and more frameworks for scaling “agile” software delivery have been appearing in recent years. The proponents of each are adamant that their framework is superior to the others. Yet, customers have difficulty understanding the differences.

This is because all such frameworks are based on the same general ideas, broadly speaking. Proponents insist there are deep differences because they are all competing for the same customers.

Here is a generalized version of conversations that might occur between a salesperson and a prospect looking for help with scaling “agile” delivery.
Continue reading Every agile scaling framework in the world

Posted on 2 Comments

Komm süße Todesmarsch

People who’ve been in the IT field for some years tell tales of the bad old days when every project ended in a Death March. Well, actually, no one died. Truth be told, no one marched, either. But we called it a Death March. Some call it the Death March Antipattern. It was, in fact, one of the reasons people became interested in exploring alternative approaches to software development.

Younger professionals have managed to avoid the Death March Antipattern, for the most part. When oldtimers tell their tales, many of the younger folk react as if they were hearing Monty Python’s Four Yorkshiremen sketch, in which four retired gentlement reminisce about the difficulties of their youth: “There were a hundred and sixty of us living in a small shoebox in the middle of the road.” “You were lucky. We lived for three months in a brown paper bag in a septic tank.” “But you try and tell the young people today that…and they won’t believe ya’.” “Nope, nope.”

But it was real. On a typical 12-month software development project, the first ten months would be spent preparing useless documents and snoring through useless meetings. With the deadline looming, the team would scramble to get as much of the work done as possible in the remaining few weeks. It meant working 24×7 until you delivered, and then crashing for a few days. That was the Death March. And it had much in common with modern-day “agile” development practices.
Continue reading Komm süße Todesmarsch

Posted on 1 Comment

A modest proposal for restructuring enterprise IT

Submitted for your consideration: The simplest way to solve a problem is not to solve it at all, but to define it out of existence. Many of the challenges we face in corporate IT may be caused by traditional organizational structure. If it is true that structure begets function, then we may be able to define some of these challenges out of existence by changing the organizational structure.

Continue reading A modest proposal for restructuring enterprise IT

Posted on 4 Comments

Where are all the Agile success stories?

Daniel Mezick confronts the elephant in the “agile” room in his post, Deviation from the Norm: “If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, “freestanding” agility. Clearly, that is not the case.”

Pondering the question, several possible reasons for this result (or lack of) occurred to me. These are speculative and based on my own experience and observations.

Continue reading Where are all the Agile success stories?

Posted on

Relief valve for Product Owners

In a pressurized system that contains a liquid or gas, when the pressure is too high the system can rupture at its weakest point, causing a halt to operations, damage to the system and, possibly, leakage of dangerous materials into the environment. To protect against this, people install relief valves. The valves guard against excessive pressure and wrong-way flow. One type of relief valve vents into the atmosphere. It is used in applications that do not have hazardous liquids or gases. Another type can direct dangerous fluids to an alternate route, possibly collecting them in a reservoir of some sort, while protecting the system from damage.

In large organizations that use an "agile" process with a formal role similar to the Product Owner (PO) role defined in Scrum, a common problem is that the individuals assigned as POs are asked to work on more projects concurrently than they can handle with due diligence. Often, they are simply asked to add PO responsibilities to their existing workload. Thanks to the historical preoccupation with maximizing individual resource utilization in management "science," the PO’s existing workload usually does not provide any slack. In short, they are already too busy to begin with. Continue reading Relief valve for Product Owners