12 October 2010

Fearless Learning

This year son joined the Robotics Club at his school. It runs first thing in the morning and the instructor encourages parents to attend, so I was able to make it this morning. I had an absolute blast watching the 12-14 year old kids working with their creations.

Since my son and his partner worked quite well together, there was no need for me to really do anything but observe and enjoy! I ended up being in full Agile Coach mode, and what I did observe was quite enlightening.

The instructor had laid out a track on the floor of the room using tape and, since today's session was focused on using the Mindstorm's ultrasonic sensors, some Lego brick walls. The goal was to program the robot to navigate the track, avoiding the walls.

What I thought was really cool was how the kids didn't try to program the entire track at once. They would try to do one thing, e.g. detect the first wall and stop, and then test that out on the track. If it failed, laughter ensued as a wall was bulldozed and the pair would try again using what they learned from the "failure". Once they got that one step working, they moved to the next. Rinse & repeat.

There were some key things I observed:
  1. NO FEAR OF FAILURE! Was that loud enough? Could you hear me at the back? These kids didn't have to get everything perfect from the start. They experimented, learning more each time and repeating until they got that step right.
  2. They worked incrementally and iteratively. Each step took one or more experiments, an iteration, and they built the whole program step by step, i.e. incrementally.
  3. They worked in pairs. I didn't get to spend much time observing the other teams, but my son and his partner were pair programming in every sense I know of. I was a proud Agile Dad! :)
  4. They delivered. By the end of the 1 hour session, my son & his partner had programmed their robot to complete the course.
So, what is there to learn here?

First and foremost, get over the notion that something has to be perfect right from the start. Experiment, fail, learn, succeed. For example, they had two possible ways of turning the robot and tried both to see which one worked better rather than debate which was the "better" way.

Second, avoid working alone. That's not always possible, but when you can work with someone else, do it! I learned about Pair Programming 10 years ago because I was actually doing it at the time. I still harp on teams to do it, and there is still push-back. Don't give me the introvert excuse, because introversion doesn't mean that you can't collaborate. In any sort of experimental or creative endeavour, multiple minds are greater than one. I saw that this morning with my son and his partner, and I see it all the time in software development when people actually take the time to pair.

Third, you have to actually deliver something. Kids in a Robotics Club is fun, but we're in the business of building software products. If you don't deliver, you go out of business. My son & his partner were able to get the job done despite the experimentation. Actually, I'd argue that they got the job done because of the experimentation, since they incorporated what they learned from their experiments back into their next iteration of work.

So, this makes me wonder when many of us become afraid to fail. I would imagine that it's a slow, incremental process, i.e. there is no single event or situation that you could point to. The best people I know and have worked with experiment constantly. Why do so many of us fall into the "Plan the work and work the plan" trap? Is this a personality issue? Are some people preconditioned to experiment, while others are preconditioned to avoid experimentation? I would also imagine that corporate culture factors into the equation. Would a public sector or very large private sector organization foster creativity through experimentation? Would a company that has downsized repeatedly since the dot-com boom reward people who fail in the small and learn?

Based on what I saw today, the corporate world could learn a lot from kids. Experiment without fear, learn, improve, deliver. Simple as that.

Oh, and when my son & his partner finished programming the robot to navigate the initial course laid out, the instructor added a 45 degree turn. The two boys made the fatal mistake of any programming activity... they said, "That's EASY!!" They never did get the robot to make the 45 degree turn! :)

11 October 2010

A Survival Guide for New Agile Coaches - Ch-ch-ch-ch-changes!

When he was a toddler, my son had difficulty with transitions. He wanted to keep doing whatever he was doing, and didn't want to stop. Transitions would generally result in crying and general bad feelings all around.

Two things helped this problem considerably. First, I happened to have a timer on my digital watch. I started using the timer, saying to my son, "OK, 5 minutes until we have to go." When the timer beeped, he would happily stop what he was doing and would move on without any fuss whatsoever. The second way this was helped was after reading about children who have transition issues. A common strategy to help is to tell them what's going on and when. For example, "We're going to swimming lessons, then to the grocery store, to Home Depot, and then home."

Through dumb luck and research, the meltdowns essentially stopped. To this day, over a decade later, my son asks what's "on our agenda" when we go out.

Coaching Point

