Perfection Obsession

A few years ago my wife's twenty-something niece was married.  We stayed with my wife's sister and brother-in-law - the parents of the bride - thus having front row seats for what can only be described as the insanity of the final gyrations of the process of staging a wedding.

First, an assumption: I'm referring to a standard, North American, Christian-based wedding with a church service and reception. For the families of both the bride and groom this was the first wedding of their respective children, so they wanted to make sure it was perfect.

Hmmm... perfect.  That term came up repeatedly during the 4 days we were there.  The bride wanted such and such to be perfect.  The mother of the bride wanted such and such to be perfect.  The father of the bride wanted such and such to be perfect.  The groom wanted such and such to be perfect. The parents of the groom wanted such and such to be perfect.  People were at the point of physical and mental illness over the stress of this event.  Why?  Because they were absolutely obsessed with ensuring that the whole event was perfect.

My father-in-law (the grandfather of the bride) and I opined about this while driving to the church.  There had been an explosion of emotion (relatively small - perhaps a few kilotons nominal yield) the day before the wedding when it was discovered that they couldn't find all of the proper holders for the table markers.  Uh, what exactly is proper?  Well, they were short two (out of 15) of matching holders and that just wouldn't do.  Tears and bad feelings ensued, and eventually the father of the bride drove 45 minutes across the city (one way) to a place where matching holders were found.  I suspect it was actually an excuse on his part to escape the insanity.  My father-in-law wondered aloud what difference it would make, and he was scolded by the bride-to-be, her mother and my wife:

Every girl dreams about her wedding, and wants it to be perfect!

I asked if anyone had ever been to a perfect wedding.  Actually, the more correct question would have been, has anyone ever noticed that a wedding wasn't perfect, or if so, did they care?  The response was silence, but I'm not entirely certain if it was because anyone other than my father-in-law agreed, or that they were quietly plotting my painful demise. :)

Coaching Point

Since 2001 I've given many presentations on XP and Agile Software Development.  I almost always started by polling the audience on their experience level.  "How many people have less than 5 years in software development? How many have 5 to 10?" etc.  I then ask how many of them had been on a project where nothing had changed from start to finish.  There's always a knowing chuckle from the audience and I launch into my presentation.  That helped me to see that there are some lessons to be learned from this obsession with perfection at a wedding, and in the delivery of software to production.

First and foremost, nothing is ever perfect.  Ever.  It's that simple.  Any non-trivial system will have defects, just as every wedding will have a hitch or two somewhere.  Some will be larger than others and can't be ignored - not having a marriage license or a bug that corrupts data fall into that category.  Others will reduce the quality of the overall experience - my wife wanted Gospel singers at our wedding and would have been quite disappointed if we hadn't been able to get them, while an application may have a memory leak that forces the user to close it and restart every so often - painful, yes, but the show can still carry on.  Still other problems may have what seems to be a tremendously inflated impact - the table marker holders or perhaps a query that doesn't run as quickly as we would prefer - but once 'production' occurs the 'user's don't even know that there's a problem.

The bottom line is that we can reduce stress in very significant ways by determining what's good enough for your given circumstances.  At a wedding reception, that may mean having a DJ play quiet music during the dinner rather than hiring a string quartet.  In software, that means performing risk and value assessments on all defects and enhancement requests.  Some stuff can simply be ignored, while others may need to become the sole focus of the entire team until they're fixed.

Another way that weddings and software development are similar is that nothing ever goes completely according to plan, so you need to either have contingencies or simply be able to go with the flow.  When my and I were married, halfway through the ceremony my son (from a previous marriage) leaned over to me and said that he had to go to the washroom!!  Well, when he says that, what he really means is that he had to go about 5 minutes ago and now he really, really has to go!  So, I looked at one of my groomsmen, and he nodded and took my son to the washroom.  They were back in two minutes, and everything went along smoothly and everyone in attendance had a good chuckle.  This happens in software too, and often we need to deviate from the plan in order to accommodate an unforeseen circumstance.  We don't have time to perform an impact assessment or have the Change Control Board provide their blessing.  We simply have to deal with the issue right there and then.

Finally, the industries surrounding both weddings and software development have a tremendous impact.  We are literally inundated by information from the media, colleagues, friends, etc. about what are the best approaches and tools.  This happens in software too! :)  Seriously, though, our expectations are inflated by these external influences and we can come to ignore our own feelings and experience about to approach putting on a wedding or building software.

I could also draw parallels between how it requires a collaborative team to handle both a wedding and software, how children can result from both, and, most regrettably, that they both have a similar failure rate.  I think you get the point though! Just for fun, try describing your last project or two and replace all software development terminology with that which would be used for a wedding.  You may be surprised at just how similar they are!

Rounding the Corners

My parents had a relatively large lot, and it used to take me a good two hours to cut the lawn.  The problem was, I hated cutting the lawn.  I could never understand why we want to "maintain" our lawns, making them look as artificial as possible without resorting to Astroturf.

I would do whatever was possible to get out of cutting the lawn.  I still do, for that matter!  Raining in Sudbury? Well, it could make it to Ottawa at any time... that would be unsafe!  Inevitably, though, I had to cut it.

Even then, I wasn't going to go out of my way to extend my agony any more than was necessary.  The back lawn in particular was quite large, and by itself it took a full hour to cut.  I guess I have the process improvement gene turned on, because I spent a good amount of that one hour trying to figure out how to make it something less than, well, one hour.  Eventually I figured out what slowed me down - square corners.  Each 90 degree turns mean stopping, turning the mower starting again.  If I could remove as many of those corners as possible, I would reduce the amount of time it took to cut that lawn.

This particular yard wasn't perfectly rectangular, and had several trees.  I determined that there were a few places along the edge I could cut first to remove some of the variance in the shape of the yard, and that I would have to do at least one full pass to cleanly cut the outside perimeter (OK, so I did care a bit about the quality as well!).  After that, I kept to cutting in one continuous strip that was curved around the corners rather than square.  This didn't bother my Dad at all, so I then set about optimizing the new process.

It took a couple of tries, but I eventually reduced the cutting time from a full hour to 45 minutes. Being a rather impatient teenager at the time, having an extra 15 minutes to do what I wanted was much better than nothing!!

Coaching Point
The teams with whom you work may be used to square corners in their process, their tools or even just their practices.  Look for ways to help teams identify where they can round off those corners to reduce or eliminate disruptions in their flow.

For example, automate anything that the team has to perform more than a single time.  Testing, builds, deployments, etc. are all practices that can be automated to some extent and have a tremendous amount of tool support now.  I've worked with teams that automated the creation of a developer's work environment so that a new person on the team could be up and running in minutes!

