March 29, 2011

Agile Road Show: Day 1


This is my first time at the Agile in Action Road Show, and so far my main impression is the quality of the tools that have sprung up in this space. If I was looking to take a team into the Agile methodology sphere, I wouldn't have to start from scratch anymore. I can use tools ranging from backlog management to SCM to continuous build; these tools are tailored for Agile and the good ones are well integrated.

The next impression is that Perforce's founder was ahead of his time. He founded Perforce to be a fast, powerful SCM system that got the job done and didn't get in the way. That fits right into the Agile perspective, which emphasizes people and interactions over tools and processes. In version control terms, that means manage your digital assets and releases for your business, not to make your SCM tool happy. That sounds like common sense, but after spending a few years working in the defense industry with some pretty heavyweight development tools, its a breath of fresh air.

The keynote speaker today, David Hussman, was very entertaining. He's coached Agile at a variety of firms, ranging from the US Army to Harley-Davidson. He's thought a lot about the value of Agile, and he came up with what he calls Dude's Law: Agile Value = Why / How. (If you saw his hair, you'd understand the Dude moniker.) So the agile value is proportional to the business needs, and inversely proportional to the time and effort to implement things.

That makes sense, of course, and it explains why Agile is rapidly maturing and becoming a general business process model, expanding out of the software world. Many companies (including Perforce) are using Agile for non-engineering groups, like marketing and sales. During the break today I want to ask him a few questions about whether Agile is better used in a cross-functional team, rather than strictly marketing or sales. For instance, when a marketing team is planning a product rollout, they're not working in isolation. It seems like product rollout should be a project, and include engineering, QA, release, marketing, and sales, so that the dependencies can be properly tracked. That may be one of the key challenges to scaling Agile for non-product teams -- the dependencies across the enterprise must be acccounted for. At Perforce we use different project tools in different departments, which adds to the challenge. But at least we all use Perforce to store our digital assets, which helps with collaboration.