We use timeboxes quite a bit in Agile. Timely feedback is one excellent reason for doing so. Another reason is to provide some consistency and rhythm to the process. When the timer beeps, we move on. The meeting ends. The iteration is complete. We ship the software built in that release. Everyone knows this rhythm and abides by it.

Timeboxes also provide focus to our work. A quirk of human nature is that our work will expand to fill a vacuum, i.e. if we're given six months to complete something, we'll find a way for it to take six months! This is known as Parkinson's Law. If we create horizons of 1-3 weeks for intermediate checkpoints and 2-4 months for releases, we must find a way to focus our work in order to deliver business value over those time-frames.

Short timeboxes also force us to break work down into small enough chunks that they can be delivered within the length of the timebox. This functions as a great way to avoid, or at least decompose, complexity in a system.

The Product Owner creates a prioritized backlog of work to be completed and a release plan showing what we think is going to be the work for the next while. That "agenda" can change, but those changes usually involve all team members, and are certainly communicated to them. What the team will be working on is crystal clear. It can change, but not without consulting the team. This prioritization process is itself another benefit driven by timeboxing – in order to work on the most important features first, the stakeholders must really think about what “important” means to them.

So, timeboxes work to direct our behaviour in a way that allows us to focus our work into a comfortable rhythm. Timeboxes help to avoid the stress caused by larger transitions through this predictable rhythm, and create a sustainable pace for all involved in delivering a product.

Oh, and don't tell my son that when I said I set my timer for 5 minutes, quite often it was actually 2 or 3.

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.

27 August 2010

Necessary Friction

Agile the Agile 2010 conference, Mark Levison commented on Twitter how he felt that the Agile community was fragile. He believes that some of the current friction between the Kanban and Scrum communities and the people for and against certifications is bad, and current scorched earth activities are hurting Agile as a whole. I certainly agree that there is friction. There are indeed egos involved, mainly because this involves people, and when you have people you have to accept the good and not so good that comes with them.

If we look back at a time 10 years ago, in the summer of 2000, there were a number of "lightweight" software development methods in use, such as (in no particular order) Extreme Programming, Scrum, Adaptive Software Development, Crystal, DSDM, Feature Driven Development. Each of those methods had people who created it and "marketed" it, for lack of a better term. Each of those methods had, even in 2000, books written about them. Those books were written by people who were experts on the topic, and were (and in many cases still are) making money by selling their books and services for their particular method.

Let's face it - to be in the position of founding a software development method, write one or more books about it and to make a living selling consulting services for that method, you need to have a pretty healthy ego. You have to be pretty convinced that your particular process is better in some way from the other processes.

So, the lightweight method community was rather fractured at the time. Fortunately, all of the "owners" of these methods that a common goal - change the status quo of dysfunction that led directly to such things as Dilbert.

It was that common goal that brought 17 of those people together at Snowbird, Utah in February 2001. The result was the Agile Manifesto whose values and principles identified what was common among all of those development methods, and set the stage for the revolution we're seeing now almost 10 years later.

Would the manifesto have been published if there were no egos involved? If everyone agreed on a single process, would it have achieved what we are seeing now? I believe that the answer to both these questions is, "No". I believe that a certain amount of discord and friction is required to be able push a group of people to achieve the best result.

After all if we lived in a frictionless world, we wouldn't be able to stop a car safely. We wouldn't be able to walk, for that matter. Frictionless worlds only exist in physics classes (along with perfect vacuums).

So, to address Mark's concerns, I believe that some friction is necessary in order to further the Agile Software Development movement. It's easy to become complacent, especially when something is reasonably successful. New processes such as Kanban help to keep us from becoming too complacent. Are there egos involved? Are there people shaking the tree? Absolutely! If there weren't, new voices likely wouldn't be heard.

If there weren't some new voices shaking the tree 10 years ago, where would we be today?

18 August 2010

A Completely Unncessary Miracle

From USA Today:
A Boeing 737 operated by Colombian carrier Aires split apart in a crash-landing on a Caribbean island just after midnight this morning. And, in what local officials are calling a "miracle," only one person died in the accident.
A miracle indeed. One that was completely unnecessary. The pilots attempted to land the aircraft during a thunderstorm, likely encountering severe wind shear or a microburst just prior to landing. These phenonena are quite common in thunderstorms and have caused a number of accidents in the past. As a result, aircraft very rarely land while there is an active storm at an airport. There is no indication from the news reports that the pilots had to land immediately due to fuel concerns or any other reason, so the logical conclusion is that they had an affliction known as "get-there-itis". In other words, the pilots' desire to get the flight in on time made them cut corners with respect to safety.