Even partial automation can be helpful.  If complete automation of a test is difficult or expensive to do, can the setup and/or evaluation of the results be automated?  Could you use Perl or Ruby to write a script that put a database in a known state prior to executing a test?  Rather than poring over a huge log file, would a shell script that simply grepped the results work?  When evaluating the UX of a particular portion of an application, can an automated script be used to get the tester to the point where the human eyeball takes over?  Could that same script pause, prompting for a pass/fail decision from the tester?

Of course, it takes time to determine the level of automation that works best for a team.  After all, I didn't simply come up with the one true way to cut that lawn in one day - it took several iterations before I was able to figure out the optimal approach.  There's also a cost associated with creating and supporting the automation tools and environment, which is best done by the team or teams who are using the automation tools.  The people using the tools have the most vested interest in seeing them work and improve further!


In the end, these "rounded corners" will keep the team moving ahead at a steady pace in the long term.  They promote flow and allow the team to accommodate changes as they learn more about what they're building.

Oh yeah, after I moved out of my parents' house, my Dad bought a riding mower. Cutting the grass is now considered fun, I'm told.  I have never had the opportunity to use the riding mower myself. I'm sure there's another lesson there somewhere! :)

Controlled Fall

Humans have evolved over the last 3 to 4 million years to walk upright constantly on two legs. While many of our primate relatives and some other animals are able to walk for short periods of time, we are almost uniquely bipedal.

It's fascinating to watch a baby learn to roll over, move about in one spot, start to crawl, pull themselves up to standing, move while holding on to items such as furniture, stand freely then finally take those first tentative steps. While each of those steps occurs, the child is building neural pathways like there's no tomorrow to help them coordinate their movements and the signals coming from their inner ear that tell their brain which way is up.

The act of walking is interesting in and of itself - it's actually a controlled fall. We lean forward a bit, and one leg moves out in front. If not for that leg, we'd fall flat on our faces. Somewhere deep in our DNA, something triggers the growth of paths in our brain that builds the progression from rolling over to walking, increasing our ability to balance ourselves upright all the while.

Of course, a few short seconds after a toddler learns to walk they want to start running! We often see these small children careening out of control into furniture, walls, pets or anything else that gets in the way. Running is an extension of walking which takes much more balance and coordination, i.e. much more control over the falling process. Children gain this control at a startling rate - within a year of learning to crawl, a child will be literally running amok, and any house pets will be eagerly searching for high ground in order to stay safe.

To prevent catastrophic injuries, we make the child's environment safe. We put gates on stairways to prevent that controlled fall from occurring in mid-air. We add soft cushioning to the corners of tables. We move plants and decorations from once inaccessible places to somewhere out of the reach of this now very mobile toddler.

We make the environment safe for the child to run around. Whether we want them to or not, they are going to go fast.

The only way to go fast is to be safe. *

Coaching Point
I've mentioned before that, like toddlers, teams are obsessed with going fast. Like toddlers, this is not a bad thing most of the time. Like toddlers, moving fast can mean that a team will bump their head on the corner of a table. They might fall down the stairs. They may simply lose their balance and fall. They may go places that they shouldn't before someone can stop them. So, the environment in which a team works must be made as safe as possible in order to prevent injuries while going fast. How do we do that?  Test-Driven Development (TDD).

TDD at the Acceptance and Unit levels keeps the floor clean, protects the corners of tables, puts gates on the stairs, moves plants, gets the pets out of the way and adds a layer of foam cushioning to the floor. I realize that the concept behind TDD is completely foreign to pretty well anyone who hasn't tried it (and many who have), but after a decade of using it I can say without a shadow of a doubt that it's the best way to develop software that I have encountered in the 30 years since I wrote my first program.

When I first learned the technique in early 2001, it took 3-4 months of constant use to move from "this is just crazy" to "this is kinda cool" to "this is fantastic". Like learning to walk and run, it doesn't happen overnight and every person's progression is different. You will hear people complain that they're slowing down because they're writing twice as much code because they're now writing tests. Experienced developers will rail at having to write such simple code to make a test pass, i.e. it would be faster to take bigger steps. Everyone will complain about how difficult it is to do TDD with legacy code - it takes so much time to be able to write the tests to enable the refactoring required to untangle the mess of code that was written without tests.

All of the complaints revolve around wanting to go fast. Yes, you have to write more test code, but the benefit far outweighs the cost in the form of persistent validation of our assumptions about what a particular piece of code should do. Yes, you take small steps, but in doing so you will very likely write less code, certainly less complex code and code that's inherently testable as a result. Yes, legacy code is a pain, but if you want to use it safely you need to get tests in place.

After all, the only way to go fast is to be safe.

* Credit goes to James Grenning for this aphorism. "Uncle" Bob Martin has used a similar term: "The only way to go fast is to go well."

Playing in the Mud

Many parents, at times this one included, become obsessed with ensuring that your kids are clean.  We do whatever we can to prevent them from getting dirty - cover our kids with clothes that prevent anything dirty from touching their skin, keep them out of mud and dirt, have a constant supply of hand sanitizer nearby, hose them off if they do manage to get something on them... and they still manage to find ways to get dirt on them!!

When they get food on their faces while eating we chastise them and wipe it away.  When a child encounters a mud puddle, their first reaction is to jump into it... a parent's is to react in horror and haul the kid away to be cleaned.

We worry about our children playing in public sandboxes because we don't know who or what has been playing in there before them!

IT'S A DIRTY WORLD, AND WE HAVE TO PROTECT OUR CHILDREN FROM IT!!

Or do we?

Coaching Point
Put simply, humans need to be dirty. We literally need to have bacteria on our skin in order to be healthy. All of the hand-washing and sanitizer we foist upon our children is meant well, but in reality we're actually doing as much long-term harm as we are short-term good. The fact is that we as a species evolved in a dirty environment - we didn't have soap or hand sanitizer 50,000 years ago!

The same type of side effects occur when a software development team doesn't work in an environment where they're allowed to get dirty. They aren't allowed to experiment. They aren't allowed to fail in small ways that allow the team to learn as they move along. Everything has to be perfect the first time, or it's considered a complete failure.

So, how well does that approach work? What are the side effects of sanitizing the development environment to remove all the dirt? Innovation is stifled. Code becomes riddled with Technical Debt because there is fear of making the changes required to keep it clean. Eventually, it costs an increasing amount of time and thus money to maintain and extend the code and ultimately a complete rewrite is required.

Wouldn't it be less expensive and much more effective to allow teams to play in the dirt and find ways to improve the software in smaller ways over time? Yes, there will be occasions where the small experiments won't work. Yes, there is a risk that some of the small changes will break other code. But, like the long term effect of allowing a child's immune system to be exposed to staph bacteria early in life, the rewards of keeping the code fresh and clean enough far outweigh these risks.

So, paradoxically, if people are empowered to get dirty, cleaner code, a better product and a more productive team will result.

Are We There Yet?

I recall driving to Toronto one time with the kids.  It's about a 4 hour trip, and somewhere around 30 seconds after we left my son asked, "Are we there yet?".  Of course, I patiently responded, "No, we have about 4 hours to go!"

