One of the hot topics in the field of project management is Agile methodology. There are many discussions about Waterfall vs Agile and which one is the better framework. The reality is that there is no better methodology. Project’s needs as well as the amount of requirement uncertainties are factors that can guide you in choosing the right methodology.
If your project has very clear requirements that are likely to remain unchanged, Waterfall can work in your favor. The Waterfall methodology includes five stages: initiation, planning, execution, monitoring and controlling, and closing.
In the initiation stage you gather the requirements of your project, identify the stakeholders, and write the charter for your project. The charter includes your business case and high level requirements that are likely to remain unchanged.
The next stage is planning. In pure waterfall, the project manager reaches out to relevant stakeholders and subject matter experts to generate a detailed plan. The detailed plan includes the work breakdown, budget, schedule, risk response plan, communication plan, human resources plan more. The justification behind spending so much time and effort to generate a granular plan is that the project requirements will probably stay the same. Therefore, it makes sense for the project plan to be comprehensive and detailed.
The execution stage and monitoring and control start and continue concurrently. Execution is merely doing the project work according to project plan. If minor changes to requirements are discovered, formal change requests are created and submitted by project manager to project sponsor for approval. Monitoring and control includes monitoring project budget, schedule, risk, scope and quality and ensuring that they don’t deviate from the project plan.
Once the project work is completed, there is a need for documentation work ranging from the sponsor sign off to gathering lessons learned. This work is captured as part of the closing stage.
Iterative waterfall suites projects that are broken down in different phases. The requirements for the first phase is clear and likely to remain the same. The subsequent phases still need time to be fully clarified. The approach to go through the five waterfall stages one phase at a time. The expectation is that by the time phase 1 is completed, the requirements for phase 2 is cleared and defined.
Hybrid Agile and Waterfall:
While not a formally defined approach, many organizations follow a hybrid version of agile and waterfall based on their needs. This happens when the project requirements are not certain enough and thus agility to accommodate for changes is needed. However, the organization has a good idea of high level requirements and wants to make sure that these requirements are met. An example of this approach may be defining the charter for the project to capture the business case and high level requirements. However, not much time is spent on the planning phase. Instead the project is divided into 2–4 weeks time intervals (referred to as sprint in agile methodology). The project team plans only for the scope of work included during this time frame. The key is to present the output of the sprint to the stakeholders and users and gain their feedback. Contingent on the feedback and other information coming into light, the next sprint is defined and worked on. This approach is continued until the project is completed. The documentation related to the closing stage is then carried over.
Agile methodology is leveraged in projects with significant uncertainties. This framework is quite popular for software development projects, in which it is impossible to know the full picture before starting the work. The project work is captured in small units called “user stories”. Each user story represents a unit of work which should be both developed and tested. Each user story includes the acceptance criteria so that the resources know the expectations in terms of both development and testing.
The user stories are written and prioritized in what is called the “project backlog”. The project backlog needs to be continuously updated as requirements come into light and priorities change. In the Scrum methodology, which is a subset of agile, the project life cycle is as follow:
Project is divided into 2–4 week periods called sprints. Over the duration of the sprint, the following scrum ceremonies occur:
Daily stand ups: Every day the entire project team meet for 15 minutes to update each other by answering three questions:
Please note that the purpose of the daily stand up is a) for the team to update each other and b) raise blockers impacting their work.
Sprint Planning: On the first day of the sprint the project team meets and picks user stories from the prioritized backlog.
Backlog Grooming: In the middle of the sprint, the project team meets for a meeting called “backlog grooming”. The purpose of the grooming meeting is to ensure that.
Demo: at the end of the sprint, the project team demos the outcome of a sprint to the stakeholders that are interested. This outcome is normally a small feature which is both developed and tested during the sprint (e.g. a drop down menu, a self automated table in a website, integration to a third party, etc). During the demo, the stakeholders provide their feedback for the project team. This feedback is crucial as it enables the project team to continue or iterate in the right direction for the subsequent sprint.
Retrospective: also, at the end of the sprint the project team meets for what is called a “retrospective meeting”. The purpose of the retrospective is for the project team to discuss:
Retrospective is an opportunity for the project team to reflect on their performance over the sprint duration and make changes that they think will help them function better in the future sprint.
One thing to note is that the project management roles and responsibilities are significantly different in Waterfall fall and agile methodologies. In pure agile, there is NO role defined as project management. Instead the responsibilities are distributed among two roles: scrum master and product owner.
Scrum master responsibilities:
It is likely that the scrum master does not have the technical knowledge to resolve these issues himself, this is fine and expected. However, it is scrum master’s responsibility to reach out to subject matter experts to resolve the blockers. For example, if an environment is down, and thus testing resources cannot test, it is scrum master’s responsibility to reach out to environment experts to have this issue resolved. If the developers cannot develop further, because the design artifacts are not clear, it is scrum master’s responsibility to reach out to the design team to ensure this issue is resolved.
Product owner responsibilities:
Please note that in pure agile whenever a story needs to be added to the sprint work in the middle of the sprint, a low priority story of the same estimate needs to be removed from the sprint work. It is the product owner’s responsibility to inform the entire project team of the change.
About the Author:Yosef Falsafi is an experienced Scrum Maser and Project Manager. Yosef’s passion is helping companies better manage their journey from Waterfall to Agile methodology. Equipped with PMP, CSM, Lean Greenbelt as well as an MBA degree, Yosef looks at firms’ project management practices from a holistic angle to optimize diverse organizational elements the project needs in order to create value.