I’m one of six technical coaches engaged by a large bank to support an initiative to improve software delivery performance. The IT department is an established agile software development shop that uses the SAFe framework with Scrum at the team level. They are seeking to achieve continuous delivery, improve software quality, establish a developer-friendly working environment, and foster a culture of continual improvement.
We want to be able to show the effects of changes the teams make in their working practices. Improving delivery performance involves changing the way people work; therefore, we need measurements that aren’t dependent on doing the work in any particular way. Three metrics from the Lean school of thought are helpful: Throughput, Cycle Time, and Process Cycle Efficiency (PCE).
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.
Premise: Agile principles depend on biologically hard-wired limits on the effective size of collaborative human groups. For this reason, agile methods as such do not scale to “enterprise” levels.
Recently I noticed a post on Twitter that referred to this article by Eric Barker. Barker, in turn, shares information he learned in a conversation with Po Bronson, an author (with Ashley Merryman) of Top Dog: The Science of Winning and Losing. Now, notwithstanding the word “science” in the title, this is a “pop science” book, not a science book. It’s based in part on the authors’ “research” (reading statistical studies and so forth) and in part on popular assumptions – what we might call “leprechauns” or “urban legends.”.
The article rubbed me the wrong way, so I’m going to indulge myself with a bit of a rant.
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. Read more…