After another hour and several thousand additional queries about our arrival status, I decided to change things up.  When my son asked, "Are we there yet?", I cheerfully responded, "Yes!"  He answered, "No we're not!", to which I not-so-patiently responded, "THEN DON'T ASK AGAIN!!!".  He had nothing to come back with, and I basked in my victory for at least a few minutes.

Coaching Point

There are a number of points that can be taken from this story.

First is the need for releases that are as short as possible.  When you work away for months at a time and can't see the goal towards which you're working, your motivation can erode somewhat.  Imagine climbing a hill shrouded in fog - you just keep climbing and have no idea when you're going to reach the top.  You may eventually become bored with the climb and start back down, when in fact you were only a few metres from the top that you couldn't see!  Release cycles of 24, 18, 12 and even 8 months can have this effect, whereas cycles of 1 day out to 6 months are within "sight" of a team, allowing them to focus better.

Second, there are situations and or products that do require longer cycles (at least initially).  Visual management can help communicate your current and projected locations reasonably well.  For example,
I now like to use our GPS for any long trips even when the route is well-known and we don't really need a map.  Our GPS also shows Distance Remaining, Distance to Next Waypoint and ETA/Arrival Time.  Everyone in the vehicle can see this information and as a result the question in the title of this post is now rarely, if ever, asked.  What information could you display for your project or product that could achieve this?

Third, teams that have been using an Agile process for a good length of time can find themselves in a rut or becoming caught in the daily and iteration-length 'grind' of the process.  On several occasions I've heard team members and even entire teams speak of working away from Iteration Planning, through the iteration, performing a demo, holding a retrospective and then get right back into the next Iteration Planning.  The common theme has been, "We don't have time to catch our breath!"  This can be a symptom of a few issues:

• No slack built into the iteration to allow for unexpected work or work that was larger than expected
• No slack built into the iteration to allow team members to 'sharpen their saw' or to spend a small amount of time refreshing their minds
• This may sound silly, but the use of the term "Sprint" for Iteration - the words we use can and do affect they way we perceive the world.  If a team is constantly "sprinting", they can have the feeling that they're out of breath at a certain point

The key here is to understand that you can't simply fill every single minute of time within an iteration with work directly from the backlog.  Not only is that unrealistic, it will burn out the people on the team.  The excellent book Slack by Tom DeMarco says,

Slack is the lubricant required to effect change, it is the degree of freedom that enables reinvention and true effectiveness.

In other words, by giving teams some time where they aren't working on their regular work, they will be more effective and efficient.  They may also come up with new ideas and even products!  Regardless, look for ways to allow team members to recharge.  Ask the team for ideas, or suggest some team-building activities or even just some 'free' time off, i.e. not charged to their vacation.

Finally, you need to consider what questions are really being asked.  When my kids were asking, "Are we there yet?", the real question is, "When are we going to get there?"  I solved that problem somewhat by using the GPS which displays that information, although when the kids were younger the concept of 3 hours was as abstract as 3 days or 3 months!

If a team member says, "We're stuck in a rut... one sprint after another with no time to breathe", what's the real issue?  Do they have any slack?  Not enough slack?  Is there external pressure to do more, requiring communication with stakeholders?  Do they need to go out for a beer after the iteration demo and forget about the retrospective and iteration planning until Monday?  All of the above?  The point is to not necessarily take the question or statement at face value - try to identify the real question or the root cause of the statement.

While you can simply answer, "No" to the question, "Are we there yet?", that rarely appeases the person or people who ask it whether they're 3, 33 or 63.  Ask yourself what you can do or suggest to either find the real question, make the information required visible or even change the circumstances such that the question never needs to be asked in the first place!

Patience, Persistence... and Ear Plugs

For the first couple of months after my son was born, we had a heck of a time getting him to sleep in the evening. After a couple of months I realized that I just had to let him scream until he fell asleep. Once he did he slept like, well, a baby! 

