Because of the fact that ActiveSupport makes a number of modifications to core Ruby classes, if your application does not otherwise explicitly require ActiveSupport, some of these core classes may now behave differently. Specifically, Hash and String core extensions were being used, as well as ActiveSupport::CoreExt::Module::Delegation.

Also, where Kookaburra::JsonApiDriver used ActiveSupport::JSON for encoding and decoding of JSON data, it now uses ::JSON as provided by either the json or the json_pure gems. The tests on Kookaburra itself pass just by swapping out ActiveSupport JSON library for the new one, but these tests do not comprehensively test JSON usage, and there may be differences that impact your application.

Kookaburra declares its dependency on the json_pure gem (a pure-ruby version) in order to ensure that it works cross-platform. However, both json and json_pure are written in such a way that, when you require 'json', it will detect if both libraries are installed and prefer the natively compiled json gem’s version of the library.

After a bit of searching, I found this post that explains how to make things right again.

TL;DR:

1

brew install reattach-to-user-namespace

1
2

# Reattach to user namespace so that clipboard integration with OSX works again
set-option -g default-command "reattach-to-user-namespace -l zsh"

Obviously, replace zsh above with whatever you use for your shell.

Because the original code was extracted from another project, the Kookaburra framework itself was not well tested. It had been indirectly tested due to its position within that other project’s tests, but as a seperate library it lacked tests that would help bot document the project and ensure newcomers can work on it with a good safety net. Additionally, there were a number of design decisions made in the earlier versions of Kookaburra that were…questionable. Not only would these decisions probably have been made differently if the development of the framework itself had been driven with unit tests, these decisions in many cases made it difficult to go back and add tests after the fact.

Starting with 0.15.1, which I just released a few moments ago, Kookaburra has been rewritten using a proper TDD approach. In some ways, 0.15.1 is possibly less functional than its 0.14.x cousins, but it is almost certainly easier to understand and contribute to the project from this point on. Please have a look at the new codebase, try it out in your projects, and send me a pull request with updates to the library. Also, if you have any problems getting it running, please don’t hesitate to let me know.

After a bit of poking around, I figured out how to use Jeweler to manage your versioning, gemspec and git tagging without pushing the result to rubygems.org when running the release task. It turns out to be both obvious and trivial. Just add the following line to the end of your gem project’s Rakefile:

1

Rake::Task[:release].prerequisites.delete('gemcutter:release')

We’ve been using Cucumber for acceptance testing at Renewable Funding since back when it was still part of the RSpec project (indeed, since before we were even Renewable Funding). While we’ve always liked the ability to have plain-language feature documentation that we could automatically test against, after years of adding to and maintaining a fairly large set of Cucumber scenarios, the cost of that maintenance was starting to really slow us down. The test suite began to grow fragile, and it seemed like every time one of our UX designers changed anything about the application’s interface, the development team would spend a bunch of time just babysitting Cucumber tests to get them passing again.

Last year, as I was reading Jez Humble’s excellent Continuous Delivery book, I was inspired when I came across the section titled “The Application Driver Layer” (p. 198). This section describes an approach to acceptance testing where the specification and the test implementation are isolated from the details of the application’s user interface by inserting a layer between the two that uses good old OOP to abstract the user interface components. Martin Fowler describes it as the Window Driver pattern on his website.

I started a proof-of-concept implementation of this pattern last summer, then my coworker, Sam Livingston-Gray and I started pulling it into a new project at work. After Sam and the rest of the Renewable Funding team helped improve on my original attempt while putting it to use for the last six or so months, we extracted a library to make it easier for other Ruby developers to implement this pattern in their testing. I’m happy to introduce Kookaburra to the world.

The following comes from Kookaburra’s README as of version 0.7.1.

Kookaburra

Kookaburra is a framework for implementing the Window Driver pattern in order to keep acceptance tests maintainable.

Setup

