One of the most popular blogs we’ve ever posted concerns our web development process. Since 13 months can be a lifetime in the wonderful world of the internet, I thought that we’d revisit the topic. While our methodology hasn’t changed a bit in all that time, our experiences have brought greater enlightenment.
Agile
Let’s begin with the heart of our process, which is the Agile project management approach. When we approach a project using the Agile method, we begin with the philosophy that the end result can’t really be known until the project is completed. That is, changes during the development process are inevitable. Indeed, the bigger the project, the more undefined the final deliverable becomes. We recognize that each step along the path to the end result could bog us down or, at the very least, alter the finished product in some unforeseeable way. It’s going to be a website on the internet. That is the only certainty on day one.
Agile is a methodology which, when well executed, ensures team coordination and efficiency, budgets are contained, and the client can more easily follow the progress. Under this method, smaller code sprints are called for, and daily scrum meetings ensure team coordination and collaboration. This process makes it easier to add features or aspects either the team, or the client, realizes should be added. Clients appreciate the flexibility. We’ve seen, however, that if this process goes unchecked it can also lead to endless cycles of code sprints without ever reaching a product launch. It reminds me of Lieutenant Columbo, the old Peter Falk character on television, who would start to exit, only to turn and say, ‘Just one more thing’_’
Pros
- Perfect for dynamic businesses
- Rapid development at a lower cost
- Ensures team coordination
- Solution constantly evolves to meet client needs
Cons
- Can create a never ending loop on the project
- End project can be completely different from the original task
- Can run over budget if mismanaged
Waterfall
Before Agile became so popular, teams practiced the Waterfall system. This is a more sequential approach to development. It requires intensive upfront planning to ensure that intricate details are accounted for and aren’t discovered midstream in the project. When done well, this approach can lead to a faster project launch, the client understands what is being launched before development even begins, and project budgets can be more accurately estimated.
However, this process design also comes with its own set of problems. Modifications and adjustments become difficult. Projects have to anticipate a client’s evolving needs. Re-entering a waterfall process over and over because of a continually evolving business can cause a project to head over budget.
Pros
- Faster project launch
- Client understands project
- Project budgets are more accurately estimated
Cons
- Longer planning phase
- Not the best for evolving needs
- Changes in project can cause budgetary and deadline issues
Wagilfall
Ultimately, we have found an ideal system we’ve labeled as Wagilfall. In working with clients such as Epsilon Agility Harmony, we recognized that spending the appropriate effort in a planning exercise could only take us just so far. Once the planning is complete, if new ideas/features come up during the development cycle, unless it is mandatory for the initial project launch, we’ll add it to a bucket list. Our goal is to get our clients to a point where we can launch the product as quickly and efficiently as possible in order to get revenue generation activities initiated. The project then evolves into an Agile approach which will enhance the site, and add those bucket list items in response to the client’s needs. Here’s how our process looks.
Two key components to this process are to understand the long term goals of the site, but also prioritizing its early phase scope needed for launch. The appropriate technology or framework needs to be chosen in order to provide the required level of scalability to adapt to the needs later defined by an evolving market need, as with any Agile process. Additionally, everything in the early phases should be limited to the key business drivers to keep it manageable in a waterfall process.
We want to hear what you think. Clearly, based on the response to the original version of this blog, the topic has resonated with many. Is there an approach you have used in the past that worked/didn’t work? Why?
