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.

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.

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!