Kookaburra itself abstracts some common patterns for implementing the Window Driver pattern for tests of Ruby web applications built on Rack. You will need to tell Kookaburra which classes contain the specific Domain Driver implementations for your application as well as which driver to use for running the tests (currently only tested with Capybara). The details of setting up your Domain Driver layer are discussed below, but in general you will need the following in a locations such as lib/my_application/kookaburra.rb (replace MyApplication with a module name suitable to your actual application:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

module MyApplication
  module Kookaburra
    ::Kookaburra.adapter = Capybara

    # Note: the following assigned classes are defined under your
    # application's namespace, e.g. MyApplication::Kookaburra::APIDriver
    ::Kookaburra.api_driver = APIDriver
    ::Kookaburra.given_driver = GivenDriver
    ::Kookaburra.ui_driver = UIDriver

    ::Kookaburra.test_data_setup do
      provide_collection :accounts
      # See section on Test Data for more examples of what can go here.
    end
  end
end

RSpec

For RSpec integration tests, just add the following file to your project:

1
2
3
4
5

require 'my_application/kookaburra'

RSpec.configure do |c|
  c.include(Kookaburra, :type => :request)
end

Cucumber

For Cucumber, add the following file to your project

1
2
3
4
5
6
7
8
9

require 'my_application/kookaburra'

Kookaburra.adapter = Capybara
World(Kookaburra)

Before do
  # Ensure that there isn't state-leakage between scenarios
  kookaburra_reset!
end

This will cause the #api, #given and #ui methods will be available in your Cucumber step definitions.

Defining Your Testing DSL

Kookaburra attempts to extract some common patterns that make it easier to use the Window Driver pattern along with various Ruby testing frameworks, but you still need to define your own testing DSL. An acceptance testing stack using Kookaburra has the following four layers:

1. The Business Specification Language (Cucumber scenarios and step definitions)
2. The Domain Driver (Kookaburra::GivenDriver and Kookaburra::UIDriver)
3. The Window Driver (Kookaburra::UIDriver::UIComponent)
4. The Application Driver (Capybara and Rack::Test)

The Business Specification Language

The business specification language consists of the highest-level descriptions of a feature that are suitable for sharing with the non/less-technical stakeholders on a project.

Gherkin is the external DSL used by Cucumber for this purpose, and you might have the following scenario defined for an e-commerce application:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Feature: Purchase Items in Cart

  Scenario: Using Existing Billing and Shipping Information
    
    Given I have an existing account
    And I have previously specified default payment options
    And I have previously specified default shipping options
    And I have an item in my shopping cart

    When I sign in to my account
    And I choose to check out

    Then I see my order summary
    And I see that my default payment options will be used
    And I see that my default shipping options will be used

Note that the scenario is focused on business concepts versus interface details, i.e. you “choose to check out” rather than “click on the checkout button”. If for some reason your e-commerce system was going to be a terminal application rather than a web application, you would not need to change this scenario at all, because the actual business concepts described would not change.

The Domain Driver

The Domain Driver layer is where you build up an internal DSL that describes the business concepts of your application at a fairly high level. It consists of three top-level drivers: the APIDriver (available via #api) for interacting with your application’s external API, the GivenDriver (available via #given) which really just wraps the APIDriver and is used to set up state for your tests, and the UIDriver (available via #ui) for describing the tasks that a user can accomplish with the application.

Given the Cucumber scenario above, the step definitions call into the Domain Driver layer to interact with your application:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Given "I have an existing account" do
  given.existing_account(:my_account)
end

Given "I have previously specified default payment options" do
  given.default_payment_options_specified_for(:my_account)
end

Given "I have previously specified default shipping options" do
  given.default_shipping_options_specified_for(:my_account)
end

Given "I have an item in my shopping cart" do
  given.an_item_in_my_shopping_cart(:my_account)
end

When "I sign in to my account" do
  ui.sign_in(:my_account)
end

When "I choose to check out" do
  ui.choose_to_check_out
end

Then "I see my order summary" do
  ui.order_summary.should be_visible
end

Then "I see that my default payment options will be used" do
  ui.order_summary.payment_options.should be_account_default_options
end

Then "I see that my default shipping options will be used" do
  ui.order_summary.shipping_options.should be_account_default_options
end

The step definitions contain neither explicitly shared state (instance variables) nor any logic branches; they are simply wrappers around calls into the Domain Driver layer. There are a couple of advantages to this approach. First, because step definitions are so simple, it isn’t necessary to force Very Specific Wording on the business analyst/product owner who is writing the specs. For instance, if she writes “I see a summary of my order” in another scenario, it’s not a big deal to have the following in your step definitions (as long as the author of the spec confirms that they really mean the same thing):

1
2
3
4
5
6
7

Then "I see my order summary" do
  ui.order_summary.should be_visible
end

Then "I see a summary of my order" do
  ui.order_summary.should be_visible
end

The step definitions are nothing more than a natural language reference to an action in the Domain Driver; there is no overwhelming maintenance cost to the slight duplication, and it opens up the capacity for more readable Gherkin specs. The fewer false road blocks you put between your product owner and a written specification, the easier it becomes to ensure her participation in this process.

The second advantage is that by pushing all of the complexity down into the Domain Driver, it’s now trivial to reuse the exact same code in developer-centric integration tests. This ensures you have parity between the way the automated acceptance tests run and any additional testing that the development team needs to add in. You could write the same test using just RSpec as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

describe "Purchase Items in Cart" do
  example "Using Existing Billing and Shipping Information" do
    given.existing_account(:my_account)
    given.default_payment_options_specified_for(:my_account)
    given.default_shipping_options_specified_for(:my_account)
    given.an_item_in_my_shopping_cart(:my_account)

    ui.sign_in(:my_account)
    ui.choose_to_check_out

    ui.order_summary.should be_visible
    ui.order_summary.payment_options.should be_account_default_options
    ui.order_summary.shipping_options.should be_account_default_options
  end
end

Whether in Cucumber step definitions or developer integration tests, you will usually interact only with the GivenDriver and the UIDriver.

TestData

Kookaburra::TestData is the component via which the GivenDriver and the UIDriver share information. For instance, if you create a user account via the GivenDriver, you would store the login credentials for that account in the TestData instance, so the UIDriver knows what to use when you tell it to #sign_in. This is what allows the Cucumber step definitions to remain free from explicitly shared state.

The TestData class can be configured to contain both collections of test data as well as default data that can be used as a starting point for creating new resources in the application. To configure TestData, call Kookaburra.test_data_setup with a block (usually in your lib/my_application/kookaburra.rb file):

1
2
3
4
5
6
7
8
9
10
11
12

module MyApplication
  module Kookaburra
    # ...
    ::Kookaburra.test_data_setup do
      provide_collection :animals
      set_default :animal,
        :name => 'horse'
        :size => 'large',
        :number_of_legs => 4
    end
  end
end

Then, in any context where you have an instance of TestData (such as in GivenDriver or UIDriver), you can add/retrieve items to/from collections and access default data:

1
2
3
4
5
6
7
8
9

class MyApplication::Kookaburra::GivenDriver < Kookaburra::GivenDriver
  def existing_account(nickname)
    default_account_data = test_data.default(:account)
    # do something to create account in application
    # ...
    # make the details of the new account available to the rest of the test
    test_data.accounts[nickname] = account
  end
end

1
2
3
4
5
6
7
8

class MyApplication::Kookaburra::UIDriver < Kookaburra::UIDriver
  def sign_in(account_nickname)
    # pull stored account details from TestData
    account_info = test_data.accounts[account_nickname]

    # do something to log in using that account_info
  end
end

APIDriver

The Kookaburra::APIDriver is used to interact with an application’s external web services API. You tell Kookaburra about your API by creating a subclass of Kookaburra::APIDriver for your application:

1
2
3
4
5
6

class MyApplication::Kookaburra::APIDriver < Kookaburra::APIDriver
  def create_account(account_data)
    post_as_json 'Account', 'api/v1/accounts', :account => account_data
    hash_from_response_json[:account]
  end
end

GivenDriver

The Kookaburra::GivenDriver is used to create a particular “preexisting” state within your application’s data and ensure you have a handle to that data (when needed) prior to interacting with the UI. Like the APIDriver, you will create a subclass of Kookaburra::GivenDriver in which you will create part of the Domain Driver DSL for your application:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class MyApplication::Kookaburra::GivenDriver < Kookaburra::GivenDriver
  def existing_account(nickname)
    # grab the default account details and add a unique username and
    # password
    account_data = test_data.default(:account)
    account_data[:username] = "test-user-#{`uuidgen`.strip}"
    account_data[:password] = account_data[:username] + "-password"

    # use the API to create the account in the application
    account_details = api.create_account(account_data)

    # merge in the password (since API doesn't return it) and store details
    # in the TestData instance
    account_details.merge(:password => account_data[:password])
    test_data.accounts[nickname] = account_details
  end
end

UIDriver

Kookaburra::UIDriver provides the necessary tools for driving your application’s user interface using the Window Driver pattern. You will subclass Kookaburra::UIDriver for your application and implement your testing DSL within your subclass:

1
2
3
4
5
6
7
8
9
10
11

class MyApplication::Kookaburra::UIDriver < Kookaburra::UIDriver
  # makes an instance of MyApplication::Kookaburra::UIDriver::SignInScreen
  # available via the instance method #sign_in_screen
  ui_component :sign_in_screen

  def sign_in(account_nickname)
    account = test_data.accounts[account_nickname]
    navigate_to :sign_in_screen
    sign_in_screen.submit_login(account[:username], account[:password])
  end
end

The Window Driver Layer

While your GivenDriver and UIDriver provide a DSL that represents actions your users can perform in your application, the Window Driver layer describes the individual user interface components that the user interacts with to perform these tasks. By describing each interface component using an OOP approach, it is much easier to maintain your acceptance/integration tests, because the implementation details of each component are captured in a single place. If/when that implementation changes, you can—for example—fix every single test that needs to log a user into the system just by updating the SignInScreen class.

You describe the various user interface components by sub-classing Kookaburra::UIDriver::UIComponent:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

class MyApplication::Kookaburra::UIDriver::SignInScreen < Kookaburra::UIDriver::UIComponent
  component_locator '#new_user_session'
  component_path '/session/new'

  def username
    in_component { browser.find('#session_username').value }
  end

  def username=(new_value)
    fill_in('#session_username', :with => new_value)
  end

  def password
    in_component { browser.find('#session_password').value }
  end

  def password=(new_value)
    fill_in('#session_password', :with => new_value)
  end

  def submit!
    click_on('Sign In')
    no_500_error!
  end

  def submit_login(username, password)
    self.username = username
    self.password = password
    submit!
  end
end

I don’t mind spending money on nice miniatures for player characters, but you can spend an insane amount buying miniatures to represent the monsters and NPCs the characters might encounter. Also, if you’re going to use miniatures for monsters and NPCs, you need to have the right miniatures; using a kobold figure to represent a needle demon doesn’t really help with the suspension of disbelief.

Maybe it’s just that I have fond memories of games that took place entirely in our heads, but I like the idea of using generic tokens to represent position and leaving the physical description up to the DM’s skills and the players’ imaginations.

A good way to make character tokens is to stick a 1” diameter, felt furniture pad to one side of a 1” (outer!) diameter, metal washer. The metal washer gives the token enough weight to stay put on the battle grid, and the felt furniture pad gives it enough height to be easy to pick it up and move it around. Then, you can just use those Post-It™ Flags to identify each token (and keep track of any active effects on it).

You could probably do the same with 2”, 3” and 4” diameter washers and pads for your bigger creatures, although huge and gargantuan creatures may be special enough that buying nice models for these is probably worth the money.

Giving credit where it’s due, I riffed on this process for creating tokens posted at Newbie DM. I just don’t bother with all the graphics editing and printing, and I like to give the height to all of the tokens (with the furniture pads), because washers by themselves can be hard to pick up when they’re laying flat.

I wish this photo was a bit sharper, but it still sums up my feeling pretty well about… well… a lot of things. :-)

At any rate, I’m switching over to Octopress to run this site, because a) it’s the new awesome, and b) maybe I’ll spend more time writing articles if I’m not trying to tweak my home-grown blogging engine while I do it. I chose Octopress because it has the parts I like about jekyll (I get to write my posts in vim and eaisly manage the content with git), but it has more of the rough edges smoothed out (again, so I can spend my time writing articles instead of working on the engine.)

