4 February 2011

A Survival Guide for New Agile Coaches - 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.

3 February 2011

A Survival Guide for New Agile Coaches - 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. :)

2 February 2011

A Survival Guide for New Agile Coaches - 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. :)

1 February 2011

A Survival Guide for New Agile Coaches - 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.