Blankie

Both of my kids have had 'blankies'. If you've had kids, yours probably did as well. You know what I mean — that near shredded piece of material of some sort from which your child is inseparable. It's tattered and torn, smells kind of funny and is next to impossible to wash because your child, um, resists having it taken away to be washed.

At first I thought the connection to blankie was something short-lived and would be replaced by the next shiny thing to come into view. Um, no. When astronomers discover the centre of the universe, they will find that it's a blankie. Hours of my life I will never get back have been spent searching for a lost blankie. I have turned a vehicle around to drive for 30 minutes to retrieve a forgotten blankie. Such are the lengths to which you will go in order to placate (or avoid altogether) an inconsolable child.

There comes a time, though, where a child needs to move on from his attachment to blankie. When he's screaming, you fully believe that he'll be 21 and moved out before that time will come, but trust me it will come eventually!

Coaching Point
Having a security blanket or other such object is quite common in young children. Indeed studies suggest that about 60% of North American children have them. There is a lot of psychology involved in their use, but the simple explanation is that they provide comfort and security during transitional periods.

Moving from a traditional software delivery process to Agile can represent a significant upheaval to a team and organization. You need to fully expect that people will latch onto their blankies during this transition.

What does an adult-sized, software delivery project blankie look like, you ask? The first place to look is the things that team members say they must have or must do because they have always done it that way.

• We have to use Gadgamahoozit® to perform round-trip object design because the company has a seven-figure site license.
• We have to use Whatchamacallit® to perform code reviews with the architecture group.
• We have to use GotLotzaBugz® to track defects because we have to know what we've fixed and how we fixed it, so that we don't have the problem again.
• We can't possibly use index cards and sticky notes for planning because everyone knows that solid requirements are the foundation of good software.

From my jaded, been there done that coaching perspective I see the following counterpoints:

• Get your rear ends together in front of a whiteboard for an hour, and do that every time you need to hash out some design or another. Use the money you saved on the tool license to get better workstations with multiple monitors, a decent build server and excellent chairs. With the multiple six figures you have left over, take the team out for dinner and give the rest back to the company!
• Use Pair Programming. That is all.
• You are going to drive quality so deep into your products that any bug tracking system will have cobwebs growing on it and it will beg for you to revert back to a traditional development process. Seriously. You will have so few defects that escape the team that you won't need to track them. No, really. Furthermore, every time you do find a bug you will perform root cause analysis to determine if that same bug could be anywhere else in the system. You'll determine what part of the team's process allowed the bug to make it into the code in the first place, and how to avoid the bug altogether.
• The only solid requirements are those that you get after a system has been released into production. Even then they aren't particularly solid. Using low-tech tools like index cards and/or stickies, there is a very tactile, visual aspect to cards - everyone can visualize how much work must be done, and the current status of that work. The card wall also represents a meeting area for the team, where they can synchronize their current status.

If you've ever tried to separate a child from her blankie, you know that it's, um, a process. It may take some time. It may take forever. What you really need to do is examine why your team believes that they need their blankies.

In some cases, there may indeed be legitimate reasons for such things as traceablility. If your business domain is regulated, such as the pharmaceutical industry or aerospace, you may have to prove that any code change traces back to a particular requirement. You can still do that via automated acceptance tests, and indeed many Agile teams do.

Other factors include the possibility of audits from an outside agency. In the public sector, the dreaded Auditors may come calling at any time much like The Spanish Inquisition, at least in its Monty Python incarnation. Generally, the auditors aren't interested in how a change to a single line of code traces back to the light bulb moment for someone in the business, but rather than there was a specific business reason to have made changes in the first place. In that regard, Agile absolutely shines!

So, ensure that you understand the team's motivations for hanging on to their blankies. They may have good, legitimate reasons in which case they can keep blankie until they're retired. In other cases they may only believe they have good reasons, in which case you may need to wean them off of blankie slowly. Going cold turkey rarely works.

Consider the bug tracking system. Have them stop using it for any new defects - only the existing ones. All new defects should be tracked using a low-tech approach like index cards. After 3 or 4 months, find out how often the team has actually used the system in the last month. The answer will quite likely be that they haven't used it much, if at all. That knowledge coupled with the new root cause analysis process will provide them with the security they need to move away from using the defect database altogether.