The bad news for a smart-alecky blogger is that it’s getting harder to find examples of companies that handle their IT function foolishly. But that’s good news for the IT industry!
At one of those massively-wasteful, multi-day SAFe Inspect and Adapt events, held at an offsite conference center, a couple hundred people were jammed closely together in a line for the lunch buffet. There was plenty of food, but the procedure to get it was very cumbersome and lengthy.
A senior IT manager at my client happened to be quite near me in line. He remarked, “This is crazy!”
I replied, “If they ran this place like an IT shop, they would solve this problem by hiring more cooks.”
“But…but that isn’t the problem,” he said quizzically.
“Exactly!” I said.
He didn’t laugh, but others did.
As a middle manager in a large corporate IT department, you feel as if
- you are in the middle of an accordion
- and the accordion is being played by a monkey
- and the monkey has taken some sort of unknown street drug
- and the strange music the monkey is playing makes no sense to you
- and your bosses think the monkey is a genius
- and your subordinates think it’s all your fault
- and you don’t see how it could possibly be your fault
- and you’re not even sure what “it” is.
You never know whether your job will survive the next re-org. Furthermore, you’re not even sure that your job adds much value to the organization: In a nutshell, you (a) take direction from above and disseminate it downward, and (b) collect data from below, compile it and report it upward. You don’t know how to run the business from the top. You don’t know how to do the hands-on work at the bottom. You have only a vague idea of what’s going on. You can’t trust any of your peers. What will happen to you if your present position is eliminated?
My book on software development metrics is in the final stages of editing. The editor made a kind comment about one section of the book. She wrote: “This section is marvelous. I wish all management everywhere would read this and pay attention.” Me, too. This is the section:
This may be the mother of all management anti-patterns. Management science has treated human beings as interchangeable machine parts at least since the time of Frederick Taylor’s “scientific management” in the early 20th century, and possibly much longer than that. Even today, many managers loosely refer to workers as “resources” without realizing the implications of the word.
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.
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
It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.
Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading
The fact this question continues to come up time and again after all these years prompted me to wonder why the matter hasn’t been settled by now. Thousands of people have tried their hand at pairing in a wide range of circumstances. Some swear by the practice and feel as if something is missing when they must work solo. Others are convinced pairing is pure waste and cannot possibly yield good results. Both opinions are informed by real-world experience. What specific differences in these situations resulted in such radically different outcomes?
Alert: 82% chance of pontification.
First, here’s the short version for those poor souls suffering from tl;dr (too lazy, don’t read much) syndrome, that peculiar malaise that characterizes our times:
Can working from home be effective
compared with collocated teams?
Opponents are quick with invective
and full of opinions, it seems.
But what if we increased, in some way,
the ratio of signal to noise?
Could we discover a good way to
routinely deliver with poise?
And now to business.
One of the ongoing debates in the IT world over the past few years has been about the relative merits of team collocation, including intense collaboration, paired work, and continuous osmotic communication, versus solo work, including work from home and other forms of remote work as well as office spaces fitted with individual cubicles. Continue reading