Sound familiar?

How often do teams and organizations start to cut corners - come down with "get-there-itis" - when approaching the end of the mandated time for delivering a system? Who has seen that happen before? Let's see some hands. Yes, almost everyone has.

As the pilot-in-command of an aircraft it's your responsibility and no one else's to ensure that a flight is safe. In the case above, the pilot and first officer should be held accountable for continuing the flight into dangerous circumstances.

As a team member it's your responsibility to call out situations that are the equivalent of flying your project into a storm while landing. Thunderstorms are visible for many miles, and are almost completely avoidable, and so are most of the dysfunctions on software projects. Agile processes quite often make those problems visible long before they cause damage, but they're visible even when using traditional processes.

Let's stop relying on completely unnecessary miracles, and use common sense and good risk management to bring projects to successful completion.

16 August 2010

Agile 2010 - Lack of Technical Sessions

There has been some discussion and even minor ranting about the lack of technical content at Agile 2010 in Orlando:

Uncle Bob Martin:
Programmers started the agile movement to get closer to customers not project mangers.
And again:
< 10% of the talks at #agile2010 are about programming. Is programming really < 10% of Agile?

I had similar conversations with Mike Hill and Joshua Kerievsky. I suppose even my session, Confessions of a Flow Junkie, could be considered non-technical since I only touched on Automated Testing as something that promoted Flow and didn't delve into the details.

So, what's different? Why does this seem to be the case? I agree completely that we could certainly use a renewed focus on technical skills, and am quite interested in the announcement about XP Universe 2011 by Corey Haines. I can also say that I attended 4 technical sessions at the conference - one by Rebecca Wirfs-Brock, one by Arlo Belshee, one by Llewellyn Falco and Jason Kerney and one by Josh Kerievsky. Those were the least well-attended of all the sessions I went to, excepting one that was listed as 'Expert'. I remember thinking more than once,
"Wow - the people who need to be here, um, aren't."
My experience as a coach is that people are learning and using the management practices of Scrum reasonably well, but they're only scratching the surface of what they can do with the technical practices. I see plenty of development teams starting to use an automated build (and incorrectly calling it Continuous Integration), and that's a good thing. However, precious few are writing Microtests, Refactoring, using Simple Design, and truly using Continuous Integration.

In one of the closing keynotes by Ron Jeffries and Chet Hendrickson, highlighted this very point:
Scrum is so simple that if you actually did it, it has to work!
Exactly. The technical practices that became part of XP aren't as simple. They take time to learn and integrate, and thus they aren't as popular. Once you have integrated them, though, they are indeed easy.

I've been told many times now by both developers and managers that microtests take too long to write, but no one has told me how long it takes them to debug a problem. I have sat with developers looking over unnecessarily complex Java/C/C++/C# code, and was told that it wasn't their fault that the code was such a mess, and that they didn't have time to clean it up. I've literally been laughed at and told that a goal of 0 defects is a pipe-dream (with that exact term used).

I call bullshit.

We know how to write code that is for all intents and purposes defect free. We know how to adjust the structure of code over time to reduce technical debt and keep it flexible and understandable. We know how to do these things, but because they are more difficult to learn than a daily standup meeting, we don't do them.

I believe that's why the 4 technical sessions I attended didn't have the same size audience as the session on Scrum Metrics that, in my opinion, was bordering on the sale of snake oil. I believe that's why only 10% of the sessions in the conference were oriented towards the technical practices - the popular topics aren't in the technical realm. Does that mean there wasn't value in the other 90%? Hell no - my head is still spinning after Jeff Patton's excellent session, "Beyond Sprint 0: Using Collaborative Product Discovery to Plan Agile Projects".

The revival of XP Universe, the ascent of the Software Craftsmanship movement and the creation of groups such as the Agile Skills Network are all indications that we're once again acknowledging the elephant in the room that is the industry's horrendously poor track record with respect to low-level technical quality.

Considering civilization's current and growing dependence on software, that revival is occurring not a moment too soon.

15 August 2010

Agile 2010 Review

I'm still in Florida as I write this, enjoying a weekend with friends near Tampa to help wind down after the conference. I must say that the humidity on the Gulf coast is much lower than in Orlando!