As part of this, I’m also moving the site from Heroku to Github Pages. Nothing at all wrong with Heroku; it’s just one fewer thing for me to deal with.

I’m now going to port over old articles (a much easier task than last time, since the last version of this site was also using markdown-formatted text files.) The comment system was already on Disqus before, so hopefully I can figure out how to get the old comments associated with the new URLs.

The test passed fine on my machine (with Firefox 4 installed), but it failed consistently on CI, which has Firefox 3.5. It kept failing with the exception Capybara::TimeoutError: failed to resynchronize, AJAX request timed out. I didn’t dig enough into the guts of Selenium/Firefox to find out exactly what is going on (and a Google search for that error message turned up nothing that really explained it) but I did at least find a workable fix. Just add the following line to spec/support/capybara.rb:

1

Capybara::Selenium::Driver::DEFAULT_OPTIONS[:resynchronize] = false

Now, I can’t guarantee that this won’t have a negative effect further down the line, but it works for my smoke-test. The resynchronize option must be using something that is only available in later versions of Firefox.

Obviously the better solution would be to upgrade Firefox on our build-agents. Unfortunately there isn’t a Firefox 4 RPM available for the Linux distribution/version that those machines are using, and our sysadmin doesn’t have any room on his plate to come up with a custom solution. Also, we have an older application that still uses Webrat/selenium-rc, and I don’t believe that supports Firefox 4 yet.