Getting to that realization was tough. He was literally screaming as loud as he could into my ear (I've been tested, and the hearing in that ear is diminished!), and he would wriggle away. I figure that he was ticked about having to go to bed! Regardless, the screaming became a routine, and once that routine was established it wasn't as stressful. 

After a few months the patience and persistence paid off. He screamed less and less, eventually going down to sleep without a fight. 

Coaching Point 

When a team is first starting their transition to Agile, you will hear a lot of screaming... mostly in the figurative sense, but sometimes literally. For most of the organizations with whom I've worked, Agile represents a fundamental change to how they think about their organization and their work. Any change that significant will create fear and stress. People will think that they may lose their job. There will be those who lose what they believed to be a prestigious title. Sacred cows may be slain in the name of moving to Agile.

Be prepared to put the team on your shoulder (figuratively, of course) and let them cry it out. Give them time to learn how to work in short cycles.  Give them the support and time needed to learn test automation.  Give them the support and tools needed to effectively inspect and adapt.  When the team has gripes & complaints and wants to give up, listen patiently and with compassion.

If that support is available to them, over time their need to "cry it out" will diminish and eventually disappear.

Believe in It

My Dad wasn't one for giving lots of advice about life. Golf, yes, but life, not so much. One thing he did say, though, has stuck with me.

Dad was a partner in an insurance brokerage and estate planning firm. He arrived at that point in his life after joining the Personnel group of a very large insurance company in the mid-1950's. He stayed in Personnel, later Human Resources, right through until the mid-1970's. He finally decided to make the change to Sales after he could no longer be a person who had to fire other people. In fact, the stress of firing others almost killed him.

He joined the Sales organization of this company, and his people skills resulted in immediate success. After a few years, he and his boss left the large company and started their own brokerage. Many trials and tribulations ensued, but the company persisted and flourished (they're still in business and growing some 30 years later).

As Dad was winding down his career and preparing for retirement, he talked me about carrying on his legacy by being part of the company. I said to Dad that I really didn't feel that I was a salesman. His response was,

"If you believe in the value of what you're selling, you will have no problem selling it." 

I didn't join the company, but those words have stayed with me ever since.

Coaching Point

You may be the lone voice in the woods at your organization, telling anyone who will listen that Agile is the way to go!  You may be an independent consultant that has to market your services to potential clients.  Regardless of your circumstances, as a coach you are often put into the position of selling Agile to people within organizations.

This is where the rubber hits the road with respect to your passion and commitment. If you believe, and I mean truly believe that Agile Software Development values, principles and practices will bring benefits to your clients or your organization, the selling part will come easily and naturally. Of course, you have to know what you're talking about and you have to have used an Agile approach in practice more than once to be truly able to convey the process to others.

Remember, though, as much as you believe that Agile is beneficial your audience may not be ready, willing or able to listen to that message. A team or organization must be feeling enough pain that they are willing to be open to seeing the value in the approach you're suggesting.

Yes, those words have stayed with me.  Indeed, they have gotten me through some rather grim and frustrating days as an Agile Coach.

How many software projects have you been part of that were late, over budget, full of defects and took a human toll in terms of stress and burnout?  Agile is by no means a silver bullet, but it does represent insurance against many of those issues.

Why?

When a toddler learns to speak, often his first recognizable word is "Mom" or "Dad" or some variation of those.  His second is "Why?"  If you were to take a teenager and, like, count the number of occurrences of "like" in their, like, speech, DOUBLE THAT and you would approach the frequency at which a toddler uses the word "Why".

The constant questions can drive you absolutely crazy - I truly believe the word "because" was invented to deal with an inquisitive toddler.  However, a great deal of patience is required to be able to help the child learn not only their language but how to use it and communicate with others.

Coaching Point

There's a very good reason why young children constantly ask "why".  It should come as no surprise that it has to do with learning about the world around them.  (As an aside, parents these days are blessed with tools such as Wikipedia to assist them in explaining why the sky is blue - those of us who had to raise children in the last century were forced to read books to learn such things!)

Asking "why" is a method for a child to learn, learn and learn while their brain is a veritable sponge for absorbing knowledge.  There's also a more subtle reason and mechanism at work, though.  By asking a question such as "Why?", the child has a tool to keep a conversation going.  The other person remains engaged and talking with the child which helps her expand her vocabulary, learn new patterns in the language and to actually use what she has learned.  In short, as children we are wired to ask questions in order to learn how to effectively communicate with others.

As a coach, you have tools for helping teams expand both their knowledge and their ability to communicate.  For example, and in keeping with the title of this post, there is the 5 Why's technique pioneered by Toyota.  The concept originated at Toyota with Taiichi Ohno and is considered a key tool for performing root cause analysis in Lean.

5 Why's is one method for performing the critical inspect and adapt function within any Agile process.  Teams and organizations must look at how their process is working, determine where and how it could be improved and actually carry out those improvements.   Most often this occurs in retrospectives, but it doesn't need to be limited just to that one meeting.  Following the Stop and Fix and Continuous Leanring concepts of Lean provides a perfect opportunity to apply 5 Why's.

While Inspect and Adapt may sound like common sense, I have seen too many teams give only lip service to the concept and simply live with their existing circumstances rather than attempt to improve them.  This is the equivalent of a child asking a single "why" and giving up - they don't really learn that much and they don't improve their communication skills.  As we mature we often become conditioned to asking fewer and fewer questions about issues we see.  People want to be good corporate citizens and not "rock the boat".

Similarly, I've seen many instances of people and even whole organizations where bad news is avoided at all costs.  Unfortunately, the answers that emerge from 5 Why's are not always what people want to hear.  In that sort of culture, problems are a sign of weakness, not impediments that need to be removed in order to improve how the organization does its work.

To be able to effectively ask "why" and process the results, trust needs to be built within the team and outside so that no one is afraid to state that there's a problem that needs to be dealt with.  Within the team is relatively easy to accomplish once they move to an iterative delivery model that shows results on a regular basis.  I once coached a group that was very distrustful and dysfunctional until after a single team leader left and an agile process was implemented.  Trust started to be built immediately once all team members started attending meetings and became involved in the process, and by the end of the first iteration the group had gelled very well, and wasn't afraid to ask the questions required to delve into some tougher to solve problems.

So, in order to be truly effective and continuously improve, you need to channel your inner toddler and ask "why" (among other questions) at nearly the same rate as a 2 or 3 year old.

It Pays to Lose Sometimes

My son loves to play video games, especially hockey (hey, we're Canadian - the hockey gene isn't recessive here).  He also loves to win, and win big.  He sets up the game so that there's no salary cap and any and all trades among teams are accepted.  He then proceeds to create the most stacked team in the history of the sport, followed by putting the game at its easiest settings.  What follows is a constant stream of hugely lopsided wins.

That's great, right?  His self-esteem must be at an all-time high!  Yes, it is.  It's also complete crap.  In life, we don't always win.  We face constant challenges, and true self-esteem comes from overcoming those challenges and recognizing that even when you don't win you did the best you could.

Coaching Point
While it would be nice if everything went perfectly all the time, life isn't like that.  Software development is even worse - I remember actually experiencing fear when a program compiled the first time without an error!  We learn much more from our mistakes than our successes, and constant learning is essential to delivering the right software at the right time with the right level of quality.

So, if constant learning is essential and we learn more from making mistakes, shouldn't we make mistakes all the time?  Well, yes... sort of.  Big mistakes that aren't visible or acknowledged for a long time aren't good.  Very small mistakes that are caught very quickly and communicated with the team are OK, though, and are a fundamental part of learning.

Small mistakes are small User Stories built to the Product Owner's satisfaction that receive feedback during a demo that means a Story will need to be changed.  Small mistakes can be automated tests that fail because we haven't written the code yet to make them pass!  Small mistakes can be assumptions made about how to approach the development of a certain task that, while programming, are exposed as flawed.  Small mistakes are spikes that are used to determine if a certain technology or approach can even be used to build the software.  Small mistakes allow us to learn without really bad consequences... as long as we learn from them, of course!  Small mistakes are the nesting ground of innovation!

Teams must be empowered to make a constant stream of small mistakes!  They have to feel that it's safe to make a mistake or two without fearing for their reputations or even their jobs.  That's the only effective way that we currently know of for delivering good software without a huge overhead cost, and to deliver truly innovative solutions.

We have salary caps, we can't trade players at will and for the most part we can't tweak the settings of the software development "game" to make it easy.  So, we have a lose a few games along the way in order to learn and thus to be truly successful!

It's Quiet... Too Quiet

Kids make noise.  It's that simple.  They talk, they yell, they bang and crash.  Their toys rattle and buzz and play music.  Put multiple kids together and the noise level increases with the square of the number of children.*

This is just a simple fact of life, and as long as the noise doesn't indicate injury or imminent doom it's also a good thing.  You see, when young children suddenly become quiet then all sorts of nefarious things can be occurring.  Little Johnny, who only learned to walk last week, could be silently climbing the dining room cabinets or applying Mom's makeup to the dog.  Yes, children who are doing something they aren't supposed to be doing are as silent as a Ninja, moving rapidly seemingly without even touching the ground.

So, noise is good - noise is safe!

* Sorry no hard data to back that up, but go to a birthday party with 8 kids of any age from 1-21 and then dispute my assertion! :)

Coaching Point

When working with teams new to Agile, a common concern I hear is that moving to an open "team room" will reduce productivity because of the noise.  People won't be able to concentrate because all of their co-workers will be talking about last night's episode of [insert TV show here], or have death metal screaming away from their speakers.  My experience just doesn't support those concerns.

While the transition may involve some discomfort as people become used to working away from the confines of a tiny cubicle, the benefits of having a team in very close proximity are clear and proven.  The principles of the Agile Manifesto are clear about this:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Face to face conversations are very high bandwidth communication channels.  Think of them as 10GB Ethernet right to the back of your computer.  Not only is the content of the conversation being passed, but the tone of voice and body language of the people involved factors into the communication.

If you move that conversation to a video chat, you're still doing OK - perhaps a 100MB connection - but some of the intimacy is lost as senses such as touch and smell are removed from the equation.  Move that conversation to a phone call, and you're down to a DSL connection since the visual aspect is lost and for all you know the other person is making faces at you while you speak. :)