For me personally, the conference was one of the first opportunities to meet a number of people I've "known" online for many years - Ron Jeffries, Chet Hendrickson, Diana Larsen, Dave Nicolette... and those were just the people I sat with at Bloody Stupid Johnson! :) Bob Martin, Esther Derby, Lisa Crispin, Janet Gregory, Jon Bach, Jeff Patton, Johanna Rothman, Mary Poppendieck, Alan Shalloway, Cory Foy, chzy, Mike Hill, Kay Johansen, Corey Haines, James Shore, Arlo Belshee... as well as new faces like fellow aviation freak Bob Schatz. Of course, it was also great getting back in touch with those I have met before!

Regardless of whether I had met someone in person or virtually before, it was fantastic and quite energizing to be around so many others who share my passion for making software better.

I attended sessions on every day of the conference, and there was only one that I would say didn't live up to my expectations, and another that had the makings of a great session but didn't draw the type of people who could have made it great.

I didn't partake in much of the extracurricular activities, but that's probably how I was able to attend sessions on every day. :) That said, one of the best chats I had all conference was with Bill Hanlon of Microsoft while waiting in line for Soarin' at Epcot after the party!

Another thing I noticed at the conference was the high Canadian Content (known as CanCon in Canuck broadcasting parlance). Everything from the company running the event to the band playing the party at Epcot at the end was Canadian! [Later found out from Gil Broza that the band were Canadian wannabe poseurs - closest to being a Canuck was the Irish bass player :( ] How do you spot the Canadian in the crowd? He's the one wearing the Dale Hawerchuk Winnipeg Jets t-shirt... or the Tragically Hip t-shirt... or the Barenaked Ladies t-shirt (was she Canadian?)... or offering up maple syrup for auction to raise money for charity. Maybe The Canadian Conspiracy and Canadian Bacon were warnings after all... :)

To me the common theme that emerged from both sessions and keynotes, especially that of Ron Jeffries and Chet Hendrickson, is that we need to stop making excuses for why software is still made with terrible quality, and get to changing how we work.

I was also encouraged by Mary Poppendieck and Dave West's talks where they mentioned that the software delivery people must become part of the business units they support in order to become more effective. I wrote about this before in Embedded Collaboration and Agile, circa 1988. What was different is that Mary spoke about Handelsbanken in Sweden, where they realized that it was much more customer-effective for each branch to have its own IT group as opposed to the cost-effective approach of centralizing IT services. Essentially, being cost-effective may work against the Lean principle of optimizing the system, and centralization of services becomes a local optimization! Long-term strategies of maximizing value for customers was more important than short-term (i.e. quarterly) maximization of shareholder value. Handelsbanken did this starting in 1970, and Amazon & Google continue it today. I've had an intuitive feeling that this was true, but nothing concrete on which to base that feeling. These points comprised the gold nugget from Mary's talk that will be immensely helpful for me moving forwards from the conference.

I was a first time presenter at this conference, and was somewhat nervous. I think it helped a bit that I didn't present until Thursday since I had a chance to see how others were doing it. In the end, I had a couple of attendees of Confessions of a Flow Junkie tell me that they had learned things that they could use as soon as they returned home. That was worth more than anything on an evaluation sheet!! So, I'm quite happy with the outcome of the session, and received some excellent feedback that I'll incorporate to make the session even better if I use it again.

So, many thanks to the conference organizers and volunteers and to everyone I met. I had a blast, and am already looking forward to Salt Lake City next year!

2 June 2010

Core Hours

When I worked with Industrial Logic back in 2006-2007, I was introduced to a hidden practice of Agile called Core Hours.

Many teams I've worked with over the years have had an agreement that all team members would be together for a certain portion of the day, possibly even working in the same physical area. This is good, but the Core Hours concept to which I was introduced takes the practice one step further.

During Core Hours, team members work on their primary project only from, for example, 9 am to 3 pm, with an hour for lunch. Yes, that’s only five hours per day. It’s also realistically how much people work in terms of actual time when you account for administrative tasks, dealing with family matters, working outside their main project, and so forth. We already know that multitasking is a fool’s errand, so why not allow people to focus for a set period of time in order to maximize their productivity? When you achieve that level of focus, you are in a a state of Flow according to Mihály Csíkszentmihályi. This state is also known as being in the zone or on fire.

Of course, there are always occasions where a critical production problem may have to be dealt with immediately. That’s fine, but there needs to be a mechanism to shield the team from as many disruptions as possible. Does a problem really need to be dealt with right this minute? Can it wait an hour or two until outside of core hours? This is where education of help desk people can have a tremendous impact. They need to be able to properly triage issues as they arrive, and not just pass them along to the development or maintenance teams. This means that they must be involved in some way during the development of any given system - another reminder that the project community is always larger than we think.

Adhering to core hours takes a little discipline initially. Often, there is pressure from managers to "increase the hours a little", but again the concept is a reflection of the reality of all the work that people actually do during the day. Management also has a role in making it acceptable for team members to say, "I can look at that in a couple of hours" when an issue presents itself and is not critical. While the business may not initially like the change from an immediate response, the rewards for doing so are enormous.

This practice should be self-policing within the team. For example, if someone is surfing during Core Hours, other team members can and should question it. The practice should is also representative of the self-organization aspect of Agile - managers don't impose the boundaries and length of Core Hours, that's up to the team.

Outside of Core Hours, team members are literally free to do whatever they want (within reason!). If they want to chat on Twitter or lose their privacy on Facebook, then have at it! This is also the time that people from outside the team can ask questions. This is when a team member can look into a non-critical problem. This is when team members can attend other meetings as necessary. This is when people deal with e-mail and other administrivia related to their job.

I'll be speaking more about Core Hours as part of my Confessions of a Flow Junkie talk at Agile 2010 in Orlando in August.

14 May 2010

Agile Then and Now

This past week the Agile Ottawa group hosted Craig Larman for a great session on Scaling Lean and Agile for Large, Multi-Site Teams. There was a great crowd of 60-70 people, and there would have been more if not for a late afternoon traffic problem that closed a major highway! Anyway, Craig said that he has spent the last few years coaching groups on how to scale up Agile to large organizations (of course only as a last resort after attempting to keep things small).

The interesting part of this talk was that it's now beyond obvious that Agile approaches are not only acceptable in large corporate environment, but they're becoming almost required as the business advantage of the approach is becoming clear. In short, Agile is indeed well into the mainstream of the technology adoption curve.

I've been involved in the Agile community for almost 10 years now, and it's quite heartening to see this level of adoption. But let's rewind to the halfway point of my Agile career, to May 2005.

Craig spoke to Agile Ottawa almost exactly 5 years ago, with an attendance of about 10 people. Craig's topic for the evening was Bloodletting. He equated the rate and depth of Agile adoption with the 150 years it took to finally abandon bloodletting as a medical practice. In that case, the proponents of bloodletting literally had to die off in order for the practice to be discontinued. I'm not sure if that's the case in software development, but certainly the sentiment is the same.

So, let's compare Craig's two Agile Ottawa sessions. In 2005 there was a small crowd and the talk was intended to educate us that the adoption of agile wasn't going to be easy (and indeed hadn't been to that point), and some people were never going to accept and would have to die off in the figurative sense. In 2010, Agile Ottawa had a record crowd to hear Craig speak about how to implement Agile in large and very large scale system development efforts. It was not longer 'if' it could be done, but 'how'.

