Some time ago I wrote about the use of metaphors in the field of software development (Metaphorically Speaking), and more recently on the risks of using colloquial English with international colleagues who learned business English (English for English Speakers). I’d like to revisit the subject, as I still see a lot of confusion out in the world, and we’re still coining new terms that strike people differently than intended.Continue reading The Problem with Metaphor
In Howard Myers’ 1972 short story, “Out, Wit!” physicist Jonathan Willis discovers the secret of alchemy, and publishes a paper describing how to make gold. Unfortunately for him, he writes the paper in an ironic style that leads people not to take it seriously. Making things worse, his work contradicts the prevailing wisdom in the scientific community, and senior researchers shut him down.
No one takes Willis’ paper seriously…except the Russians. They understand English well enough to comprehend the content of the paper, but not well enough to understand the humor in it. They return to the USSR, where they apply the techniques described in the paper to produce large quantities of gold, which they use to collapse the capitalistic economies of their enemies.
The common language of work
In the global economy of the 21st century, English has become the de facto common language for international scientific and academic exchange, business, and technical work. It’s the official corporate language in many international companies. It’s the practical working language for software teams that include members from different countries.
The situation sounds like an automatic “win” for native English speakers. We already know the global language of business. We don’t have to overcome that barrier to be effective in international work – conferences, user group meetings, training classes, working in multinational companies – all doors are open for us.
This is a brief follow-up to the post, The power of words, on this blog.
Recently I posted a question on Faceboook and Twitter about the origin of the phrase “hold teams accountable.” The phrase is used frequently in “agile” circles. The only answer anyone suggested was that it probably pre-dates the agile movement, as managers have been thinking in terms of holding people in one sort of grip or another for a long time.
But that single answer was not the only response to the question (uh-oh; another pair of words, there).
Seeds of change
This one is for all the change agents out there who, from time to time, may have felt as if their work has no meaning or value.
Here’s what we do:
- We win an engagement with a client whose management want to institute organizational change (e.g., to implement Lean and/or Agile methods and practices, or to shift the organizational culture and management style toward a 21st-century model, or some other lofty goal).
- We define “success” as “the organization has deeply, honestly, and permanently changed for the better.”
- We help the people in the organization visualize a different future and guide them on a path toward that vision.
- We encourage people as the organization makes halting, slow progress.
- We encourage people as the organization succumbs to systemic forces and reverts to the status quo ante.
- We watch sadly as the people who had learned the most in the transformation initiative leave the organization.
- We hang our heads in shame; the definition of “success” has not been achieved.
- We use tales of the engagement to convince others to try the same thing, as we go forward in our careers. “It got off to a good start. If only…”
- We return to step 1.
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.
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.
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.
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?
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.
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.