Where Agile goes to die

There’s something I started to notice around 2011, but didn’t quite understand until recently. Now I think I have a handle on it.

From time to time I hear agile coaches describe a particular client company as a place where agile thinking never penetrates, or where agile methods are never properly adopted. It seems as if most of the larger markets have at least one such company or governmental organization.

One (that I know of) is known in its local market as “the place where agile goes to die.” Coaches in other markets have been less poetical in their descriptions, but many of them are aware of at least one client company that has a similar local reputation.

My individual coaching assessment guide

As an agile/lean coach and “change agent,” I often find myself working with dozens of individuals at the same time at any given client. I’m not a great fan of “assessments,” but I do need some practical way to keep track of where everyone stands and how they tend to think and collaborate. To do that, I consider the following factors.

Beyond resistance

Do people resist change? The consensus appears to be that they do.

• Changing Minds (many articles)
• Prosci (models, tools, training)
• Harvard Business Review, “How to deal with resistance to change”
• Forbes, “Overcome the 5 main reasons people resist change”
• Human Resources at about.com, “How to reduce resistance to change”
• Small Business Chron, “How to overcome resistance to change in an organization”
• Computer Weekly, “How do I overcome resistance to change?”
• Paycor, “Change management in the workplace: Why do employees resist it?”
• “Overcoming resistance to change – isn’t it obvious?” (Video, script by Eliayu Goldratt and Ilan Eshkoli)

Well, with all that consensus floating around, I guess resistance to change must be a Thing. It’s hard to argue with a million articles that all say the same things.

On the other hand…not everyone sees it that way.

Should coaching be treated as hourly contract labor?

Often, companies try to balance staffing with the natural variability in IT workload by engaging contract workers. They don’t want to make a long-term employment commitment to the number of people required to handle their maximum workload. So, they hire enough full-time employees to handle their typical workload, and in periods when the workload is higher they bring in temporary workers on a contract basis. That way, companies can expand and contract staff to match the internal demand for IT services.

Problems occur when the parameters of the temporary staffing engagement are at odds with the nature of the work performed. Because “coaching” has not been a well-understood category of services, it has more-or-less accidentally fallen into the “hourly contract” mode. Is this appropriate? Does this model cause difficulties for any of the three constituencies that have an interest in it: The clients, the workers, and the middlemen?

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.

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.

What skills does a technical coach need to have?

What skills does a technical coach need?

One of the goals of my present coaching engagement is sustainability, defined as the ability to continue with the improvements after the coaches are gone. To that end, we’ve been identifying internal people who have the potential to become effective technical coaches. One manager asked us for a short list of key skills that a technical coach ought to have. Answering that question has been quite a challenge. It occurs to me that other people may be asking the same question, so it might be useful to discuss it publicly.

Organismic Integration Theory

Recently, I came across a model I had not known before: Organismic Integration Theory (OIT). I read about it on Sal Freudenberg’s blog, which is much easier to digest than scholarly articles on the subject.

I know how to tie my shoes

Recently there have been numerous discussions online about the difficulty of convincing people to try unfamiliar software development techniques that technical coaches and mentors consider useful. The same discussions have been taking place for many years, with no progress. Why is there no answer?

How to avoid the local optimization problem when coaching at the team level

A recent Twitter discussion inspired me to re-think a few things about how to effect meaningful change at the organizational level and the team level. (Funny how Twitter seems to serve that sort of purpose, which may be above and beyond the usage pattern its creators envisioned initially. But I digress.)

During the first few years I worked in the general area of process improvement, I functioned mainly as an “agile” coach at the team level. Through those experiences I tried to understand how each method or practice worked mechanically as well as applying the “agile” values and principles on the cultural dimension, and started to learn how psychology and organizational sociology play into software development practices and delivery methods.

It didn’t take long for me to realize that the way an individual development team goes about its work actually has relatively little impact on the effectiveness of the end-to-end delivery process. I continued to look for the key leverage points in organizations that might yield the greatest positive effect for process improvement. I often found myself venturing far afield from the teams I had been engaged to coach, because time and time again I discovered that the real problems with delivery lay well outside the team’s jurisdiction.