Otter's Law

For all the 'take back agile" and "agile smagile" and "apologizing for agile" and all the other post-agilists and so-called post-agilists in the world, I give you Otter's law:

Any methodology followed via obligation and knowledge-avoidance cannot produce positive change. 

I've ranted about change gone wrong and methodologies followed badly and horrible oversales and undersales and all, but it comes down to otter's law ultimately.

Too many companies have huge gains from using XP and Scrum and what-have-you. Too many others tried "the same thing" with entirely different results.

Some teams are whole-heartedly into the whole agile thing, and they seem to have pretty good. Others don't seem very excited and don't get much out of it. Is it excitement that they need?

I don't think so. I think that the lack of excitement and the lack of progress have the same root.

I think it's a lack of profluence in agile-as-practiced. Often mandated agile drives people up the old Christopher Avery "responsibility" chart all the way to "obligation." Not to responsibility.

The team doesn't have a sense that they're gaining ground at all. They may be afraid of misjudgment or criticism or failure at every step. They don't feel safe so they don't dig in for all they're worth. They tip their toes into the water, and do what they are required to do so that they don't seem to be resisting the management directive.

Worse, teams can reach a point of total anhedonia. They lose all ability to celebrate wins or feel a sense of accomplishment because nothing they do will ever be good enough. If they dig in really hard, they'll be told that it's nice to see them making some effort, but they're going to have to do a lot more. In such a circumstance, developers (testers included) can't see the sense in changing methodology and terminology. They're all in a state of learned helplessness depression. A wall of colored cards and sticky notes won't change that.

Are they digging into the material to find out how to do a great job? If not, then they are probably operating on "knowledge avoidance." They don't invest in researching because there's really no pay out for them. Instead, they'll do as they're told, as they understand it. There was no real shared mental model involved in the roll-out.

I think that people have reasons for not being gung-ho agilists to begin with. If you try using pressure to oblige (there's that root word again) them to act as if they're excited, the effort is not going to create the excitement you're looking for. It will instead establish a cargo cult.

But some teams do get a lot of excitement from the profluence, do see transformation in their code base and their companies, huge reduction in defects, huge increase in mastery and autonomy in team members, and huge bottom-line effects.

I'm not writing this to blame the people who are trying to push their company into a more ideal agile-like environment. I totally agree with that. Some managers see what is possible and want to adopt XP or Scrum for the way "good agile" can empower their organization. I don't think it's wrong for them to want it.

I'm also not blaming people who are in a system that makes them feel unsafe or guilty writing tests or refactoring existing code. They are citizens of a system. I don't expect them to stick their necks out and risk their position or reputation or standing among their peers.

I'm just thinking that every transformation runs the risk I describe with Otter's Law. If we only push people to obligation, we shouldn't expect to see responsibility automatically bloom.

The methodology doesn't come with its own culture, history, and mythology. It has to take root where you plant it.

Even the world's best teacher can't teach unit testing so well that everyone feels safe doing it. There is a control culture and a guilt culture to confront.

It has to be safe for people to try, even to fail, to adopt new practices or to take control of their code.

Wrong naming revisit

I was looking at the excellent work by appium, and saw this little snippet in an example:

var el = driver.FindElementById ("name_input");
	el.Clear ();
	el.SendKeys ("Appium User");
	el.SendKeys (Keys.Return); There's nothing horribly wrong with the name el, except that it's exactly what we ask people not to do with names.  El is short for element (a bit of mental mapping, but the length of the name reflects the shortness of scope). But it is not informative. The variable "el" (EE-EL) looks like "e1" (EE-ONE) to the casual reader. The name doesn't look right.  Also, "element" is what it's made of, not what it's for.  Yes it's an element. But it means "the name input field" so "nameField" or"name_field" or "name" might be better. Or even "input" if it's the only input field in the block. Appium is pretty cool. You should check it out. But remember that writing examples is both something rather important (people copy or imitate examples) and something hard to do. We write them thinking "the api is the important thing" or "the idea is what matters" but we forget how seriously people will take examples.

What is a Coach?

I'm a software org/team/individual coach. What the heck does that mean?

On a closed mailing list, Geepaw asked for our definitions of a software team "coach," and several offered opinions. 

This one is entirely mine. 

On reading my definition, John Kern interpreted it to mean "individuals" whereas I intended these to apply to teams and organizations as well. I thank him for bringing up the possible misinterpretation, and I leave it up to my readers to understand I mean it in a plural sense; organizations and teams have skills and habits and mindsets just as individuals do.

Without further ado:

A coach is someone whose:

1) work is with people

2) primary product is an improvement in their abilities 

3) secondary product is an improvement in the way they interact with teammates and peers.

4) teaching comes through interaction, not mere lecture or advice (that would be a counselor)

5) work is done at the request and permission of the coach's client

I would also note that when we refer to "abilities" above, it is in the same sense that JB Rainsburger mentions, that of increasing capabilities and removing impediments.