If that conversation moves further to e-mail, you now have a 56K modem because not only are all of the physical aspects of the conversation now lost, but the conversation has lost a time element as well.  E-mails are asynchronous - if you send me a message, I don't have to respond to it immediately.  An e-mail, being written text, can also easily be misunderstood - how many times have you been in trouble because you forgot to put a smiley in a message? :)

Finally, using a written document to communicate is the equivalent of the old "phone in the cups" acoustic coupler 300-baud modem.  For those of you not old enough to know what I mean, here's a picture:

As a communication medium, a written document is simply awful.

So, we've made the case for face to face conversations, but can't we have those in a cube farm just as effectively as in an open team area?  Well, no, we can't.  The simple walls of cubes create barriers to communication, even if someone is only a few cubes away.  An open workspace without internal walls encourages communication.  Indeed, the entire cubicle concept originated at Herman Miller in the late 60's as a way to make the effective "bullpen" work area concept more comfortable.  As we all know, it was subsequently bastardized into the Dilbert-esque cube farms in order to cram more people into the same amount of floor space as a cost-saving measure.

An open workspace where the team members can see and hear each other fosters face to face communication because the probability of communication is much higher.  MIT professor Thomas Allen studied this in the late 70's and his results showed that the probability of face to face communication decreases rapidly with distance.  This is known as the Allen Curve, and I've personally witnessed its effect over distances of only 4-6 metres:

So, if you have a teams of 7 +-2 people working in open workspaces all communicating face to face, isn't there going to be a lot of noise?  Well, to an extent, yes.  This isn't a crowded pub - everyone can't be yelling!  What you should hear, though, is a 'buzz' on the floor.  There should be constant conversations going on that aren't loud enough for everyone to hear, but effective for the people involved.  Team members have to be respectful of others, and I've found that simple tools such as foam bricks and Nerf weaponry are very effective at enforcing that point. :)

In the end, a workplace with a buzz on the floor signifies a healthy workplace.  After all, silence indicates trouble.  Noise is good - noise is safe!

Have Some Compassion, Stupid!

My daughter went through a phase where she didn't want to go to school. There were also a couple of occasions where she woke up in the morning with a slight fever, only to have it disappear completely with a single dose of acetaminophen, thus giving her a free day at home. One day when she woke up with one of these fevers, I decided that I had had enough. It's Children's Tylenol for you, my dear, then off to school! After all, I'm a very important person, and I must get to work.

I fully expected that by the time she came downstairs for breakfast, there would be no problem at all. However, she dragged herself across the kitchen and sat down to a bowl of Fruit Loops with her head barely held above the table. My daughter has a flair for the dramatic, so I paid little attention. After several spoonfuls of cereal, she proceeded to barf on the table.

My first thought was, "Well played... can’t argue with barf!" My second thought was more about what a putz I was to ignore that she wasn't feeling well, and focusing on my own perceived importance. I stayed home with her while she felt rotten most of the day, and strangely the world kept turning without me.

Coaching Point 
The team you're coaching is probably quite new to Agile. In most of the cases I've encountered, that means that their whole world has been turned upside down. Suddenly they're in a team room or area rather than having private cubes. They have to talk about their status every day where before they could go a week or two without having to tell the world that they were stuck on a problem. Testers have been thrust onto a team with, ewww, developers! Developers have those evil, cunning and devious testers sitting right beside them! They have an annoying Coach who is telling them that their code is crappy and they need to rewrite it in little tiny steps! They are no longer using sophisticated tools for requirements gathering and planning, but instead using index cards and markers! Where they once had months before they needed to show progress, they now have days... and they have to demonstrate what they have completed to the people who have comfy chairs!

It's no wonder that people resist the change to Agile.

At some point you need to know when the team needs a bit of a break. They aren't faking in order to get out of school, they do indeed need a "sick day". Work with the team's management to organize some team building event that takes 1/2 to 1 day. Make it fun, although there are as many definitions of that word as there are people on the planet. It doesn't have to have a particular purpose beyond just blowing off some steam. The time lost by having the sick day will be more than made up by a refreshed team, and likely one that has bonded a little more in that time.

If you can't organize a larger event that brings the team to fun, try bringing fun to the team.  I often purchase toys for teams such as Nerf weaponry.  I do so under the guise of allowing teams to control external noise (self-organization at its playful best!), but it serves to lighten the mood among the team members.

This notion of bringing play into the workplace may seem foreign.  After all work is for work, and we're not supposed to have fun on company time!  However, as Stuart Brown so eloquently says in his landmark book Play,

The opposite of Play isn't work, it's depression.

I've seen depressed work environments and the negative effects that they have on productivity.  Introducing some lighthearted play can help immensely.

Dirty Laundry

When I was 12, I wasn't very good at cleaning up my room. It wasn't dirty, per se, but had piles of clothes everywhere. My Mom griped and complained about having to "wade" into the room in order to get the laundry. I assured her it was safe, but did caution that she shouldn't show fear - the dirty socks could sense that. She finally gave up, and said that I must take the laundry to the basement myself, which I did.

One day, there was a particular shirt that I just had to wear to school. No other shirt was acceptable. I couldn't find it in my room, and the dirty socks assured me they hadn't seen it. I went downstairs to the laundry room, and there was the shirt, sitting on top of a pile of clothes that had yet to be cleaned. I was furious. What sort of place was this, where you couldn't get clothes cleaned when you needed them?! I was ready to go give Mom a piece of my mind, when a sudden wave of lucidity overcame me. In that brief moment, the potential outcomes of telling Mom that she had been derelict in her duties were clear, and none of them were particularly pleasant.

I decided to use a different strategy - do the laundry myself! There were these interesting symbols on the tags of my clothes, and I had noticed that the washer had a legend for those symbols on the inside of the lid. The instructions on the washer also mentioned something about washing like colours together. So, I tried washing the clothes. It didn't hurt a bit. Neither did drying them.

It was a liberating feeling... I was suddenly no longer dependent on Mom's schedule! I could wash my clothes at will! I did learn that you don't mix a new red shirt with white underwear, or at least you don't wear the resulting pink underwear on a day when you have gym class. Painful clarity does make for easy learning!

Years later when I went to university and lived in an all-male dorm in my freshman year, I was suddenly the person that the other guys asked about how to do their laundry. I helped prevent several pink underwear incidents, sparing floormates the same potential embarrassment I had endured!

