Agile, Waterfall… I Just Want my Damn Stuff!
Ok, we’ve gotten some of the fun geek’s stuff out of the way. One more thing I want to discuss before we dive deeper into the development process is some vocab. You are going to hear these terms, and you are going to get opinions on what is the best way to approach a development project. You should consider the opinions carefully, but the reality is if the development team that you are paying to do something is going to suggest a process you are going to use that process.
Let’s be realistic, if a developer comes to you and says that Agile is the way to build your product, are you going to question them? This is not about questioning the process of a professional and asking you to second guess what they are doing. This is a discussion of the camps, so you are aware of the fundamental differences.
There are two basic types of process. Waterfall and Iterative. I’ll describe both a little better below, but the waterfall is a process where you ask for something, and the developer goes away and brings you back, sometime later, a magic solution that is your product. An iterative process is a process where you focus on smaller tasks and complete those over time with lots of check-in and review while you build the product.
It might be helpful to think of waterfall as all or nothing and iterative as bits as you go.
To define waterfall via Wikipedia:
“The waterfall model is a relatively linear sequential design approach for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction (“downwards” like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.”
To define iterative via Wikipedia:
“Iterative development was created as a response to inefficiencies and problems found in the waterfall model.[3]
A simplified version of a typical iteration cycle in agile project management
The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during the development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made, and new functional capabilities are added.”
It’s important to know that in each of the two methods I’ve described there are MANY different approaches with adherents that follow methodologies with a religious zeal.
What you need to know, again, is that your developer will likely have a specific reason that they do things the way that they do them. And, while you don’t want to start second-guessing what they do as a process, you do want to know what the differences are so that you know how to manage your expectations and help you select the right developer, to begin with.
Two words of caution…
Everything is gray. REALLY gray.
I’ve been building things on the web since 1998. I have NEVER built a project with a company that strictly followed the philosophy that they espouse. Whether that was in-house or with a vendor. Never. It’s just not possible. So know, it will probably need to be flexible. More on that in a minute.
Zealots are annoying.
Unless they are your customers. Zealots have a way of creating division and animosity. And they are contributors to the Wizard’s Domain problem. If you are considering a zealot firm, consider what will happen when you have questions or need to make changes because of market forces, or your Aunt Mable gets sick.
How do I do it?
I love an iterative process. Something that can accommodate change and redirection. I’m less of a fan of send it away and months later get a solution. That has been a recipe for disaster for me in the past. So I like a process that has a quick check-in each week with deliverables every two weeks or so. The idea is to be discussing with the developers what you need to do and making changes as you find issues that need to be developed.
The actual process and what is used is less important to me than the need to be able to be regularly checking in and talking through the project with the development team. In my experience, this gives you the best result.
Join the Conversation
This is the from the archive of an ongoing series called Making Things That Matter. Each week I will send you an email with another step in the process of building products and launching ideas. Signup here to join the conversation.
