Archive for September 2009

Building a Learning Culture on Agile Teams

I was thrilled to present at Agile 2009 on building a learning culture on agile teams. This post is a short summary of the presentation. You can view the presentation on slideshare. The image below is a mindmap of the presentation:

Building a Learning Culture Mindmap

The main point is that in order to embrace change:

We should strive not only to deliver value today but simultaneously increase our capacity to deliver value tomorrow.

Source: http://www.stevenmsmith.com/my-articles/article/the-satir-change-model.html

There are so many dimensions we can learn: our products, our customers, our domain, new technologies and so on in order to embrace change and deliver value. Now, embracing change is supported by learning and so we can consider change models for insights.  Even though the change model from Virginia Satir is modeled on dysfunctional families I believe the applicability to agile teams is sound. I often find the limiting factors in building high performance agile teams are the team members mental models and the team’s ability to work together effectively.


To build our capacity to embrace change and achieve ever higher levels of performance we need to build learning teams. This is one of the five disciplines that Peter Senge discusses in his classic text The Fifth Discipline. I find two main challenges that the five disciplines present to agile teams. First, much of the book applies to larger organizations than agile teams and second the book is short on practical tools to help learning teams. The supporting text,  The Fifth Discipline Fieldbook and other tools primarily from Agile Retrospectives and Fearless Change provide activities and simulations that you can use with agile teams.





Learning map

Now, I want to bridge the game from the principles of team learning to the practices by way of an agile learning map. I built a learning map based on on the Chinese symbol for learning. It provides four key areas that are necessary for building a safe learning culture:

  1. Intentional – Proactively plan and retrospect on learning activities
  2. Incremental – Focus on small incremental. progressive learning
  3. Infrastructure – Build a workspace structure that supports effective learning
  4. Individual Safety – Make sure people feel safe to learn

The presentation provides a more detailed map of activities and patterns you can use in each of the above areas.

Building the teams learning muscle is key to long-term agile success!

What I Learned Programming With the Stars

I had a great experience pairing with Patrick Wilson-Welsh at Programming with the Stars at Agile 2009 in Chicago. We were ousted in the first round but we had a blast. And I learned a few things along the way:

You should make your tests expressive

We were deducted points for not including the word “should” in our tests. I do strive for this but find that this “rule”, as with any rule, can be too restrictive. Liz Keough suggests that the word “should” should be the first word in your test method name. Getting tired of the word “should” yet?

I strive for expressive test method names that clearly state a design criteria for the class under test. So my preference is to make the test method name a full sentence. And of course I try to include the word “should” in it. Using this approach I find it hard to craft a test name beginning with the word “should” that reads like an assertion rather than a question. So, I rarely start my tests with the word “should”. Also, I break from production code styling and use underscores so that test method names are as readable as possible:

As Brian Marick would say, “an example would be good right about now”. So, if we have a test like this:

  1. @Test
  2. public void handleZero() {
  3.     assertEquals(0, Closest.closestToZero(new int[] {0,2,4}));
  4. }

Then a refactoring like shown below provides a more expressive test:

  1. @Test
  2. public void zero_should_be_closer_to_zero_than_any_other_integer() {
  3.     assertEquals(0, Closest.closestToZero(new int[] {0,2,4}));
  4. }

Don’t write new conditional production logic without a new failing test

Jim Newkirk deducted a point because we added an ‘if’ statement without a new failing test. This was new to me although it makes perfect sense and I appreciate the insight from Jim.

So, if you are about to write new conditional production code without a new failing test … stop! If you are currently trying to make an existing test pass then try to get it to pass without a conditional statement. Otherwise, update the test so that the new conditional logic is not required. Once you get green with this you should then write the failing test that will require the conditional logic you were about to add. Now, you can add the conditional logic sufficient to get the test green.

You can’t write much code in 3.5 minutes

Patrick and I were test-driving a method that would return the integer that was closest to zero in an input array. We knew from writing the initial code and refactoring it what a clean code implementation could look like. And, as if often the case, the refactored code looked obvious in hindsight. We decided that given the time restrictions we would write our initial code towards the refactored code as it reflected an intentional programming approach. Bad idea, we were deducted points for thinking too far ahead and then not having any significant refactoring.

So, if you are in this position, write some really, really simple code and allow time for simple refactoring … and let intentional programming code emerge from the refactoring.

Don’t go first

Just sayin’ …

Hanging out with agile journeymen is mental adrenalin

Having an opportunity to talk code with people like Liz Keough, Jim Newkirk, Brian Marick and some top-notch agile coders was a real buzz. Hanging out with Patrick Wilson-Welsh and the cool Pillar dudes was also a blast. If you get a chance sign-up for this at Agile 2010!

Many thanks to Joshua Kerievsky, Jeff Nielsen and Industrial Logic for sponsoring this event.