Continuous Improvement Book

I did not manage to use my Christmas break to get a lot of work done on the book.

I tried, but there was much going on in our world (almost all good stuff) and I was unable to get the focused time I was hoping for.

You might be able to access a sample of the draft as of today. It is only a small bit of the book, but maybe enough to whet your appetite.

I hope to decide on the "early adopters" price soon, and finish up the initial set of illustrations (thereby getting rid of the ugly ascii art that appears in some places, and breaking up the expanse of text that appears in others). If you want, use the public page to suggest a price.

Thanks for waiting. I hope you'll find the result thought-provoking and useful.

Circling the Drain/Facing the Truth

Messages from the past have a way of reaching into the future and getting your attention.

This week everyone is talking "apocalypse." This is because of an ancient mayan calendar which quits tracking time on Dec 21st. The joke (I hope we all know it's a joke) is that it stops because that's when time ends. Of course, my calendars used to run out every year (before Google Calendar).

The word "apocalypse," according to my sources, was a theatrical term. It referred to the moment when the curtain was pulled back and all was revealed. When I learned that, the title of the biblical book "Revelations" finally made sense, as did more of the text within.

Today I'm facing my own apocalypse. An ancient message (from two years ago) has come back and presented itself to me.

I like this team. They're good people, and they understand their business. They write quite a lot of code, and they get along. There is nothing to dislike, and much anyone can learn from them.

On the other hand, I don't get any takers when I want to pair up and teach testing, refactoring, and other code quality practices.

The card keeps popping up, either when I page through my AgileInAFlash deck or when I am quietly contemplating the team and my experience here (success mixed with confusion and frustration).

The fact is, the team is not growing as a team. They are at best holding steady and coping. They are learning about code smells and have seen some demonstrated skills, but there is not a strong uptake.

Are they circling the drain?

The voices of Ottinger & Langr from two years draw my attention to difficult facts:

• They self-assign, but they take individual work assignments. There is not a full-court press to complete features. Instead, each feature has minimal human bandwidth: at most 1. The team doesn't work together.
• There are piles of unfinished stories at the end of every sprint. Some are started, and the point total is always pretty high for a team of this size, but there is a lot of "hangover"
• The work that gets done is not the work that was planned. There are tasks given to individuals from outside the team (self-selected sometimes). Those tend to get done at the expense of other things. Stress, of course, is fairly high as the end of sprint approaches, but this is seen as "normal."
• The retrospectives and daily standups are not very helpful because of the first problem listed. Standups are just status reporting - a time to update Jira/greenhopper. It isn't a vital time of sharing successes, needs, and lessons learned. Retrospectives tend to follow the same formula and produce fairly similar results, though some actions do seem to move the team forward now and then.
• Once the code is done, they try to test it. If they finish that, they might refactor if they have time. By not doing test-first and continual design improvement, they end up neglecting quality practices. I'm not seeing a lot of automated acceptance tests.
• The damning stroke is that they don't like sharing code, holding it close to the chest until it is "done."  The feeling of personal safety is not high. If they were pairing to begin with, test-first, integrating continually, then there would be a lot less stress about revealing code. 

The item we didn't know to put on the card is "situational awareness." It's the military concept that people are aware of position, direction, intention of teammates and the location, direction, and intention of hostile forces. They know their situation, and it enables them to act in a manner that their teammates can anticipate and work with, but that their enemies will find frustrating and possibly devastating. You have to know your situation.

I fear that the team does not have good situational awareness. In my few weeks here, I've never had a sense of how the team and it's products are tracking. There isn't a "customer" (XP sense or Lean Startup sense) to give feed back. There are no big visible charts. There are online data sources like Jira and Sonar, but I don't know that anyone really looks at them.

Apocalypse: we're not making the progress I'm here to ensure.

Now I have some situational awareness, time to get started.

Code Oddity: Conditionally starting

I'm starting to see a lot of these:

 
for(int x=0; x < someLimit; x++ ){
     if (x == 0 ) {
       // do initialization
     }
     else {
       // do everything else
     }
}

Is it just me, or is this a pretty weird thing to see? I've seen it a half-dozen times in the past few months and I don't think (outside of Duff's device) I've seen a switch/case or if/else on the loop counter in years.

Robert Probst and the Cubicle Wars (we lost)

I was talking with some folks in California last week about the evolution of cubicles from the original "action office" where everything was movable to the modern view of cubicles as tiny jails with fixed walls held firmly in place by management policy and departmental will.

Originally, the office was supposed to adapt to the needs of the people living/working in it, but then something sad happened:

Propst believed that the facility should adapt to the needs of the individuals, and there could be many forms of adaptation. But in the 1980s and 1990s, standards programs and the box move—move people instead of the office—became the predominant planning model. Workers had to adapt to the facility. What happened to a human-focused, individual-focused interior design approach?

This is not an unfamiliar story. I think it has some parallels with other great movements of the past few decades in that some mechanical aspect of the original work is kept, but only after the humanity is extracted.

It reminds me of Dr. Who's enemies, the Cybermen, who "improve" human beings by removing all the humanity from them.

This is the risk that faces the Agile software methods as large corporations "improve" it by twisting it into a plan-driven, ceremony-heavy way to extract effort from workers without sharing control.

But on the topic of cubicles, be sure to read up on the change at Herman Miller Research. Don't miss his five rules for work environments.

TLC Labs Doesn't Do Performance Reviews

I read an interesting post from The Library Corporation's TLC Labs.

Here's what I learned:

Since we ended reviews, we have seen employee retention improve substantially. A host of other metrics that one could argue would be likely to be affected by “performance management” have also improved. I can’t prove (or disprove) that not doing forced ranking was a major driver of these outcomes, but I feel safe in saying that at the least it has done no harm.

When you see your company asking how they can improve employee retention, try pointing them to this blog post and let them see what happens when people realize the futility of pitting employees against each other.