Coaching Point 
At some point, you have to instil independence in the team you're coaching. As a coach, you really are trying to work yourself out of a job with each team you encounter. Like your children, you want them to mature, become independent and do their own bloody laundry!

Technical Debt in a code base is a prime example of dirty laundry.  If you don't keep the code clean by refactoring constantly and writing automated tests as a safety net to enable that refactoring, the team will find itself paralyzed by the fear of breaking something.  Like those dirty socks, debt-ridden code can sense fear and will break in seemingly random places in order to perpetuate that fear further.

Leaving that code to a maintenance or sustaining team is the same as me waiting for my Mom to call in a HazMat team to remove the dirty laundry from my room.  She didn’t know my ‘schedule’ any more than a separate team knows that the team you’re coaching has to make changes in that crappy code that will break what the maintenance team is doing.

The problem, though, is that you can't clean up the mess yourself because you're only the coach.  You have a team that's fully capable of doing its own laundry given a little guidance.  You need to provide the equivalent of the tags on the clothes and the instructions for what colours should go with what.  This comes in the form of Code Smells to identify what's wrong, and Refactorings to clean it up.

There are other Agile technical practices that help keep your laundry clean, ironed and folded at all times.

Continuous Integration
It’s important to remember that continuous integration means, well, to integrate continuously.  It doesn’t mean a build server or the software to perform automatic builds, although those tools do aid in the continuous integration process.

When you have a team of people working together on some software, there are going to be times when they need to work on the same areas of the code.  Resolving conflicts between the changes created by multiple developers can be a royal pain and my general advice when something is painful is to do it as often as possible!  No, I’m not a masochist, but rather I prefer small instances of pain that fall below the "I never want to do this again" threshold.

If integrating code after the developers have worked for a week or two in their own personal branch (more on that later) takes one or more days and results in many conflicts and errors, why not integrate once per day?  There won’t be as many conflicts, because no individual developer will have created or changed that much code.  If that works well, why not integrate twice per day?  Why not once or twice per hour?

To achieve this, the team needs a very fast build and very fast microtests that allow each individual developer (or pair) to use the following process each time they want to integrate:

1. Update the code from source control
2. Build
3. If the build is successful, execute all microtests
4. If the tests pass, commit the changes to source control

This process allows everyone to use the latest code from all developers all the time.  It virtually eliminates merge conflicts, and those that do exist are minor at worst.  It also ensures that the system is building properly, and the tests ensure that the build is clean.

This process also eliminates the need for developers to have their own personal branches of the code, and even can lead to the elimination of feature branches.  Every developer is working from Trunk, or the main branch of the code.  You may need to maintain some branches after a release to support previous versions of the system, but the need for separate development branches all but disappears.

Test-Driven Development (TDD)
This is almost the equivalent of doing your laundry before you wear the clothes, but that's the great thing about analogies - they don't have to perfectly reflect reality!  That said, imagine if you had a tiny little washer, dryer and iron combination that had capacity to wash a single outfit - shirt, pants, socks and underwear - and could do it in just a few minutes.  You just tossed that outfit into this little machine, and out came your clothes cleaned and pressed and ready to wear again.  Would you be more likely to do your laundry more often?

The Lean community has plenty of data regarding the goodness of small batches of work, and software testing certainly follows that rule.  TDD takes small batch processing to the extreme - one failing test, just enough code to make it past.  Rinse and repeat.

TDD also makes code simpler, more focused on the task at hand and, by definition, more testable.  It takes some time to learn, or more correctly to unlearn previous habits, but the benefits are enormous compared to the cost of learning it.

Collective Ownership
Why do everyone else's laundry by yourself?  If the whole family pitches in, then the effort of doing the laundry is smaller.  Ensure that everyone on the team is responsible for all parts of the code.  Islands of knowledge create potential bottlenecks and significant risks - what if the only team member who knows the most important widget in the system leaves for another job?

As a coach, your role is to help the teams with whom you work learn to do their own laundry.  You can show them how to identify Code Smells, clean them up with Refactoring, Integrate their work Continuously, write code Test-First and to Collectively Own the code in the system, but you need to ensure that you aren't doing it for them.  Using analogies like "Doing the Laundry" can be quite helpful.  Essentially, your role becomes teaching the team how to read the funny symbols on the tags, and how to separate colours from whites in order to avoid, um, pink underwear incidents. :)

Slow Down that Swing!

My Dad was the stereotypical golf fanatic. I like golf, but Dad loved it. Over the years, we shared a good amount of time on the golf course, and I loved every minute of it... except perhaps those rare occasions where the ball didn't go where I wanted. Yes, that was frustrating (and actually not very rare at all), but the rest was pure gold!

Dad gave me lots of pointers about various aspects of the game that I use to this day. By far the best was after I strutted up to the 1st tee one day, determined to show Dad just how bloody far I could hit that ball. Yes sir, that poor dimpled piece of plastic & rubber would rue the day it was made! I know what you're thinking... I swung and missed the ball completely. Well that's absolutely not true. The ball travelled at least 20 yards, and plopped into a creek.

Dad & I are a lot alike, temper included. Knowing this, he thankfully didn't laugh out loud. He did say, though, that I should try again, except this time just take a nice easy swing. I hit the ball about 175 yards (which was good at that age) right down the middle of the fairway.

Years later, when I would go to a driving range I would invariably take a couple of rips with the driver. They would either dribble ahead 20 yards or would hook or slice horribly. Perhaps 1 in 20 would go straight.  I would then follow Dad's advice and just take a smooth, rhythmic swing. In those cases, probably 15 out of 20 would go straight down the middle about 200-210 yards.

In the end, slowing down that swing in order to take consistency over raw performance improved my score dramatically.  But damn it was cool when I absolutely crushed the ball that one time out of 20! :)

Coaching Point
In my experience, software teams are obsessed with going fast. Technology has certainly obliged, making it much easier than ever before to quickly throw together unmanageable piles of crap. Teams and even whole organizations are constantly trying to "grip it and rip it" to get that 350 yard drive that impresses the gallery. The problem is that they may actually pull this off... 1 time in 20. The other 19 times the teams are just trying desperately to get their ball back on the fairway, let alone on the green.

Golf analogies aside, you need to help teams understand that going fast isn't necessarily that good. Velocity is important, but remember that it's a vector consisting of both speed and direction. You may be going very fast, but completely the wrong way!

Teams will initially have difficulty with the concept of the Done State, i.e. getting their work (Stories, Minimal Marketable Features, etc.) completed to a point where it could be released upon an unsuspecting public. They will feel like they've slowed down, and in some ways they have. This perception of slowing down is quite disconcerting, and you need to ensure that the team, their management, stakeholders and possibly even customers know that they are slowing down in order to go fast. Pushing quality practices to the beginning of a development cycle and maintaining those practices throughout will allow the team to deliver more functionality at a much higher level of quality, and in turn move much faster in the long run.

