I love studying software development methodologies. After all, what is a methodology? It's someone's attempt to draw on past experiences to define a systematic process that will lead to fewer mistakes in the future. That's not Webster's definition, its mine. Most everyone else would probably mention "repeatable success" in their definition. I like mine better because I'll let you in on a little secret… are you ready… here it is… making good software is hard. And no methodology alone will lead to repeatable success. At the very least a critical analysis of every completed project should be done, and your methodology tweaked from lessons learned. The trouble is, too many teams don't even bother to do that. Critical self reflection is not something we as humans do very well.
Don't read me wrong, software teams need to follow a methodology, whether it's your own or someone else's. And there are no shortage of documented methodologies for you to choose from; Waterfall, Agile, Extreme, Scrum, RUP, Adaptive Software Development, Lean Development, to name a few. While repeatable success with an arbitrary team is the goal of a methodology, it is a lofty goal. My own experience says success is dependent more on people than methodology. This explains why some teams inexplicably succeed without any identifiable methodology. Good teams do their very best to improve with each project, and as a result their methodology improves.
Through the years I've been involved with many projects in varying capacities that utilized recognizable methodologies. I have my favorites, as I am sure you do. Methodologies are a lot like politics. You have extremes in Waterfall and Extreme Programming, with overzealous advocates who seem to shout with the loudest voices. And as with politics, the majority of us advocate for something somewhere in the middle. When I compare methodologies across the spectrum, the most significant difference between them is the degree of iteration. Software, by its very nature, is iterative. Something as abstract as software must be iterative. For most non-trivial software systems, you have to build it before you see its flaws, and I'm not talking about bugs. Conceptual flaws that are hard to foresee. Make no mistake; it's the risk of conceptual flaws that iterative software development seeks to mitigate. This necessity is all too often cloaked by descriptions of being "adaptive to change" in business. Business does not change near as fast as our perception or understanding of the business. And if you are building software, you are likely trying to automate, streamline, be more efficient/responsive, analyze, quantify, evaluate. For any of these business goals you better darn well know exactly what you are trying to accomplish before you try to create software. Far too many projects start without this understanding.
So how do you gain this understanding and build software that works? Iterations. For businesses that are well understood, methodologies with fewer iterations will work, regardless of the goal of the software, or even the size (in development effort). This is because a good, unambiguous specification can be written about something that is well understood. And developers can write good software from good unambiguous specifications. But without complete understanding, any software development process with few iterations will likely fail, and that is because the spec will not be very good. You just can't spec a process that is not well understood. The team will try, they will fill a document full, review it, and sign off on it because it will mention enough of what the decision makers really want out of this new software system. The developers will get it, scratch their head, ask a lot of questions, and then go build software, most likely filled with many conceptual mistakes. These projects performed in a Waterfall type methodology will always fail. When the software is delivered, it will be all wrong, and even if management is steadfast and funds the corrective iteration that fixes the software, the project will cost twice as much as forecast and will still be considered a failure. The less understood the business, the more iterations you need. If only it were all just about creating good software…
Managers and decision makers want to know how much a software project is going to cost. How much money will you spend up front just to gauge the risk? How solid are your estimates? Methodologies play a big part in these discussions as well. Folks I don't care who tells you otherwise, any software estimate made without a complete written spec is not an estimate at all. It is a guess. Sure, the more you guess the better you get at it, but dispense with the baloney and call it what it is. There is a reason why software estimating is often referred to as a Black Art. Software is extremely expensive to create and business people don't like to take risks based on a guess. Software methodologies must not only attempt to manage creating the right software, but it must also manage time and dollar estimates.
So how do you determine the best methodology? For established, continuous development software teams, I think it is their methodology. Sure they may have started from a known base, but with every development project they refine and improve to fit their product, environment, and people. So it is their methodology. But for new project development and consulting teams, what you do must be based on the specific project and its goals. For well known business practices, a methodology with fewer iterations and a heavy up-front specification process is best. These types of business scenarios are really easy for an analyst to identify too. Here's a real quick litmus test. Can the subject matter experts answer your questions clearly? Does every answer start with "that depends on…"? Ask three subject matter experts the same question, and compare their answers. For projects where the goals are less understood, go agile. And that means more iterations. Spec-code-test, do it again. This works because subject matter experts can see, drive, and evaluate software so much better than they can a spec doc. So give them software and then ask what needs to be changed and added. Do this enough times and you'll end up with conceptually correct software. Of course this too is dependent on the subject matter experts actually taking the time to perform an honest review. It pains me to say, but sometimes even that is extremely difficult to get accomplished. And without it, agile is no better than waterfall, at least from the goal of conceptual accuracy and risk mitigation. Everyone is busy this is true, but building good software is a team sport, and everyone on the team must play in order to achieve success.
So what does all this mean? Adopt a methodology that matches the business understanding of the project. Think in degrees of iteration. For most new software I tend to lean towards agile approaches, but don't get caught renaming your utter lack of any methodology for being agile. This is way too common. For well known business goals or projects porting legacy systems to newer technology, I would lean towards an approach with fewer iterations. There's very little risk there, so take the time to write a single complete spec. For your upfront efforts you'll end up spending less money in development.
Regardless of your chosen methodology, here is what you need to create conceptually accurate software.
Do you have a spec? Any Spec? If not, you don't have a methodology you are flying by the seat of your pants. Weekly meetings, heck daily meetings, and whiteboards are fine, as long as the decisions are captured in the written word. If chicken scratch on the back of a Quiznos napkin is the best you can muster, photocopy it and distribute it to the folks that are going to create the code. You'll end up spending less on development for your efforts.
Get the reviews. People prefer to review software over documents. After distributing a specification doc, I once received feedback from a guy that our client identified as a subject matter expert for review purposes. His feedback was, "It's difficult for me to determine if this would work or not based on this document, so I'll have to reserve judgment until I see the software." Gee, thanks for the help. I asked for a new subject matter expert. You need that feedback though, so get it any way you can. The analyst or developer who thinks they know more than the client does is in dangerous peril. Ask yourself who are you are building the software for and who will determine whether it is right or wrong?
Software development methodologies exist to help us succeed in a difficult endeavor. They are no silver bullet, but just making an attempt to learn from past experiences and applying those lessons learned in future work will lead to greater software success.