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.