when relevant content is
added and updated.
If you’ve been in software more than a few years, you have probably heard the announcement “from now on, all programming will be in (new_language)”, yet never heard any plans for the conversion. The idea is so naive (do we rewrite all our existing applications?) yet too common.
Process changes are worse. I once had a manager declare that we would start doing ambiguity reviews for documents. From what I can tell, no one actually did the review. Ever. Not even the manager championing in the change as an example.
When I heard that GeePaw Hill was going to do a keynote on change for Agile&Beyond this week, I was encouraged.
GeePaw writes code. As a programmer’s programmer, he has managed to stay relevant in a 40+ year career. He blew me away.
Here are a few of his ideas.
See Judgements Not Numbers
This one runs counter to so much of what we do. In software, we want to prove we are providing value, so we talk about the number of story points we got done this sprint, or the number of projects done on time and on budget this quarter. GeePaw turned that idea on it’s head, asking the audience “How many times have you gone to a doctor, he said tell me what’s going on, and you answered ‘three.’ Nobody does that. Nobody does that ever. Instead, you say ‘My big toe really hurts’, you give details. You do not abstract into a number.”
When the company says it has a delivery problem, and you say you’ve gone from 42 story points per sprint to 53, that doesn’t really help them figure out what is going on, does it?
Hill said that the most common question he is asked is “How Do We Get Them To Change?” Instead of trying to get other people to change to our way of work, he tries to get them to do what they want to do.
The brings up the question – aren’t people already doing what they want to do? Hill answered that no, they generally aren’t. His trick as a consultant is not giving people the answer, but instead, taking the answer from them.
In some ways this is an old consultant’s trick. If Management is sufficiently disconnected from the workers, you can simply ask the workers how to fix the place, run it through a filter of self-interest, and present that to management. Hill meant something more refined. Figure out what people want, then pull from you list of tricks and tips to find how doing this will get them that.
As an example, Hill told the story of a simple one-line code that he wrote test-first. The single unit test he wrote passed, but it caused fifty other failures in a different part of the suite. He and his partner moved the code into a different module, and everything ran green, preventing a serious bug from getting out in the wild. By experiencing the value, GeePaw won a TDD fan — where speeches and drawing on a whiteboard would have failed.
Easiest nearest owie first
This is as easy as trying to get a good thing to happen to the person you are trying to influence, with a modest amount of effort, on the first try. To do that, start with the patient. Ask them their Owie’s, and try to address them.
Getting there takes a wide and deep tool belt. It takes real analysis skills, and even a little bit of people skills.
Which leads me to GeePaw’s definition of coaching:
“I create opportunities for people to take tiny steps to get closer to who or how they wish they were.”
That is beautiful.
How can you apply those words to help someone else change?