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!

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!

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. :)