- Agile: It’s only a model
- Keep trying until you find a way that works
- We tried agile, and it didn’t work
- Scrum: The Three Questions
- Self-organizing teams
- The coach knows all
- We’re not ready to try [insert practice here]
- Alignment and communication of requirements
- The value of comprehensive documentation
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.
Take a walk in the desert
No one can see their reflection in running water.
It is only in still water that we can see. (Lao Tzu)
A friend of mine was telling me about the new apartment he and his family have bought. The building is under construction, and is located in a prestigious part of a major city. We got into a discussion about choosing where to live. He prefers large cities, and I prefer living far from a city (although I work in cities).
Continue reading Take a walk in the desert
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?
Continue reading Should coaching be treated as hourly contract labor?
It’s getting harder to find bad examples
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!
Billy Pilgrim and the software estimation debate
Warnings:
- tl;dr
- sarcasm
- calories from fat: (don’t ask)
I’d like to begin with an insightful quote. Until I find one, here’s a quote from Vonnegut:
“I am a Tralfamadorian, seeing all time as you might see a stretch of the Rocky Mountains. All time is all time. It does not change. It does not lend itself to warnings or explanations. It simply is.”
— Billy Pilgrim in Slaughterhouse Five, Chapter 4 (Kurt Vonnegut)
The online debate about software estimation may well be the greatest waste of pixels since the invention of porn. Like porn, the debate comprises a never-ending repetition of the same scene over and over again, the very definition of “boring.” And the actors conclude each day in the same state they were in when they awoke. Every day the same, every day exhausting, every day pointless.
The argument, like Kenny of Southpark, refuses to die. It wakes up each morning as if nothing has happened. In a sense, I guess, nothing has.
Anyway, here’s the thing: Despite people’s best efforts and their protestations to the contrary, no one can predict the future accurately and precisely.
Continue reading Billy Pilgrim and the software estimation debate
The what, the how, professionalism, and pragmatism
Warning: Rant
Warning: tl;dr
So, there’s this idea floating around of technical debt. There are some nuanced definitions, but in general it means bad design baked into the code. The “nuance” has to do with why bad design is baked into the code. There are a lot of debates about this, and you might wonder why, as it isn’t intuitively obvious how anyone could argue in favor of baking bad design into their code.
Yet, they do.
Continue reading The what, the how, professionalism, and pragmatism
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
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.