Circling the Drain/Facing the Truth
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.
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.