Relationships Rule

  1. Posted on July 22, 2009 8:36:AM by Earl Beede to Practicing Earl
  2. Technique, humor, change, Management

Getting better in software development requires change and change is hard and change is unpleasant. Most of all, it doesn’t seem like we actually change. We talk about change, we start change initiatives, they pay people to teach us new ways, we may even read books, but at the end of the day we seem to be unchanged (except a bit poorer). Do we need to change the way they go about making changes?

I started addressing this question in my earlier post called Logic Loses. I described how facts, fear, and force, while giving the appearance of short-term change, did not seem to result in long-term desired behaviors. If that doesn't work, what does?

In Alan Deutschman book, Change or Die, he combats the approach of facts, fear, and force with his own three words (but his start with the letter R): relate, repeat, and reframe. Let's start with Deutschman’s short definitions for his R’s.

  • Relate: You form a new, emotional relationship with a person or community that inspires and sustains hope.
  • Repeat: The new relationship helps you learn, practice, and master the new habits and skills that you'll need.
  • Reframe: The new relationship helps you learn new ways of thinking about your situation and your life.

The best selling book on leading change is, of course, John P. Kotter’s Leading Change where he lists out his eight-stage process* to creating major change. The second step in Kotter's process is about creating a guiding coalition. This mirrors Deutschman’s first R: relate. Change seems to require that somebody outside ourselves has to believe that we are capable of making the change. That somebody, or some group, gives us a glimpse of what we can be and makes it impelling to us, not only because their facts or that they draw on our fears, but because our relationship to them is as compelling as the data.

Change, it seems, needs another human being whom we can connect with but who is not like us. The connection need not be affection only. Respect, awe, admiration, and the like seem to be equally fine kinds of connections. Fear as the sole basis for the connection seems to be insufficient for long-lasting change. (Though it is pretty darn good for short-term change!) The bigger and tighter the connection, the more you're likely to change and that change to last.

But it just can't be one of our mates who thinks just as we think. Just as in Kotter's third step, they need to have a vision of what we can be that we ourselves cannot quite believe yet. “You can automate those test cases.” “No, we don't have to constantly work massive overtime.” From small things to massive change, our connection to them and their belief in us gives us the hope, and therefore the energy, to make the change.

But that connection cannot be fleeting. Deutschman’s second R: repeat echoes Kotter's fifth and sixth steps. Practice makes change perfect (at least in the old-fashioned meaning of the word: complete) and this is the reason why most cold turkey, sheep-dip approaches fail. Doing the new thing once or twice is often not enough to create habits of mind that will make the change last. Change needs training and coaching.

In order for the repetition to be successful it also needs to be seen to be making progress. If I'm trying to find a better way to do requirements, I need to have some signs that I’m actually doing better lest I totally give up. The signs need not be massive, just little things like a better written requirement statement or a comment from a tester that my requirements are much easier to use. I need short-term wins.

Building habit through repetition and short-term wins drives me to Deutschman’s third R: reframe (Kotter’s seventh and eighth steps). Because I see myself doing it and doing it better, I stop relying on my connection’s vision and start developing my own. My old way of thinking, that there is not any better way to do requirements work, starts to give way to my realization that I am already doing a better way. Things I thought impossible before, or at least unlikely, now seem completely doable. Now statements like, “Requirements are about the problem space and design is about the solution space,” don't seem like nonsense but statements of deep truths.

Of course what ever new worldview we end up in will probably need changing in the future and will have to go through the 3Rs again. And we will try at first: facts, fear, and force. And we will scratch our heads wondering why we cannot change.

[* Kotter’s eights steps are: 1) Establish a sense of urgency; 2) Create the guiding coalition; 3) Develop a vision and strategy; 4)Communicate the change vision; 5) Empower broad-based action; 6) Generate short term wins; 7) Consolidate gains and produce more change; 8) Anchor new approaches in the culture]

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl