27 September 2010

A Survival Guide for New Agile Coaches - 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 CommunicationEquivalent Bandwidth
Face to FaceThis is a full OC-192 optical connection to the back of your laptop.
Video ConferenceWe're now down to a good Cable or DSL connection.
Phone CallAt best a 56K modem, with error correction at least.
E-mailRemember 14.4K modems?
Written DocumentNow 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.

20 September 2010

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

16 September 2010

A Survival Guide for New Agile Coaches - 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. There are some parts of Agile, though, that arguably 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
  • Small Releases
  • Short Iterations
  • User Stories in an Iteration built to "Done, Done" state
  • Reflection upon the team's work via Retrospectives
This subset of practices 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.

13 September 2010

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

12 September 2010

A Survival Guide for New Agile Coaches - Learning to Crawl

This blog entry is the first in a series for people who are new to Agile Coaching.

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.

10 September 2010

New Blog Series - A Survival Guide for New Agile Coaches

This series originally started as the kernel of a book idea, but I decided to release them as individual blog posts instead. The premise behind the posts is quite simple: "Everything I know as a coach I learned from my Parents and my Kids."

You know this Agile Software Development thing pretty well now. You've done it on a number of projects and have experienced the highs and fallen in the potholes. You've now moved on to a new group or company, and they want to "go Agile". Since you're the local expert, you've been volunteered to be the Coach. Congratulations, you're the dog who actually caught the car!

There are plenty of books out there about Agile Software Development in general, and some on Coaching in particular. The coaching books are good - I have them! These blog posts are different. They assume that you know Agile already, and won't delve into the minutiae of the principles and practices unless warranted by the example at hand.

These blog posts use the metaphor of our progression through the stages of life to provide a backdrop for a team's journey towards Agility, and your journey as a parent... er, I mean Coach. Anecdotes provide the context for a particular point, and concrete examples give you strategies for working through those situations, and even entire stages in a team's "life".

Life Stages
A team's progression during a transition to an Agile Software Development approach can be roughly equated to the following stages of a person's life:
  • Prenatal
  • Infancy
  • Toddler
  • Preschool
  • Elementary School
  • Adolescence
  • Teenage-hood
  • Young Adult
  • Maturity
It's not a perfect model, but that's the beauty of models - none of them are perfect. That's why they're only models! We're going to examine each of these stages through anecdotes and advice as a team progresses from their nascent beginnings to full maturity.

9 September 2010

Agile Backlash - Personalities

Elisabeth Hendickson recently posted an article on her blog discussing some of the latest backlash against Agile Software Development. She makes very good points, and the one about introverts dealing with extroverts tweaked me to some issues that I've been poking at over the last 10 years.
I suspect that some of these folks are introverts working with a whole passel of extroverts who took to the social nature of Agile like ducks to water. Introverts need time and space to process stuff internally. If they don’t get enough time to themselves during the workday, they burn out.
The Introvert/Extrovert point is interesting, and an area that I've explored over the years as well. I would like to say, though, that it isn't as simple as just introversion vs. extroversion.

I'm a card-carrying extrovert, and my full MBTI is ENFP. The interesting thing is that my combination of type indicators leads me to indeed be an extrovert, but I also need time on my own to integrate information. I'm energized by being in (and especially working with) groups while I'm there, but I do need to recharge later. I may seem impulsive, but that's generally because I've been thinking about a decision for a while already.

What I have found interesting in my decade in the 'agile world' is the over-representation of Intuitors (the 'N' in MBTI) that I've met. I did a poll on the XP list a number of years back, simply asking people their Myers-Briggs type. Only 7% of the respondents were Sensors ('S'), while 66-74% of the general population are S's. At one Agile 2010 session, I asked the question again and of around 10 attendees who knew their MBTI all were Intuitors.

I'm a computer geek and not a psychologist or sociologist (although as a coach I sometimes wonder...). I'm not qualified to draw any conclusions from very unscientific data such as this, but I do believe that where there's smoke there's fire.

When I first read about Extreme Programming in 2000 I distinctly remember thinking, "Yeah! That just feels right!" I didn't know it at the time, but that's the 'N' and 'P' in my ENFP doing their thing. I didn't need a stack of case studies or empirical data to tell me that Pair Programming was good - I just tried it. TDD sounded kind of weird, but when I and a colleague tried it, we were hooked almost immediately. We didn't need someone else to prove it for us, our gut feel said that the practices made sense and our own experimentation proved that.

I suspect, and have for a long time, that given the large majority of people who don't work by gut feel and intuition it's inevitable that there will be a backlash against practices that seem counterintuitive.

As Agile in whatever form you like moves into the early and late majority of Moore's adoption curve, it will encounter more and more of the majority of people who are Sensors. With that will come people who question the very foundation of some things that many of us have worked with for years. That will itself create friction, but it also represents an opportunity to further improve what we do now. If we can quantify why these practices are so good, we can likely also determine how to make them better.