There's still a long way to go, but the difference in the tone of the two sessions certainly highlighted to me that we're on the right path towards much more effective ways of delivering systems.

5 May 2010

A New Daily Standup Dysfunction

As an Agile Coach, I've attended a lot of daily Standup Meetings over the years. I've witnessed and dealt with all sorts of dysfunctions ranging from the usual delving into technical details to attendees mumbling about their work in barely audible tones.

Recently, though, I witnessed a standup meeting dysfunction that was completely new to me - a team member said his piece, waited a minute or so, and then walked away.

First, I was shocked that he did this, but I was even more shocked by the fact that not one other team member questioned his action. Other than the ScrumMaster, I don't think many people noticed. I suspect that the root cause of this problem is that the person in question feels that the Standup Meeting is simply for giving his status.

Providing your status is indeed one aspect of the Standup Meeting, but it is by no means the only reason why you attend. The Standup is intended as a daily synchronisation point for all team members, and I do extend that to include Product Owners. I tell teams I coach that while perhaps 80% of what's said in the Standup may not affect any one individual on the team, the other 20% is absolutely crucial to ensuring that every is working together. Hearing that someone has an impediment may trigger someone to say, "Oh, I had that problem before and fixed it by...". It may make clear the need for a conversation to take place.

Regardless, if you keep the Standup restricted to the 3 questions then it will move quite quickly and that 80% won't feel like much of a waste of time.