I’d love to see any comments or pointers to information that would help me understand exactly what that resynchronize option is doing, especially if someone knows why turning it off could be a Very Bad Thing™.

My goals for this program are as follows:

• Contribute back to the local and global software development communities by providing mentoring, a place to work, and stewardship of one or more open-source projects.

• Provide a safe, open, fun environment for people of all backgrounds to improve their skill in a non-competitive, supportive learning environment.

• Increase local knowledge about Renewable Funding’s software development team, so that when we post job openings, you all know who we are.

• Identify local developers who—while they may not have a lot of experience—have a lot of talent and passion, so that we know who to talk to when we have appropriate positions open up.

Here’s what I’m thinking as a starting point, please let me know what might not work, and what might work better:

• Recruit a group of between 2 and 6 local developers who are interested in participating in the program for N months. (What is an appropriate time period?)

• The group gets together at our office one evening per week for the duration of the term. (Thursdays from 4pm-8pm? Is once per week the right frequency?)

• At least one senior developer from my team will be at each session to coach and mentor the team. Renewable Funding will pay for dinner and/or snacks.

• The group will decide on an open source project to work on. It could be a new creation or contributions to an existing project.

• The group will work on project following an agile methodology similar to what we employ during our daily work at Renewable Funding.

• We may be able to open our office to participants during regular work hours to provide a space to work and access to individual mentoring.

So, is this a good idea? Would anyone be interested in this? Am I overlooking some obvious and potentially disastrous outcome?

A couple of years ago, our team was much smaller. We had around three full-time developers working on the code, and we would all commit our work-in-progress to the master branch in our git repository and push those commits out when we had a set that made sense to share with the other developers. With only a few developers, we would usually be working on one feature at a time, and once a small number of features were accepted and ready, we could go ahead and release them to production. This worked pretty well at the time, and when we did have a merge conflict, we were all familiar enough with what was being worked on to be able to work it out reasonably.

In 2010, the ProjectDX team was acquired by Renewable Funding. Among other things, this gave us both the resources and the need to grow the team beyond just a few developers. I took over management of the software development team, and within several months had hired three new developers and then added 2-3 contract developers to the team at any given time. It’s no big surprise that increasing the size of a team by a factor of three in a six month period is going to have some challenges, and one of those was how the flow of work through the system needed to change.

