#52-Changing Change, Part 1

If we are to be successfully agile, we must embrace unpredictable change.  But to do that, we have to fundamentally alter our relationship to change itself.  This is part one of a series about how I recommend teams accomplish this.

Transcript

Changing Change, Part 1

Agile resists the notion of up-front commitments, favoring teams that can respond to changes as they occur.  Does this mean we cannot make any early decisions?  That would seem to lead to a chaotic process.  No, what we want to do is to make early decisions about product design that focus on the interfaces involved, rather than the implementation details.

The best illustration I've even seen of this came from a friend of mine named Jeff McKenna. Jeff is an agilest, and a brilliant systems engineer.  I was lucky to work with him for a time.

In this case, he was giving a lecture to a very mixed audience when this question came up from a team lead.  To address it, he did a demonstration.  The whole room was full, but he focused primarily on the people sitting in the front row.

Jeff went down to that first row with a notepad in his hand and he stood in front of the very first person, and he said to them "what is your driver's license number?" The gentleman looked a bit uncomfortable with the question, probably thinking "why do you want my driver's license number?   I'm not sure I want to give you my driver's license number." But he didn't say anything for a few moments. Jeff just stood there calmly waiting for the man to respond.  Eventually, I guess feeling that everyone was looking at him, figured he'd better answer the question.

So he took his wallet out of his back pocket, opened it, flipped through until he found his driver's license and read out the number, which Jeff wrote down, and thanked him. Jeff moved on to the next person.

"What is your driver's license number?"

This person happened to be a woman and she had her purse next to her on the floor.  She did not reach into a back pocket. She picked up the purse, put it on her lap and opened it.  Inside was a smaller clasp purse.  She took that out and opened that and inside was a bundle of credit cards, business cards and other things of similar size with a rubber band around it.  She undid all of that because her driver's license was in there among those things, and once she found it she read Jeff the number. He wrote it down, thanked her, and just kept going like that from person to person to person.

When he got to the last person in the row and he asked, "what's your driver's license number?",  the person just told him without doing anything. Apparently, this person had their driver's license memorized. Why would you memorize your driver's license number?  I don't know, maybe he gets pulled over a lot. 

Anyway, Jeff finished that and he said "Okay.  What I just did was what agile reccomends; I focused on the interface.  To show you the distinction, I'm going to do the opposite and not follow this guidance."

Jeff restarted the exercise.

He went to the first person and said "reach into your right back pocket, take out your wallet, open it, find  your driver's license and read the number to me."

When he got to the woman, this was not going to work at all because she didn't have it in a pocket, she didn't use a wallet, a whole different set of activities were needed, and he went through all of those, and she did everything he asked, and he wrote down her driver's license number.

When he got to the person at the end of the row who had it memorized he had to say "recite your driver's license number from memory."

Jeff's point was that he had to take different actions with different people but also he had to know what actions to take, he had to know where each person had their driver's license stored, if they had it stored at all. He had to alter what he was doing in order to get what he needed and he pointed out that the next time he does this exercise if somebody comes in who has their driver's license stored in some completely novel way, maybe they have it on a slip of paper in their breast pocket, maybe they have it written on the bottom of their shoe, then he'll have to do something different, something he's never done before.

Jeff said "keep in mind all I wanted was a list of drivers license numbers. This burdensome additional work does me no good, doesn't help me in any way, but it makes my process much more complicated and means I to have to constantly change what I'm doing for no value or purpose.  I get what I got before, a list of driver's license numbers which," he said crumpling it up, "I'm certainly not going to keep."

When Jeff took the second approach he became vulnerable to differences in the specifics of implementation, which meant he would have to constantly change what he did, for no value.  In the first approach, he focused only on value and thus could embrace future changes.

Understanding this, the development team must be lead toward this approach, and trained to achieve it effectively.  This is one of the critical things I teach when I train them.

But it's not the only one.  Stay tuned.