3 May 2010

What's in a Name

Several teams at a recent coaching client have been using some form of numbering scheme for their User Stories. There isn't a global standard, but the scheme is consistent within each team. In all of the cases, the teams are not using any sort of title for the stories, just the Story Number and the Description.

An interesting conversation occurred last week when discussing the tasks for a story. It went something like this (names changed to protect the guilty):
Bob: We already did something like this on Story 12a a few sprints back, didn't we?

Bill: I think so.

Brad: Uh, I don't even remember what Story 12a was.
The team finished Story 12a several sprints ago, and all information about it had been archived and wasn't visible on the team's wall.

But that isn't the issue here. The issue is simple communication. Obviously Bob remembered what Story 12a was, but others on the team did not. What if Story 12a had a meaningful title instead? What if that title conveyed just enough information to bring all the team members back to the same page?

A User Story has never been intended to be a comprehensive document of something that you need to do in a system. Alistair Cockburn said it best when he described a Story as "a promissory note to have a conversation", which highlights the critical aspect of stories - the conversation!

The intention of the title and text of a story is to provide enough context for everyone to know what they need to talk about. Throw in the acceptance criteria, and you have a shared understanding among all team members about what a story is intended to accomplish.

The further benefit to using titles is that it also provides context to people outside of the team. Anyone could walk into the team room and understand what "Search for Book by ISBN" means, as opposed to "Story 12a".

A numbering scheme may be fine for providing some indication of relationship between Stories, but it's sadly lacking in communication value. In the end, this whole Agile Software Development thing is about maximizing communication. So, let's do that with the User Stories as well.

More information on User Stories (including examples) is available on the Westboro Systems web site.

8 April 2010

Getting Dirty

Put simply, humans need to be dirty. We literally need to have bacteria on our skin in order to be healthy. All of the handwashing 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 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 will result.

3 April 2010

Responsibility... again

I have ranted about professionalism and personal responsibility in the software industry before. Recently I've been coaching teams that have run headlong into that brick wall known as Technical Debt, and in all of those cases the excuse was "we didn't have time to do it right".

Frankly, I'm tired of that excuse. Seriously. Uncle Bob Martin has talked about Just Saying No in that situation, and also in his seminal We Will Not Ship Shit article.

For all the complaining we do about airlines, the aviation industry in general does a very good job of instilling a sense of responsibility in pilots and aircrew, and the software industry could learn a lot from that. For every fatigued pilot issue, there are dozens of unreported "good" things that happen. Here is an example where 3 pilots and an air traffic controller all did the right thing - they ignored scheduling and cost pressures and did what was right for their passengers and overall safety:




The duty of the Pilot in Command, be it in an A380 or a two seat Cessna 150 is to maintain safe flight. That overrides all other considerations, even instructions from Air Traffic Control. In this situation, the pilots all chose to put safety first rather than taking a chance. It's quite likely that no one would have been hurt if the A380 continued its approach and landed. However, debris from the blown tire could have been ingested into an engine causing literally millions of dollars of damage.

The next time you're faced with "just getting it done", remember what those pilots did. Are you willing to take the risk that you will cause the equivalent of a blown engine? Or, does it make more sense to take your time, do it right, and all but eliminate that risk?

Considering the extent to which software directly affects our lives now, I want to make damned sure that developers opt for doing it right.

15 March 2010

Why Rewrites Fail

Last week on Twitter Kay Johansen asked, "Why do "rewrite" projects so often fail?" After all, rewriting an existing application should be easy, right? We are simply copying the business functionality, and not adding anything new. How could that possibly go wrong?

Actually, there are a number of reasons. The first one that I thought of came from the Standish Group's CHAOS reports, in which they say that some 45% of features in software are never used, and only 7% are always used. I can understand that some features of a commercial product may fall into the never used category - you may need to add a feature in order to stay even with a competitor - but I seriously doubt that those types of features account for 45%!

What that statistic does tell me is that there was precious little business involvement in the process of defining what features the software should have. Alternatively, the delivery cycles were so long that the business was tempted to cram in as many features as possible. Those two issues result in a lack of timely feedback that can be incorporated back into the software, and lead eventually to features that weren't really needed in the first place.

How does that lead to failure on a rewrite project? Well, if you blindly march into the process without re-engaging the business, you're potentially wasting 45% of time & money on features the business didn't really need in the first place!