At first, we didn’t change anything about that process (I prefer not to change things before I have any idea what the real problems are going to be). Developers still committed work to the master branch, and that branch was deployed to our internal alpha server by our automated CI system if and when all of the tests passed. When the developers working on a feature felt that it was complete, they put it up for acceptance, and the product owner verified the feature on alpha before either accepting or rejecting the work. However, our increased capacity meant that more individual features were worked on at any given time, and this parallel development ran up against some shortcomings in our process.

Our release cycle is once every two weeks. We plan our work into two-week sprints, and a feature isn’t considered “done” until it is accepted by the product owner and actually released to production. The problem we ran into was that—on occasion—a feature planned for a sprint would not be accepted in time for that sprints’s production deployment. This caused problems putting together the production release. For example, let’s say the team worked on Feature A and Feature B during the sprint. Feature A gets accepted and is ready to release, but there are some issues with Feature B that mean we are not going to put it in production this time around. Since we worked on both features at the same time, the commit log on the master branch contained a mix of commits for both features and looked like:

• A
• A
• B
• A
• B
• A
• A
• B
• B

When it came time to put together the release, we only wanted to take the commits for the accepted feature and merge them into the production branch. This meant that someone would have to go through the commit logs, find the relevant commits, and cherry-pick them into production one at a time. First problem: that’s a mind-numbing chore for whoever is tasked with it.

Now imagine that—even if there are no inherent dependencies between Feature A and Feature B—there are changes made in one of the early commits for Feature B to a commonly used area of the code. Then, in the further work on Feature A, the code is written in such a way that depends on this new behavior added by Feature B’s commits. Not a problem if both features get approved for the release, but it does become an issue when only Feature A makes it to production. At that point, the person tasked with putting together the production branch ends up with failing tests and—possibly—a merge conflict. It’s especially fun when that person didn’t actually work on the changes involved.

That’s bad enough; but it gets worse. It’s not as if we stop working on Feature B just because it doesn’t get accepted for this release. The people working on it continue to do so, and the est of the team starts work on Feature C. By the end of the sprint, we have a commit log on the master branch that looks something like:

• A
• A
• B
• A
• B
• A
• A
• B
• B
• C
• B
• C
• B
• B
• C
• C

Luckily, both B and C get accepted this sprint, so we can cherry-pick both of these into production, and everything should be fine, right?

Well, the production branch now looks like this:

• A
• A
• A
• A
• A
• B
• B
• B
• B
• C
• B
• C
• B
• B
• C
• C

Notice an issue there? The production branch contains all of the same commits as the master branch, but now they are applied in a different order. In practice, this led to some very interesting merge conflicts. In some cases, it didn’t lead to conflicts that git was able to detect, but it caused some defects to appear in production that were not present during our internal acceptance process (performed against the master branch).

After a couple of “releases from hell”, it was apparent to the whole team that this was a problem that we needed to solve. We put our heads together and came up with a solution that has been working great for us in the several months since adopting it.

The first change is that we no longer have the whole team committing work-in-progress to master. Whereas we used to have a master branch that contained the main line of development and a production branch that only contained work that was in (or ready to go to) production, we decided to turn that on it’s head a bit. We made the decision that the master branch wasn’t really all that important, and that the production branch was the most critical part of the system. Regardless of what undeployed work might be in commits on the master branch, the production branch is what is “real” and “permanent”. If you want to keep feature development independent from work on other features, the production branch is the one thing you can rely on not changing prior to the next production release.

Now, that’s all well and good, but I’d have to cut a corner off my agile practitioner’s card if I suggested that we based each feature off of the production branch and didn’t integrate them until the end of the sprint. On the other hand, we don’t want to change the production branch until we’re ready for a release (in case we need to push out an emergency, mid-cycle release to fix a critical defect.)

The challenge was to come up with a workflow that would protect the “actually in production” nature of the production branch while making sure we didn’t fall into the trap of “big bang integration” at the end of the sprint. In order to meet these goals, at the beginning of every sprint we create a new branch based off of the production branch called sprint-N (where N is the number of that sprint). Each feature that is being worked on during that sprint also gets its own branch, and the feature branch is based off of the sprint branch.

When a feature is ready for acceptance, the developer in charge of the feature will deploy the code from our feature branch to the alpha environment for the product owner to review. The product owner is able to review that feature in isolation from all of the other work in progress. This gives him confidence that—even if this were the only thing we got done this sprint—it would behave the same way in production.

If the product owner rejects the feature, the developers go back to working on it, and no other features are directly impacted. If the product owner accepts the feature, then and only then does the feature branch get merged into the sprint branch (we use git merge --squash so that the changes for the feature show up as a single commit in the sprint branch). After the changes are merged in, the rest of the team is notified that the sprint branch has been updated, and all other in-progress feature branches are rebased onto the new HEAD of the sprint branch. (For those not familiar with git, rebasing—in layman’s terms—means rewriting history such that all of the commits made only to the feature branch will be applied after any changes that appear on the sprint branch, regardless of the actual chronological order of those commits.)

