Agile, Wagile or Waterfall?
In an earlier post, we wrote about managing Agile teams in the constantly shifting landscape of software development.
In this article, we’d like to talk about the development approaches we use for our projects - is it only Agile, Waterfall or a bit of both?
Before we go further, here are some assumptions about each:
- Agile is used for a large or complex project which gets broken down into multiple phases. Each phase would go cycle through design, development, testing and deployment. It’s an iterative approach meaning we’re constantly improving an application bit by bit.
- Waterfall usually applies to projects with just one deployment at the end, for example when we build a website. Each phase (planning, design, development, testing and deployment) needs to be client-approved before we move to the next one.
- Wagile means a Waterfall/Agile hybrid approach - quite common for campaign-led jobs for us.
Turns out at Pattern, we use all of the above.
We use Agile for product-type projects that organically evolve over time. Potentially we would have built and launched a product, then we work on new features or improvements post-launch to improve the application over time. We can be cycling through development, testing and go-live fairly regularly for a single feature.
We use Waterfall for projects that have very specific requirements and clear deadlines. While milestones can shift, the project goes through its planning, design, development, testing and deployment phases in a very linear fashion.
Wagile comes into play with jobs that are linked to deadline driven campaigns. There are usually multiple dependencies due to the collaboration required with external parties and reliance on third party platforms. These jobs start off with a Waterfall approach: there’s a planning meeting, followed by a brief and design. As we move into development, things start to morph at pace. This is when the job turns Agile: we have to iterate quickly to deliver the desired result.