Monday At Agile2010

Agile 2010 started today, and I’m already glad I decided to come (and that I convinced people to send me). I picked up my badge and hit breakfast, where I discovered the first of several differences between this and GenCon. Normally, when I see “fruit” on a breakfast buffet, it’s two or three kinds of melon. That’s fine, but I really don’t like melon.1 Here, however, there were strawberries, blueberries, blackberries, and raspberries, in addition to the melon. Considering my normal breakfast at home is berries and yogurt, I was pleased.2

After breakfast, my first session was Janet Gregory’s “The Dance of the Agile Tester: An Iteration-Length Performance.” I have Janet’s book, Agile Testing,3 but I haven’t been able to do more than skim it, so I was curious to get an overview of testing in an Agile context. The session didn’t disappoint, despite be interrupted by a fire alarm. Among my key takeaways:

• Continuous Integration means that a stable, up-to-date build can be pulled for testing at any time.
• It is useful to differentiate types of tests along two axes: tests that support the team vs. those that critique the product, and tests that are business facing vs. those that are technology facing.4
• In Agile, a requirement is a story + an example + a conversation.
• Don’t leave iteration planning without your acceptance tests defined, at least at a high level. Acceptance tests are about intent, so it is vital to develop a shared understanding of the problem.
• Automating tests is what makes time for exploratory testing.

A focus on testing and integration carried over into my afternoon session, “Continuous Delivery” by Jez Humble and Martin Fowler. This presentation was all about “taking code that works when you hit F5 and making sure it works for the customer.” Their contention is that cycle time5 is probably the most valuable measure of whether you’re doing Agile well. One cause of long cycle times is that the “last mile” of delivering something that works in a production environment is painful. We’ve gotten good at setting up continuous integration systems that verify our code works in a development environment, but that doesn’t always tell us if it will work for our customers. There are usually two forces at play here: poor collaboration between development and operations, which is often caused by organizational structure, and lots of manual work to deploy to a production environment, caused by a lack of knowledge and tools. While Jez talked a little about the former near the end of the presentation, most of the session focused on the latter.

So what is the ideal that we’re trying to reach?

• Getting software production-ready is not a phase; it happens continuously.
• Deployments are reliable and easy to roll back in a rare case something goes wrong.
• Everyone can self-service; there’s no additional overhead when someone needs a build.
• Releases happen according to the needs of the business, not the needs of development.

How do we get there? We need fast, automated feedback on production readiness every time there is a change to code, to infrastructure, or to configuration. When we have small deltas, finding and fixing problems is easier. Getting this feedback requires that we have excellent automated testing at all levels, that we have comprehensive configuration management, and that we have true continuous integration. Martin proposed an intriguing criterion for when your tests are good enough: You should have confidence that if someone had access to your source code and made a change, if all your tests ran green it would okay to ship.6

They talked a bit about specific techniques for building, testing, and deployment, but for me the most interesting other topic they covered was continuous integration. Specifically, Martin wanted to make clear what felt continuous integration really is. For him, it means:

• Every build is repeatable
• Build means test too
• A commit is not considered successful until the mainline goes green
• Everyone commits to the mainline every day
• Feature branches are incompatible with continuous integration.7

All in all, it was great day of sessions. I stayed at the architecture/design level of technical topics, which is about where I wanted to be. I was sorry I missed Matt Smith’s session on improv, but I got a lot value of what I attended. And to think I’ve got three and a half more days to go.

1 I feel this reflects poorly on my character.

2 They had yogurt too, but enough about breakfast.

3 Co-authored with Lisa Crispin, whom I noticed appeared at one point.

4 This is Brian Marick’s 4 Quadrants of Testing

5 Measured in Concept-to-Cash terms: From the point at which you have an idea of something you could sell, how long does it take for you to have delivered it and gotten paid?

6 Because this is what development does, after all.

7 Particularly if you have more than one branch at a time.