With this system, we make sure that no feature has any unintentional dependencies on work that may not be accepted, because the sprint branch only contains code that is actually in production plus already accepted work that will go out in the next release. At the same time, because changes are merged into the sprint branch as soon as they are accepted, we are able to test integration at the earliest practical point in time. When the developers working on other features rebase their branches onto the new sprint branch, they deal with any actual or semantic merge issues at that time. That way, the people most familiar with the changes are able to resolve the conflicts while those changes are still fresh in their minds.

We use TeamCity to run our automated, continuous integration. TeamCity runs tests whenever it detects changes to either the sprint branch or the production branch. Additionally, we can easily clone the build configuration and have it run against the branch for a particular feature. We don’t do so for every feature, but we use that capability for larger features that need to integrate the work of multiple pair-programming teams.

When the end of the sprint arrives, updating the production branch is as simple as git checkout production && git merge sprint-N. Since the sprint branch was created directly from the production branch and only contains accepted work, this is always a simple, fast-forward merge. We tag the production branch with the release number and deploy that to our staging environment for a final once-over before delivering to production.

If you can answer yes to both questions, then your team is agile. Whether you use XP, Scrum, Lean, Waterfall or any other process or mix of processes doesn’t matter at all for the purpose of determining agility; these processes may help you deliver software that meets stakeholder needs in a timely fashion (or they may not), but no single one of them is “the right way”.

Note that I don’t ask about delivered value or sustainable pace. It’s not my intent to discount the importance of either of these things in general; I do not, however see them as a strict requirement of agility, per se. Granted, if a team isn’t able to do both of these things, that team probably will not be successful in the long run, but if the team asks itself the two questions I propose, then the other things are likely to fall into place naturally. (When I say team, I am talking about the whole organization—it is critical that the team is empowered to make changes that can affect its answers to these questions, so the management needs to be part of the process.) Both the Agile Manifesto and Elizabeth’s questions address qualities that are typically evident in truly agile teams, but the essence is that a team is able to react quickly to whatever is thrown at it and is able to react differently to changing situations.

Most software development methodologies start out as experiments that worked for one team, got introduced to others and managed to gain successes and proponents. Then somebody puts a label on it and writes down the definition of what it means to do, say, Scrum. Now we have a neat list of things that a consultant can point to and say “yes, you are doing Scrum” or “no, that’s not Scrum”. This recipe for Scrum is now ready to ship off to other development organizations, and if only they perform the recipe just the way it’s written down, everything will be fine.

Right…

A tangent: My wife and I both love to cook. One of my favorite celebrity chefs is Alton Brown—he is, in fact, singularly responsible for my move from viewing cooking as “something you had to do occasionally if you wanted to eat” to being something I actually enjoy doing. The reason for this is simple: he doesn’t just give you a recipe, he gives you the tools you need to reflect on what you’ve done and understand why a dish did or did not turn out the way you expected. That way you know what to do differently next time as opposed to assuming you can’t make that particular recipe work and giving up on it.

The promotion of various “agile” methodologies as connect-the-dots exercises is the biggest failing of the agile software development movement. A methodology gains enough popularity that an organization’s management (or often the developers themselves) decide to adopt that methodology in order to take advantage of the benefits of “agile”. They follow the process to the letter for one or two releases, but they don’t meet the goals of the organization, write off “agile” as something that won’t work for them and go back to old patterns that are perceived to work at least a little bit better for them. Meanwhile, the consultants and trainers have moved on to greener pastures with the occasional tweet about “#notscrum”.

I much prefer the approach of those like Diana Larsen of FutureWorks Consulting and co-author of the excellent book Agile Retrospectives who—while promoting agile methodologies—stresses the importance of an organization reflecting on what it has achieved, what it has failed at, and in both cases how and why it has done so. She will then challenge that organization to find the next steps it can take to get closer to meeting it’s goals.

With such an approach, a team that is new to agile software development may start out with a by-the-book Scrum implementation, but after several iterations of delivery, retrospective and process modification, that team may or may not have a process that still resembles Scrum. As long as that team is able to answer yes to my two questions, they may be “#notscrum”, but they can hardly be called “#notagile”.

So, I gave toto the boot and am hand-rolling something simple. Yes, I know there are a few other weblog tools out there that would give me the simplicity of editing locally in vim using a markdown-formatted file, but I guess I’m suffering from a bit of not-invented-here at this point after trying a couple and finding them severely flawed when it comes to the way I want to work with them.

Frankly, I also needed an outlet for hacking on something that didn’t have to be useful to anyone other than myself. The amount of time I’ve been able to spend just writing code had decreased substantially since I took on management of the ProjectDX team at the beginning of the year.

Now that posting isn’t a complete pain in the rear and the dates will show up correctly, I’m hoping I might actually bother to write a blog post once in a while. Based on historical evidence, I wouldn’t hold my breath if I were you.

Part of me wonders why I keep this site up and running at all. I tend to make public statements in 140-character increments these days. Twitter has killed the casual blog.

Thankfully, even though Renewable Funding is based in Oakland, CA, there are no plans to move our team down there. We’ll be staying in Portland and continuing to work on the public-facing web application that provides communities with tools to educate their residents about sustainability programs and allow property owners to manage applications for PACE financing programs.

