Agile Road Show: Day 2
A few musings from day 2 of the Agile Road Show...
Listening to David's keynote a second time, I'm thinking more about the challenges of scaling agile from small teams to large enterprises. As he pointed out, you can't simply add more Scrum masters or more training and claim that you're agile. You really need to incorporate the principles of Agile into the entire organization to be successful.
There's no simple solution, but its important not to get hung up on specific implementations of Agile. If you're managing a team of 50 users at multiple offices, use a tool to coordinate the mechanical process of tracking stories and tasks. As your development velocity increases, take advantage of all the Perforce features that help you track and manage the flow of change across teams and branches. Use a powerful build system to automate everything that happens around a check-in.
I talked yesterday about how Perforce's founder was ahead of his time by designing Perforce to always be fast and flexible. By doing that, he put down a solid foundation that lets Perforce scale up from small teams to huge organizations. And we're still building on that foundation to make a more innovative, scalable product. You can't scale SCM, or make it more Agile, just by adding more hardware or more administrators. Rather, features like replication (available in the 2010.2 release), streams (upcoming), and local branching (upcoming) improve Perforce's workflow and architecture. That makes all the users more productive, and I think it shows that Perforce has kept its core principles near and dear. Getting back to David's point, Perforce isn't scalable or Agile because we're bolting on an Agile widget. Speed and flexibility are part of our DNA.
On a side note, I'm always impressed when someone like David can incorporate eccentric material in a technical presentation. His analogies range from orchestral music to how democracy evolved in the US over the past 200 years. Yet he manages to pull that material back to his main point about software development processes. I learned how to write from teachers who were firmly in the Steinbeck and Hemingway school -- say what you want to say, back it up with two or three specific examples, and move on. That's comfortable for me and safe as well; what's clever to one person can sound pedantic to another. So, I do admire folks like David who can incorporate some riffs in their material.