In January, I had the privilege of participating in a panel at Agile Austin with executives leading other software organizations around Austin. David Anderson also dropped in while he was in Austin.
Throughout the question & answer session, one theme became clear. The audience wasn’t clear on what agile is and what agile is not. So many folks have attended Scrum training that I think I can comment on what is being taught (caveat: each Scrum trainer does it a bit differently).
The most popular agile training is Scrum training. In scrum training, there is a lot of talk about the development team, the product owner, and the scrum master. There isn’t, however, a lot of talk about management. The scrum master is not a manager. It is intentionally defined as a facilitator who has to facilitate without direct authority. Every organization has management, however, but Scrum doesn’t really speak to that. I think this is a big gap with it. Extreme Programming doesn’t either, but it doesn’t pretend to be a project management methodology.
Agile is all about delivering frequently and refining as you go. Agile doesn’t have a set of dogmatic practices that you must adhere to. Every agile team will have a process that is unique because each has different business goals and different people. The team needs process. Larger projects need larger processes. Whole Foods is a very agile organization, and it has tons of processes to make it all work seamlessly. I have encountered some who feel that agile teams have to light on process. I believe that the team needs just enough process, and it’s probably just a bit more process than the average “Certified ScrumMaster” would think.
By now, we have all heard stories about the “agile” teams who adopted scrum and then subsequently burned through a year’s worth of sprints and still delivered nothing. The magic fairy dust of scrum is wearing off, and the industry is starting to realize that in any given project, success depends on the good and passionate work of the people involved.
All in all, it doesn’t matter where good ideas come from: waterfall, scrum, extreme programming, lean, FDD, or the next methodology that comes along. Good ideas are good ideas, and I strive to find them wherever I can.
Practical agile software delivery is hard. HARD. It requires confronting problems head-on, even when those problems are organizational. Short iterations expose the problems. Solving the problems makes them go away. The absence of problems leads to effectiveness. Rinse, repeat. A project will succeed or fail based on the people involved, not the “official methodology” used in the status report.