Also, consider why a rewrite would be necessary. Was the software buggy? Was it not performing well? Was it so old that the hardware and platform software vendors didn't exist anymore? In the first two cases, the business people for whom the software was written likely weren't terribly happy with their system in the first place. As a result, they probably wouldn't want to devote a lot of time to the rewrite... "Just make it work this time!"

In the end, business involvement is exactly what is required when rewriting a system. I'm obviously biased towards Agile processes, but they force that involvement and are much more likely to deliver the system that the business needs at that time, rather than just what it did before. By focusing on the current business needs and providing constant feedback, there is much less risk of failure and a much higher chance that the delivered functionality will meet the business need.

Another factor that can feed into the causes of failure is the belief that the new system must be 100% complete before it can be released and replace the existing system. There may indeed be cases where this is a requirement, but there are likely as many or more cases where the business people could live with the duplication of effort for a certain period of time. At one client I had, a Lean Transformation in the business completely obviated the need for one rather large system - whiteboards and face-to-face communication had replaced the complex workflow that the system possessed and was no longer used. That system, however, was a "system of record" and data still needed to be entered for legal purposes. The business made a conscious decision to continue to use the system in as minimal a way as possible in order to satisfy the legal requirements. There was duplication of effort, but it was deemed worth it until a new system was in place (which will likely occur some 2-3 years after the manual methods were first used). Meanwhile, some simple automated tools were created to assist the teams working within their new process. All of this falls into Lean's principle of optimizing the whole rather than just certain aspects of a process. Completely replacing the existing system first would not have done so, and likely would have eliminated any benefits to replacing the older system. The replacement of that system is now taking place when the business understands their new process much better, and thus is much better positioned for success.

The real moral of this story is that a simple rewrite should be anything but. The business must be as engaged as they would during the development of a new system. The level of support from management needs to be the same. In the end, what is developed should be a new system supporting the current business processes, not what was in place when the system to be replaced was released!

7 March 2010

The Wrong Metaphor

This past week I read a post on the Cutter Consortium blog by Bob Benson entitled, "A Shift in the Notion of Portfolio Management Opens Opportunity for IT". Bob begins the post with,
For many years,Tom Bugnitz and I have been recommending that IT organizations think of themselves as a service business, with five fundamental service portfolios.

1. The Application Portfolio (e.g., providing the applications and support to business units)
2. The Project Portfolio
3. The Infrastructure Services Portfolio (e.g., e-mail, network attach, remote access)
4. The User Services Portfolio (e.g., help desk, PC repair)
5. The Management Services Portfolio (e.g., providing procurement, planning support to business units)
He goes on to describe how he's now seeing the boundaries between these service portfolios become blurred, with which I agree. What I don't agree with, though, is the suggestion that IT organizations much act like a service business, at least not for the part of IT that build applications for use by the business.

The problem is that the level of collaboration required for effective software development precludes the use of the Service-Consumer model. As I wrote in Embedded Collaboration in 2008,
There is no functional separation of business and IT on a project - they are living and working together, breathing the same air, meeting at the same water coolers.
The most obvious way to accomplish this is to have the software development people "go native" and physically sit with the business people for whom they are building software (I also wrote about this in Agile Circa 1988). Create product teams within each business unit whose sole reason for existence is to serve the software development needs for that unit. The business unit is responsible for establishing it's own software development budget, and for feeding the product team with a constantly groomed list of prioritized features that they require. There are some potential problems with that model, though.

First, it can create a local optimzation at the business unit level, i.e. the immediate software needs of that unit are being satisfied, but perhaps what is created could have been shared with the organization as a whole. To address this you would require some form of communication and collaboration between the software development groups of each business unit.

Second, once an application or business process crosses business unit boundaries, you're not in Kansas anymore - you can't simply "go native" across the whole organization. In that case, the discipline of product management become even more important, with the need for a more strategic view of the organization to be used to guide the team. That said, though, there is still no reason for the people who are building the applications to belong to an IT service organization - they should be part of a product team that includes close, frequent (ideally daily) participation from the business.

The third problem is that not all business units are created equal. It can be much more difficult for Human Resources to justify its own software development budget compared to a business unit that is directly creating revenue for the company (ironically, the first time I encountered Embedded Collaboration, it was in a Human Resources Systems group). To address this, you may need to have a product delivery group that spans multiple smaller business units. The key, though, is not to look at what a business unit either contributes to or takes away from the organization's bottom line, but rather at the impact of that unit on the business. Human Resources may be considered "overhead", but its impact on the business of any medium to large organization far outscales its size.

