Agile vs Waterfall
There is much debate in project management circles around Agile vs Waterfall. Some people sit firmly in one camp and are completely unreceptive to the alternative approach. At Easyprojecthub we don’t believe it should be one or the other. Instead, we suggest the approaches are used intelligently and appropriately. Which you plump for will entirely depend on the type of project being delivered, the culture of your organisation and the skills within your team. If you’re really smart, you’ll keep an open mind and leverage appropriate bits of each approach to get your project delivered successfully. The purists might not approve of this recommendation, however we really believe that Agile vs Waterfall can evolve to become best of both.
In the rest of this Agile vs Waterfall post we’ll:
- summarise Agile and Waterfall
- give you some pros and cons of each
- talk about the bits we love and don’t like so much
- and finally give you some ideas on when you might want to use Agile and when you might want to use Waterfall
#1 Agile explained
Agile is an iterative, time-boxed approach to project delivery. Requirements and solutions evolve through collaboration between self-organising cross-functional teams.
Let’s explain that statement further:
- Agile is always ITERATIVE, so the stages of the project such as design, build and test are all run alongside one another.
- Agile has a list of everything to be delivered called a BACKLOG. The backlog is the master list of all the features to be delivered. These can be new requirements, changes to existing systems, or non-urgent issues for resolution. The features on the backlog are prioritised by someone called the PRODUCT OWNER, with the most important or urgent at the top.
- The backlog is broken down into ITERATIONS or TIMEBOXES. Each timebox has a set time and will deliver a subset of features on the backlog. The length of the timebox will depend on the complexity of the project and tasks. There are a number of techniques to help with estimation. A technique that works well for some is STORY POINTS.
Story points measure a feature’s size relative to other features. This approach provides a way of comparing the size of features to one another, so provides a relative size. Story points works well when there is insufficient information to estimate the time to build a feature. Typically you would use a scale to estimate features. The fibonacci scale (1,2,3,5,8,13…) is popular as it provides enough of a jump between numbers to encourage the opt for a particular number (rather than getting caught up in debate over small differences).
- The whole team work together to determine what will be in any given timebox.
- The team is self organising and responsible. The roles in agile vary slightly depending on which agile approach you follow, however many of the activities of a traditional project manager revert back to the team. There is a big emphasis on empowering the team to use their skills to deliver. In Scrum, which is a popular Agile approach, the role of the scrumaster is more of a coach that of a project manager.
- USER STORIES are written to describe features (not how to implement them). User stories are short, simple descriptions of a feature written from a users’ perspective. They provide just enough detail for planning & development. They are supported by discussions and conversations. User stories help keep the focus on what the user wants and needs. A timebox may contain one or more user stories.
User stories typically follow the format: As a [who is the user?], I need/want/expect to [goal] so that [reason – why does user want to achieve goal?]
- User stories are used to facilitate discussion. A top tip is to write user stories on post-it notes or cards that can be displayed and moved around to help with discussion and estimation.
- Team members SELF-SELECT tasks relevant to their skills. Again this follows the approach of a self-organising team. The intention is that the team will be most efficient if each team member is working on tasks best suited to their skill set. They are also like to be happier.
- DESIGN DOCUMENTATION sufficient to build and support the product. Documentation in Agile is simply sufficient to build and support the product. It is often light and sometimes contained within the code.
- BUILD is iterative. Typically the build in Agile will take place early, allowing end users to get a view of the product as soon as possible. In this way the product evolves with user input.
- TESTING throughout the build. Testing in Agile takes place throughout the development or build of the product, allowing early identification of issues.
- There is a daily meeting called a DAILY STAND-UP or SCRUM. This is a very focused, short meeting (15 minutes maximum) ideally held at the same time and in the same location every day. Each team member speaks in turn and states:
- What has been accomplished since the last meeting?
- What is going to be accomplished before the next meeting?
- Any issues that are preventing tasks being progressed
- The deliverables need to be ACCEPTED by the stakeholders at the end of every timebox
#2 Waterfall explained
Waterfall is a sequential method of project delivery, which generally makes it easier to understand at a high level. This also makes our section on waterfall much shorter than our section on Agile, however this does not necessarily mean that it is easier to manage a Waterfall project.
- Waterfall, delivery is broken down into distinct phases (e.g. requirements, design, build, test, deployment)
- Each phase is completed before the next is started. Typically there are ‘stage gates’ between each phase that must be passed before the team move on. Once a phase has passed it is not revisited.
- Each phase has relevant documentation associated with it, for example requirements will have requirements documentation, design will have design documentation, and so on.
- Planning is done for the overall project at the beginning. Plans for each phase should be firmed up during the previous phase and will include resource requirements and financial / funding information. For example, plans for build should be firmed up during the design phase. Passing the stage gate will be dependent on the plans being in place for the next phase.
- The stakeholders and sponsor are regularly updated on progress against plan, budget and risks to delivery.
- Testing is a formal phase done once build is complete and is broken down into stages which will include functional testing, systems testing and user acceptance testing. Testing is aligned with requirements, so that each requirement is tested and signed off.
- Changes to requirements can be accepted later in the project but must be formally controlled. All changes will need to be impact assessed to understand how they would impact the rest of the project. Changes can be declined.
- Deployment will only happen when stakeholders and sponsor have signed off final phase of testing.
#3 Agile vs Waterall – the pros and cons of each
|Changes easily can be incorporated at any point||Easy to understand, use and manage|
|Incremental delivery means end users see benefit more quickly||Has clear documentation associated with the project|
|Allows continuous improvement of systems||Issues often found early during design phase before any code written|
|Documentation can get neglected||Difficult to make changes later in the project|
|Difficult to assess the effort required at the beginning of a timebox||Nothing delivered until late in the lifecycle|
|Developers have client facing roles which they may not be trained for||Requirements must be well defined at the outset|
#4 What do we love?
The type of project, team and Client will influence the approach we take to managing a project. We’ll consider the pros and cons of Agile vs Waterfall but we’ll also look at using the elements we love regardless of the approach.
Some of the values promoted by Agile are great. They should be, and often are, employed in Waterfall. Agile makes these values very clear, and we have highlighted below the ones we particularly like and employ:
- Have a large, visible plan on the wall that the team and the stakeholders can all see and buy in to. There is something very satisfying about physically ticking of tasks and making notes with a big marker pen. This can be more difficult if the team is geographically diverse, however in this case it’s good to have an electronic version that is regularly shared via skype.
- Having buy-in from the whole team to the project and the plan is essential
- Regular communication in the form of a short daily meetings works brilliantly. It helps the team build relationships with one another, keeps everyone focused, assists in prioritising tasks and identifying potential issues early. The key to productive meetings is to have a good facilitator. You can read our post on Daily Team Meeting – 5 tips for making it count. Beyond the daily meeting it’s critical to keep your stakeholders in the loop and regularly updated. Once a week is normally enough.
- Celebrating successes throughout the project makes the team feel valued.
- Identifying and maintaining a sustainable pace of work prevents the team from burning out.
We also like some of the structure brought about by Waterfall. In particular we like:
- Ensuring that designs are signed off by stakeholders
- Sufficient documentation so that the whole team know what they are building, and is available to hand over to business as usual to enable them to support the product once it is live.
- Structured approach to testing which really gives the business confidence that the product is fit for purpose.
#5 What don’t we like?
Although an Agile project should produce sufficient documentation to support the project, it is often perceived that NO documentation is necessary. It is critical to understand, and have documented areas such as the overall technical architecture and how the product should be supported in live.
Whilst it’s inefficient to spend time producing unnecessary documentation that is never read, some documentation is essential. Identify what this is, keep it short, focused and in an easy to digest format.
We also find that true Waterfall can be too constrained. We tend to allow phases to overlap provided certain criteria are fulfilled. For example we find value in overlapping testing with build to allow earlier identification of issues.
When considering Agile vs Waterfall we will look to mitigate any downsides if appropriate.
#6 When would we recommend Agile and Waterfall?
Without a doubt, web development, app build and anything requiring a great user experience will benefit from using the Agile approach. Agile supports building prototypes and mock ups to share with the end user and refine.
Ongoing systems development can also benefit from an Agile approach. Ongoing development is best approached with a standard length timebox, for example you might carry out 6 x 5 week timeboxes in a year. Your backlog holds all the wants and needs of the customer and can be continually updated as new requirements come along. Each timebox will contain 5 weeks worth of features.
Waterfall is more suitable to environments that are risk averse and have clear requirements. It is also suitable to projects where there is likely to be little change in the requirements. Waterfall would be our preferred option where there is a level of complexity and interdependency between multiple workstreams to deliver.
Remember, Waterfall and Agile do not have to be exclusive. Intelligent project management will leverage the most appropriate parts of both approaches to achieve successful delivery.
Remember, Waterfall and Agile do not have to be exclusive. Agile vs Waterfall can become intelligent project management that leverages the most appropriate parts of both approaches to achieve successful delivery.
You can find and follow me on LinkedIn here
We love to hear your comments and really appreciate it if you share on your favourite social media platform (you’ll find the links if you scroll up or down).
Thanks for reading!