What happens when the shoe doesn't fit?
Our firm does a significant amount of user experience and graphic design work. I don't have a background in either (although I can draw a pretty kick ass circle), but it's neat to see how the folks with training in creative design go about their work.
We've always described our employees and our approach as "pragmatic", and the graphic artists we employ are among the most pragmatic of the bunch. They don't necessarily work faster than the ladies and gents who focus on application development, but they follow a process and rarely waste cycles. What's more, the rigor they employ doesn't crimp their creativity. And even though they work on a wide variety of projects, they're always efficient. Their process amounts to what I'd consider a methodology, and the first step in their methodology is "figure out what's going to work for this project."
That's different from the typical line-of-business application project that adopts one of two approaches: the Screw Process! (or "Two Dudes") approach or the Process Rules! approach. I think most people will agree that the "Two Dudes" approach rarely ends in success. But what about projects where the team conforms rigidly to a methodology? Isn't that supposed to ensure success?
In my experience, the Process Rules! projects succeed much less often than you'd expect. It's not because the team is following a process. It's because they're following the wrong process.
Re-read the second paragraph. Process is important, but the same steps won't solve every problem. Seems obvious, right? But that's what people often try to do with software development. They don't consider which methodologies are well-suited for their project (mistake #1); they use the methodology "as is" (mistake #2); they punish people who veer from the prescribed steps even when it yields better results (mistake #3). In short, they get hung up on the methodology.
Successful software development teams:
- Involve smart people. This is so important. More on that in another post.
- Consider the project's characteristics and determine which methodologies are geared toward their project's success factors and limitations.
- Use a methodology as a starting point but customize it for their project.
- Adapt midstream if something isn't working.
- Mix methodologies. Specifically, they combine concepts from several methodologies. 80% XP and 20% Scrum? That can work.
- Repeat these steps on all projects.
I understand why teams take a liking to pre-packaged methodologies. People assume strict adherence to a process lowers risk, and that's often true when you're dealing with repetitive tasks like disarming bombs or shutting down a nuclear reactor. If you modify or stray from the process, you increase risk (ironically, concepts common to many methodologies and the ones with which I agree the most - notably, that it's tough to predict the cost/duration of a project up front; that it's possible to gather all requirements up front - are often seen by "management" as the worst parts of a methodology and, as such, are ignored). But software development isn't a repeatable process.
When a potential client asks us to describe our methodology, we
generally tell them we need more information before we can
determine the right approach. Does XP make sense in this case? Will
Scrum help us? We didn't invent this. I've talked to dozens of
successful people and heard countless successful business leaders
speak, and they all say the same thing: when faced with a problem, they
figured out what was going to work for them even if it broke some rules. I'm not suggesting teams need to reinvent the wheel. Methodologies like XP, Scrum, RUP, Iterative, Spiral and "Agile" are based around solid ideals. They just don't work "as is" in every case.