I do agree with Bob Benson that there is a blurring of the lines between the activities performed in IT groups now. However, I don't agree that the Service-Consumer model is appropriate for software development activities. I've met Bob, and have a lot of respect for his experience. However, I've seen that model when applied to software development create many more problems than it has solved. It has created artificial divisions that impeded true collaboration, and thus negatively impacted the delivery of software.

If you believe that the Service-Consumer model is appropriate, allow me to quote Dr. Phil,
How's that workin' for ya?

27 February 2010

Humility in Coaching

A recent blog post from the inimitable Mike "GeePaw" Hill reminded me of a fundamental value that I adhere to in my work. For my "day job" I coach teams that want to adopt Agile Software Development as their software or system delivery process. That coaching can range from the nuts & bolts of object-oriented software design & testing to group therapy for people in a dysfunctional organization! :)

What I've found over the years that I've been coaching, and what GeePaw put into words for me in his blog, is that a key success factor in coaching is to show those who you are coaching that you're as human as they are.

For example, a couple of weeks ago I was slated to do a Lunch & Learn at a client on Code Smells/Refactoring/Microtesting/TDD. I hunted around for smelly code in pen sources projects, but had a bitch of a time resolving dependencies, tc. I decided instead to start with some code of my own that had been built with tests and I thought was reasonably good. Well, when I opened that workspace in Eclipse, I felt like I had just stumbled across a dead porcupine in the woods that was stinking up the whole area. Tests weren't passing, and I saw obvious smells in the code.

I had built this code a couple of years ago for a local startup, and I had kept this code reasonably clean over time. What happened, though, was a change the folks at the startup needed after I wasn't really working with them anymore. This app interacted with Facebook, and the the API had changed substantially. I grabbed a new version of the Java API library and just slapped the changes in. The app worked and I moved on, leaving the smells in place.

So, I ended up using my own code for the Lunch & Learn. I could show not only several code smells that I had introduced, but also show the simplicity of code that had been built with tests (and a good portion using TDD). What I did in the session was to show them how to isolate dependencies in order to make the code easier to test. In this particular case, the new API used static method calls so I had to do some fancy footwork to be able to fake out the functionality such that I could get the tests to run properly again. All of this took about 10-15 minutes, and I was able to show the developers that it was relatively easy to make small changes to make the code more testable.

The fact that I could do this while making fun of myself in the process I believe made it easier to get the points across. It made me look like a regular developer, and not some pontificating arse who dwells in towers of ivory. As GeePaw says, the mistakes were acknowledged without justification or being excused, I laughed (and they did too) and we moved on.

There was a discussion recently (I forget where) about the attributes of a good coach. One point put forth was "empathy". I believe that empathy follows humility, and showing people that I'm human and can make the same mistakes allows not only empathy on my part but the people who I'm coaching to accept that empathy.

I would much rather coach from a position of:
Dude, I've been there. Let me show you some techniques I've learned to make things better.
than,
This is crap. You need to do these things to get yourself out of the hole you're in.
My experience is that the former is much, much more effective than the latter. What's your experience?

12 February 2010

On Pair Programming

Pair Programming has to be the single most controversial practice in Extreme Programming. I suppose that it flies in the face of the mythical "hacker", working heroically through a caffeine-fuelled night to deliver world-saving software in the nick of time.

I'm a strong advocate of pairing, which probably stems from the fact that I was actually pairing when I found out about the practice! Now, I could delve into the social aspects and quote Laurie Williams' research or even show that the US Air Force was using Pair Programming 35 years ago, but I won't.

Instead, I will point to the most compelling argument in favour of Pair Programming that I have seen in almost 10 years in the Agile world. This argument is provided by Corey Haines:


2 February 2010

Reconciling Forces

Jeff Parks, a local Information Architect and user experience consultant, passed along a link to a video he shot to be used to provide some context for a discussion he was having.

Well, that video is so damn good, I wanted to share it with you:

Seek First to Understand from Jeff Parks on Vimeo.

Key takeways:
  • Reconciling forces focus on the people, not the technology
  • Reconciliation leads to win-win situations, compromise leads to lose-lose
  • Reconciliation requires face to face conversations, which in turn requires social skills
Well done, Jeff!