April 1, 2011

Agile Road Show: Day 3


On the third and final day of the Agile Road Show, David and the rest of us have been refining our messages a bit. One thing that David mentioned today really hit home with me. He's an Agile coach, but he's been in large companies, implementing Agile to increase business value in real environments. He said that he tries to avoid getting hung up on Agile terminology. If you're meeting with the business managers, this sentence won't have much meaning:

"The scrum master is grooming the backlog to make sure all the personas are represented in the sprint."

But this would make sense:

"The project coach is making sure that the customer needs are captured in the next iteration."

To those of us immersed in the software world, either version sounds about the same. But we have to be sensitive to the fact that technical jargon can obscure the message when talking to the other parts of the company.

I always prefer practical, simple language, so I really appreciate his point. The whole point of Agile is rapid, purposeful change - knowing what to build and how to build it quickly and effectively. Focus on that, and you'll get the business value that Agile delivers, whether you call it a scrum or just a daily meeting.

This Road Show has been a great experience. Working with David and the folks from VersionOne, KlocWork, and Electric Cloud, I think we're all aiming to help teams be successful as they try to adopt Agile for real, complex products. Scaling Agile for large teams located at several sites is difficult. That's something we've always recognized at Perforce, and our tools are always built with the idea that a small team of 10 developers in one office can grow to be a team of 200 developers in three offices.

Building tools that scale well isn't always easy. For instance, sometimes folks in a training class will ask me why setting up a Perforce workspace isn't as simple as just running a 'checkout' command. If you have a small, simple project, that's a legitimate question. But most projects end up being complex. Your source code may have dependencies on modules from other teams, stored in other parts of the repository. So a Perforce workspace gives you the tools to assemble a coherent working copy of your product that maps in dependencies from the right places. We do recognize that ease of use is part of scalability, of course, and that's why Perforce streams will automate some of the branch and workspace management.

Well, that's about all for now. Back up to the Perfortress tomorrow, where I'll start thinking about my presentation for the user conference.