Posted on

It’s time to re-group and prepare for the upturn

In December 2008, I attended a talk by Niel Nickolaisen about his Purpose Alignment Model, or PAM. I found it compelling and useful, and I’ve applied it with many clients since then.

I might describe it crudely as a typical consultant-style “quadrant diagram” showing mission criticality or alignment with business purpose on the X axis, and market differentiation on the Y axis. There’s a walkthrough of a hypothetical bank business in my book, Technical Coaching for IT Organizational Transformation, and similar descriptions on Todd Little’s blog, on Cory Foy’s blog, on KBP Media’s site, and many other sources you can find easily online. Some people call it the Purpose-Based Alignment Model, instead of Purpose Alignment Model; bear in mind those names refer to the same model, which was originally called the Purpose Alignment Model or the Silly Little Model, after co-creator Todd Little.

One of the ways the model can be used is to think about how to position or re-position a company during economic downturns. Companies that use downturns to prepare for the next upturn are positioned to hit the ground running when the economy ramps back up again, as it always does. Companies that react to downturns in fear, by cancelling initiatives and halting capital spending, tend to lag behind the competition when the economy emerges from the tunnel. Their behavior during downturns is a telltale that they can only prosper by following those with better leadership, feeding on the excess the successful companies produce during the good times.

In the talk, Niel had just finished saying more-or-less the same thing when a participant in the session asked him what his company was doing just then. (You may remember Q4 2008 was the start of the “financial crisis” of the early 2000s.) He replied that they were cancelling all initiatives and halting capital spending. They intended to wait and see what other companies did, as a signal to know when it would become safe to operate normally again. I was surprised at the answer.

In the year 2020, we’re in another economic downturn. Most companies are handling the situation by cancelling all initiatives and halting capital spending.

Now is the time to prepare to hit the ground running when the economy emerges from this tunnel. The companies that will succeed when the economy rebounds are already investing in building the capabilities and skills of their staff (through training and mentoring), and preparing their work environments for the post-pandemic world – physical office setups that minimize the risk of infection (changing open-plan work spaces, reducing the use of conference rooms), adjustments to work schedules to avoid forcing people to crowd together unnecessarily (such as waiting 30 minutes at a bank of elevators to go to their floor in the building, because employees must all arrive at the same time), changing some common operating procedures (such as requiring employees to crowd together to listen to executive announcements or “town hall” meetings, when they could listen just as well over the computer network), and intentional support for remote or distributed work.

Consider investing in training for your staff. Take advantage of the free training offers that have proliferated, as training companies struggle to remain visible in this slow market. But don’t expect training to remain “free” forever. There is value in good training, and value doesn’t fall from the sky like rain…at least, not usually. Even in these times, the highest-quality and most practical training for technical staff isn’t offered free of charge, with good reason. You get what you pay for.

Posted on

Does your organization need an agile scaling framework?

In collecting information for the ebook, Choosing an Agile Scaling Framework: A handbook for decision-makers, I was surprised to notice that the Kanban Method kept bubbling up to the top of the list of choices in nearly every scenario. For every business need except one, it was the best or one of the best choices. (The exception is the case when the organization only intends to pretend to change. For that purpose, less-expensive alternatives are available.)

Why would that be true? I wondered.

Continue reading Does your organization need an agile scaling framework?

Posted on

An opportunistic coaching moment

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.

Posted on

The accordion game

As a middle manager in a large corporate IT department, you feel as if

  1. you are in the middle of an accordion
  2. and the accordion is being played by a monkey
  3. and the monkey has taken some sort of unknown street drug
  4. and the strange music the monkey is playing makes no sense to you
  5. and your bosses think the monkey is a genius
  6. and your subordinates think it’s all your fault
  7. and you don’t see how it could possibly be your fault
  8. 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?
Continue reading The accordion game

Posted on 8 Comments

The mother of all management anti-patterns

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:

(begin excerpt)

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.
Continue reading The mother of all management anti-patterns

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

Posted on 1 Comment

Don’t do anything stupid on purpose

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 Don’t do anything stupid on purpose

Posted on 7 Comments

Does pair programming work?

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?

Continue reading Does pair programming work?