I’m looking forward to figuring out my new role as I step into a management position. Although I’ve always been a natural leader–I’ve served as technical lead on various teams and held a lot of influence over team and process design in my consulting work–this is the first time I’ve been responsible for personnel management and had people reporting to me in the org-chart. I don’t pretend to know all there is to know about being a great manager, but I have the benefit of some great mentors and a fantastic team to start with. I’ve always done my best work when I’m thrown in just a bit over my head, and this is definitely pushing my boundaries (especially when combining the new responsibilities with navigating a merger).

I’ve had the decision to completely restart my website made for me. The previous incarnation of my site was being generated via a post-commit hook in a git repository that lived on a VM at Slicehost. I decided to shut down that VM and move the website to a system that I didn’t have to maintain. Unfortunately, I thought that I had the git repository mirrored on my GitHub account, but apparently not. I’m sure I could come up with usable backups if I put forth enough effort, but let’s be honest: thanks largely to Twitter, I had barely updated the site in the last 2 years, and a lot of what was there was either outdated or of no real value to anyone other than myself.

So here we go again. This time around, I’m just using GitHub’s pages feature to publish the site. I don’t have to maintain the server, and now I know that the repository is on my GitHub account.

UPDATE I’m actually switching to using toto with Heroku. I like toto better than jekyll, because I don’t have to put up with using the Liquid page templating engine. Plain-old ERB FTW!

The activities we used during the retrospective mainly came from Diana Larsen and Esther Derby’s book, Agile Retrospectives. We started off with the “ESVP” (Explorer, Shopper, Vacationer, Prisoner) activity to find out what the group’s interest level was in relation to the work we were doing in the retrospective. Nearly everyone in the group said they were an Explorer via anonymous vote. With this group, I basically trust that outcome, although I did wonder if anyone may have given the answer they thought they were “supposed” to give.

Next, I had the team build a time line of events from the past release. Prior to the start of the retrospective, I drew the time line on our white board and divided it into sections for each iteration (our cycle is 2 3-week sprints followed by a 2-week, internal Alpha testing period and a 2-week customer Beta testing period). The result looked something like:

1
2
3
4
5
6
7
8
9
10
11
12
13

|----------|----------|-------|-------|
| Sprint 1 | Sprint 2 | Alpha | Beta  |
|          |          |       |       |
|          |          |       |       |
|          |          |       |       |
|          |          |       |       |
|          |          |       |       |
|          |          |       |       |
11/03 -----11/24 -----12/15 --12/29 --01/09
|          |          |       |       |
|          |          |       |       |
|          |          |       |       |
|----------|----------|-------|-------|

During the retrospective, I had everyone take some time to think about any events during that time period that were meaningful to them in any way, write the event on a sticky note then stick the note on the time line in roughly the right spot. We spent about 45 minutes generating events, during which time we were free to look back at calendars and email as well as the commit logs from our SCM. Having set the time box to 45 minutes, I said it was fine for people to take a break if they felt like they couldn’t remember any more events and asked everyone to simply be back on time for the next step.

Rather than specifying that people work in pairs, I opted to have the team self-organize here. It was interesting to see how—at first—everyone seemed to work on their own, but as the more obvious events were posted to the board, people started working in groups to come up with more data. At the end of the allotted time, we had a white board full of events.

The area below the time line was intended for a graph of energy/emotion levels, which I’ll talk about in a moment, but JD Huntington had a great idea to also add to that area a rough bar graph of our commit volume as reported by GitHub’s activity graphs.

After everyone had a last opportunity to look at the board and add any last-minute stickies, I asked everyone to take a turn at the board and use markers to place a blue dot next to any event which they felt positive about and a red dot next to any event that they felt negative about. Then, I asked them to think about their positive and negative energy/emotion levels throughout the release and draw a line graph in the bottom section to signify their ups and downs throughout the release cycle. At this point, we looked at each iteration in the cycle and I asked the team to make observations about the data. Using bullet lists at the bottom of the white board, we captured the observations as further data points for analysis.

After a break for lunch, we used the “Patterns & Shifts” activity to generate insights about the data on the time line. We gathered around the white board where I asked each person to mark on the time line any point at which they felt there was a shift or transition of some sort and to draw lines between any events, graph points and observations that they felt were somehow related.

After no one was able to see any more connections, I asked the team to look for any patterns among the connections and the shifts. The first thing we noticed was that we felt like the real shift between iterations was constantly happening about 3 days after the actual time box ended. Rather than get into a long discussion about it when it was noticed, I asked the team to simply keep it in mind as a possible concern during the next phase of the retrospective.

The next observation was that we had a number of connections with long lines spanning two or more iterations. I asked everyone to focus on these connections and look for those where we may have noticed an issue early on but it wasn’t addressed until much later. In some cases it turned out that while that was the issue, the length of the line just signified that either the work took that long or there was a conscious decision not to address the issue right away.

Reflecting on the other cases led to an interesting discovery, however. Chris noticed that where the lines crossed the bounds of the iterations it was likely signifying a parallel cycle which we were attempting to force into our release cycle: specifically, we have both an explicit product release cycle and an inexplicit customer deployment cycle occurring at the same time.