Update - July 2011
I took my son golfing for the first time today.  He spent a good portion of the 1st hole trying to hit the ball as hard as he could.  On the 2nd tee, I talked him through relaxing and just taking a "smooth, rhythmic swing".  He hit the ball 150-160 yards dead straight down the middle of the fairway.

I guess some advice is timeless.

Oh, and I hit a great drive about 240 yards down the middle, just like my Dad did 30-some years ago after giving me the same advice. :)

You're Not That Special!

I'm the 4th of 5 kids, and thus had 3 siblings precede me through teenagehood. I was actually pretty good to my parents during those years, although I did have one party when I was in my first year of high school. My parents went away overnight, and my younger sister stayed at my Grandparents' home. I had the place to myself, so naturally I wanted to have a party! So, I did.

Sorry to disappoint you, but this isn't a case where 300 people showed up, totally destroyed the home and I made the local, regional and even national news. There were about 15-20 people who came, and if there was any drinking it was done outside. Nothing was broken, no police were called, and as I recall we all had fun.

I cleaned up the house the next day, thinking that I had completely eradicated all evidence of the party. When Mom & Dad came home late in the afternoon, Mom went through the living room, into the kitchen and then asked me how the party went. I was shocked! How could she have known?!

Well, I'm the 4th of 5 kids and thus had 3 siblings precede me through teenagehood! She did compliment me on the cleaning job, though.

Coaching Point 
Every organization I've worked with in my career, even before this whole Agile thing, believed they were special. They were different from everyone else. In a sense that's quite true - each organization has different people, therefore they are different. However, from a software delivery process perspective they really aren't.

I'm willing to concede that there are two fundamental types of software organization - software product companies, and internal IT or software development groups. The former is in the business of developing software products, or their software is part of a larger system. In the latter, the focus of the organization is not the delivery of software - the software supports the core functions of the business. Beyond that, though, I have witnessed striking similarities in organizations in both the public and private sectors, small and large.

So, when you're told that a team can't possibly do Continuous Integration because of their company's policy for committing to source control, ask why they think that their company is different. If they tell you that they have to create a high-level design that must be submitted to and approved by an architecture group, ask why they think their company is different. If they tell you that they can't possibly ship a meaningful increment of software every few months, ask why they think their company is different.

You will hear a myriad of reasons. Almost none of them are valid. Organizations of similar size and function have been doing these things since long before the term Agile was coined. Even more are doing it now.

The people are special. How those people deliver software is not.

Ch-ch-ch-ch-changes!

When he was a toddler, my son had difficulty with transitions. He wanted to keep doing whatever he was doing, and didn't want to stop. Transitions would generally result in crying and general bad feelings all around.

Two things helped this problem considerably. First, I happened to have a timer on my digital watch. I started using the timer, saying to my son, "OK, 5 minutes until we have to go." When the timer beeped, he would happily stop what he was doing and would move on without any fuss whatsoever. The second way this was helped was after reading about children who have transition issues. A common strategy to help is to tell them what's going on and when. For example, "We're going to swimming lessons, then to the grocery store, to Home Depot, and then home."

Through dumb luck and research, the meltdowns essentially stopped. To this day, over a decade later, my son asks what's "on our agenda" when we go out.

Coaching Point

We use timeboxes quite a bit in Agile. Timely feedback is one excellent reason for doing so. Another reason is to provide some consistency and rhythm to the process. When the timer beeps, we move on. The meeting ends. The iteration is complete. We ship the software built in that release. Everyone knows this rhythm and abides by it.

Timeboxes also provide focus to our work. A quirk of human nature is that our work will expand to fill a vacuum, i.e. if we're given six months to complete something, we'll find a way for it to take six months! This is known as Parkinson's Law. If we create horizons of 1-3 weeks for intermediate checkpoints and 2-4 months for releases, we must find a way to focus our work in order to deliver business value over those time-frames.

Short timeboxes also force us to break work down into small enough chunks that they can be delivered within the length of the timebox. This functions as a great way to avoid, or at least decompose, complexity in a system.

The Product Owner creates a prioritized backlog of work to be completed and a release plan showing what we think is going to be the work for the next while. That "agenda" can change, but those changes usually involve all team members, and are certainly communicated to them. What the team will be working on is crystal clear. It can change, but not without consulting the team. This prioritization process is itself another benefit driven by timeboxing – in order to work on the most important features first, the stakeholders must really think about what “important” means to them.

So, timeboxes work to direct our behaviour in a way that allows us to focus our work into a comfortable rhythm. Timeboxes help to avoid the stress caused by larger transitions through this predictable rhythm, and create a sustainable pace for all involved in delivering a product.

Oh, and don't tell my son that when I said I set my timer for 5 minutes, quite often it was actually 2 or 3.

Building Forts

When I was young, our groceries were delivered in cardboard boxes, which provided a near endless supply of construction materials for the elaborate fortresses I created in our crawlspace. I even tried multi-storey forts once, but that was probably the first indication that I was not destined for a career in civil or mechanical engineering.

Fast forward some 35 years, and we moved into a new home. That move created an ample supply of empty boxes, so the first thing the Kids did was to start building a fort in the basement. The Kids actually grabbed surplus carpet and hardwood and decked out they're fort quite nicely. As a one-time fort-building aficionado, I was very impressed!

It would seem that we humans have an instinct for creating our own isolated private spaces. Give a kid a couple of large boxes, and he'll instantly start creating forts with them. Heck, the boxes don't even need to be that large!

Coaching Point

Cubicles suck. There, I said it. While we may have an instinct to create them as our own little forts, they hinder and even block the type of collaboration required to deliver software and systems effectively.

Face to face conversation is by far the most effective way to communicate. Think of it in terms of network bandwidth:

Form of Communication	Equivalent Bandwidth
Face to Face	This is a full OC-192 optical connection to the back of your laptop.
Video Conference	We're now down to a good Cable or DSL connection.
Phone Call	At best a 56K modem, with error correction at least.
E-mail	Remember 14.4K modems?
Written Document	Now we're back to a 300 baud teletype machine.

The point here is that you want to maximize the amount of time the team spends collaborating face to face. That type of communication not only 'transmits' the words of the conversation, but also the inflection in those words and the sentences they comprise. Body language is quite evident during the conversation. There is a lot more content communicated than just the words themselves, and thus the level of understanding created by face-to-face conversations is much higher.

Get team members into a team room or area. If they are on different floors in a building, they may as well be on different continents. You want to maximize the probability of face-to-face conversations occurring - putting everyone in a single space does just that.

What's that? You have people in the euphemistically-named 'low-cost centres'? You have people that work from home, and a company policy to support that? In those situations, ensure that the remote people spend at least some time in person with the rest of the team. That length of time must be enough to develop a working relationship, generally around 2-3 weeks. If full-time co-location isn't an option, the human relationship is the next most powerful aspect of collaboration.

