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'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!

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.