After we were finished recognizing patterns in the data, it was time to discuss these patterns (and anything else on our minds) and come up with a few action items for the next release cycle. Here I ran the team through the “Circle of Questions” activity. In this activity, the group sits in a circle, and each person takes turns asking a question to the person on their immediate left. The question can be about anything they like (barring anything offensive or attacking), but it’s helpful to focus on the insights gained during the previous stage of the retrospective. The person to the left answers the question to the best of their ability, and then they ask the person to their left any other question (or the same question if they feel they’d like a better answer). This continues until the alloted time is up or you have gone around the entire circle twice, whichever comes last. Make sure you go around the complete circle: if some people in the group get more turns to ask or answer a question than others, it can send the wrong message.

The thing that I really like about the Circle of Questions activity is that when you have a mixed group of people—some of whom tend to dominate the conversation while others tend to stay quiet—it gives everyone a chance to ask their questions and have their opinions heard without feeling like the most boisterous people have the only valuable input. We certainly have a mix like that in our case, and this activity worked wonderfully.

In the end, we came away with a number of things to change for the next release cycle. It’s interesting to note that none of our action items were directly related to the insights generated from the time line. I think the insights are still valuable (and are contained in the notes which we post to our internal wiki), so we may still come back to them in the near future; we were running over on time and had to wrap up even though the discussion could have continued longer.

Before we held this retrospective, I think some of the team members felt that we would not gain much from doing a full-day retrospective this time around. We had made good progress on our action items from the previous retrospective, and the general feeling was that things were going basically well. What could we possibly need to change?

People, please don’t hold retrospectives only when your team feels like there’s a problem that needs to be dealt with. If you hold retrospectives on a regular basis, whether you feel like you “need” to or not, you will uncover issues before the become problems. In our case, we managed to uncover a number of issues during our retrospective that could easily have grown into much larger problems if we didn’t bother to think about them until the effect was obvious.

If you do have obvious issues, then you might choose a different set of activities than what we did for this retrospective. The time line activity is great for discovering potential improvements even when everything seems to be going well, so I suggest giving it a try the next time your team is tempted to skip a retrospective because no one thinks there’s any huge problems.

I can’t believe 2008 is already over. The older I get, the faster the years seem to fly by; I’m not sure I like the trend. The effect mainly tells me that I need to concentrate more on living my life intentionally, so that I have a better memory of my everyday experiences.

That’s not to say that I don’t remember 2008—this has been a year of big changes and lots of neat experiences. The year started off with a plan to take a job in Dublin, Ireland and move the whole family over there with me. For various reasons, that didn’t work out. We stayed in Portland where I opened up shop as an independent consultant. Finally, after working with a number of wonderful clients, I decided to accept a job offer from one of them; and I’m once again an employee.

Probably my most important achievement of 2008 was to completely, 100% quit smoking cigarettes. I had actually quit in the Fall of 2007, but I was using the nicotine patch, and it took me longer than it should have to wean myself off of it. But I did, and I’m now living completely nicotine-free.

I did not, unfortunately, stick to my exercise goals for the year. The new bike I bought this summer with a plan to ride several time per week has only been out of the garage a handful of times. In the Fall, I started the 100 Push-ups program and added on sit-ups, leg curls and calf extensions. I was doing pretty good for a few weeks, but then my schedule got thrown off when Misty went out of town, and I never got back on track. Boo.

Of course, no 2008 year-end review would be complete without a record of the Snowpocalypse which descended upon us during the last half of December. It almost never snows on the valley floor in Hillsboro or Portland. This year it not only snowed, but it stuck. We had well over a foot of accumulation by the house along with a half inch of ice. Since we’ve no infrastructure for clearing the roads, everything basically shut down. Of course, I enjoyed the hell out of it, because it gave me a chance to put the Jeep in 4-lo once or twice.

This was definitely a prosperous year for our family, and we’ve been able to do a number of fun extra things such as pay for my friend, Quentin Baker, to fly out for a few days this fall and for my dad and his wife to come out for a week during Christmas. We’re debt free except for two car payments, and we’re hopefully in a good position to weather the current problems with our economy.

2009 looks like it could be another year of changes. It’s definitely going to be a big change for our country as our new president takes office. Hopefully I’ll be able to bring some more positive change to my individual life as well. I plan to spend some time tomorrow thinking about my goals and resolutions for the next year.

For now, good-bye 2008 and happy new-year!

I’m not hosting on GitHub, though. I simply installed Jekyll on the cheapest VPS from Slicehost, set up a git repository on that server to hold the contents of the site and then slapped together a simple post-update hook script for git that automatically publishes the site when I commit changes.

The changes also come with a new design.

Dragons are cool, so I am cool.

The stylesheets obviously aren’t fleshed out yet, so everything pretty much looks like crap. I plan to have it fixed up real soon.

Also need to slap together a new Atom feed for the posts.

All worth it, since I can now easily compose my posts in Vim using markdown syntax and have them stay editable in that format. Maybe now I’ll actually post more than once every couple of months. :-)