The Picky Eater

My daughter is, um, picky when it comes to eating. There doesn't seem to be any specific pattern to what she will and won't eat, except perhaps with colour - her food must be as beige as possible. Of course, candy and chocolate are completely exempt from exclusion from her diet.

In the end, we try to ensure that our children eat a balanced diet so that they'll be healthy. We care about them, of course, and sometimes need to be rather firm about getting them to eat good foods. If we just allowed them to eat what they wanted, broccoli and spinach would likely become extinct within a generation, and I'd be rich owing to my massive investment in the stock of companies that make chocolate products.

Coaching Point

Agile Software Development isn't easy. It's quite common for teams to pick and choose the practices that they want to use. It's not unusual for them to choose the chocolate over the broccoli. Why would developers used to testing their code after it has been written use Test-Driven Development? Why would they even want to write microtests in the first place? Why would people used to their own private cubicles move to a team room where, gasp, they have to work with other people? Why would development teams used to receiving requirements over one wall and throwing their software over another actually start to collaborate with the people on each side?

The practices that come from Scrum and XP are there for a reason - they provide value on their own, but together they support one another in such a way that the whole is greater than the sum of the parts. Just like having your child eat a balanced diet, you have to ensure that your team isn't picking and choosing only the practices they want to use. If your child ate nothing but candy, they would get sick. If your team only uses the 'easy' practices, or what they perceive to be easy practices, they will see only limited benefits. They may even believe that Agile doesn't work for them.

Of course, all of that's easy for me to say - I like both broccoli and spinach!

Learn by example... your own!

I remember when I was 4 years old and was running around on the sidewalk with my hands in my pockets (don't ask why — that I don't remember!). My Mom said, "Stop running with your hands in your pockets. You'll fall and hit your head." I didn't stop, and sure enough within a minute I fell and smacked my head on the sidewalk. Now, Mom could have actively grabbed me and pulled my hands out of my pockets preventing the accident altogether, but her parenting philosophy was (and still is over 40 years later) that we would learn better from our own experiences - our own falls - than we would through pronouncements from her.

Despite what many who have met me may think, there was no lasting damage from my fall - just a scrape and resulting scab square in the middle of my forehead. Every day for the next couple of weeks when I looked in the mirror I had that scab to remind me that I shouldn't ignore my Mom's wisdom.

This philosophy repeated itself constantly through my childhood - unless you're creating mortal danger for yourself or others, a bruise or scrape were much better learning tools than words alone.

Coaching Point
You can bleat about Agile practices all you want, but there's no substitute for the team learning on their own.  I've encountered numerous teams that will do the equivalent of running down the sidewalk with their hands in the pockets:

• Long Releases
• Long Iterations
• Team members that aren't co-located
• Teams that are dispersed
• Teams that are not cross-functional
• Manual-only testing

All of these issues will degrade a team's long-term (and often their short-term) performance.  However, they don't represent issues that will truly stop a team in their tracks.

Mortal Danger
There are some parts of Agile, though, that if they aren't present or performed fall into the category of "mortal danger to yourself or others":

• Executive Support from both Business and IT management
• Product Owner Involvement, Ideally Daily
• A Backlog of work written and prioritized by the Product Owner
• Estimates performed by the people who will be doing the work
• Work in an Iteration built to "Done, Done" state
• Reflection upon the team's work via Retrospectives

This subset represents the "must haves" for any chance of success. All other practices are optional or negotiable to some extent. If a team doesn't want to adopt them, warn them of the risks and then stand back. During the Retrospectives, listen to what the team says needs improvement. Seek ways of using the practices that haven't been adopted to implement those improvements.

You don't always have to wait for a Retrospective to point out where Agile practices can help. If the team is doing the equivalent of me running with my hands in my pockets, for example not having an automated build, let them fall on their face. Someone will eventually forget to check in something new, or will check in code that breaks everyone else. When the pain of omitting the practice is right there for the team to feel, suggest adding the practice and offer any and all help. If the team still refuses, point out that they have a scab on their forehead. If they ask what that means, tell them to ask me.

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.

Learning to Crawl

My son was quite a large baby, and grew quickly after he was born. He was quite strong, holding his head up early, rolling over early, and attempting to wear out his Jolly Jumper a good month before he was supposed to be doing that sort of thing. Of course I was justifiably proud, being the father of an overachiever!

When he got to about 6 months, though, he showed no interest in crawling. He had no trouble rolling onto his stomach and getting up on his arms, but he didn't seem to be compelled to actually go anywhere. Apparently he knew that he had people for that whole movement thing.

One day he and I were playing with some blocks. I would make a tower, and my son delighted in knocking it down. I mean he really liked knocking my creations down!

So, I built another tower destined for destruction but I built it just out of his reach. My son was not pleased. He didn't exactly cry, and I'm not fluent in 'baby', but I don't believe that what he said is repeatable in mixed company.

What he also did was move himself, trying to reach the tower. At first he pushed too much with his arms and went backwards, initiating another stream of baby talk profanity. He persisted, though, and within a few minutes wailed away upon my tower, reducing it to a pile of BPA-free rubble. We continued this for a good 30 minutes, and my son was now fully mobile!!

Coaching Point
Don't be afraid to challenge teams by moving the tower on them. We don't often improve ourselves spontaneously - there must be some stimulus to get us moving.

For example, teams new to Agile are often quite wary of any iteration length shorter than 6 months! If a team starts initially with 3 week iterations, challenge them at some point to move to 2 weeks. Feedback is a critical aspect of Agile, and you want to maximize the frequency that it can be obtained. So, the shorter the iteration length, i.e. the opportunities for feedback, the better. When you propose this, you may encounter the equivalent of my son's griping that I put the tower out of reach. However the benefits of making them stretch, of making them ratchet up their intensity such that meaningful increments of value are delivered over a shorter period of time, are well worth the foul language. Any bottlenecks in the process that may have quietly existed in 3 week iterations will no longer be quiet at 2 weeks and will have to be addressed.

Another common area that teams could use the 'out of reach tower' concept is in automating their environment. Builds, testing and deployment are all areas where automation can be applied to simplify the work that the team must do. When someone tells you that something can't be automated, ask if they've tried. If not, ask why they believe it can't be automated. Challenge them to prove it by using a timeboxed experiment. It's quite likely that another team somewhere has encountered the same problem, so challenge the team to find out if there are any existing solutions out there. In short, challenge them!

A word of caution, though. After my son learned to crawl he immediately, and I do mean immediately, started exercising his new freedom by going places that he shouldn't (and I thought we had child-proofed the house!). The team still needs to deliver work that has been deemed valuable by the Product Owner, and thus they can't spend all their time working on these challenges. These types of technical items must be communicated so that the product owner is aware of them. They do provide indirect business value and should be done, but they may not be the top priority at the time. Another approach is to address these technical infrastructure items during Iteration 0.