Waterfall-Agile Spectrum

Yosef Falsafi

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.

Pure Waterfall:

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:

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:

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:

  1. What did I do yesterday?
  2. What will I do today?
  3. What are the impediments and blockers affecting my work?

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.

  1. All the user stories in the backlog that are likely to be worked on in the subsequent sprint are clear to the project team.
  2. Additional information, enhancements, acceptance criteria corrections are accommodated.
  3. All the user stories are estimated by the project team in terms of effort.

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:

  • What went well
  • What could have been done better
  • What can start or stop to help the team function better.

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:

  1. Coaching the entire project team on agile methodologies, ensuring everyone knows what is the purpose of each sprint, ensuring everyone is aligned on how does estimation work and other related methodology coaching.
  2. Facilitating all the scrum ceremonies explained above (daily stand ups, sprint planning, backlog grooming, demo, and retrospectives). At times there may be need for ad-hoc meetings and sync ups. Scrum master is responsible to ensure that this happens.
  3. Documenting retrospective action items and ensuring that they are completed in a timely manner.
  4. Documenting and communicating project teams’ agreements and standards.
  5. Analyzing project team’s performance every sprint and inform them of the result. Also, recommending ways the team can improve the performance.
  6. Ensuring that daily stand ups stay to the points. If there is further discussion needed for a topic, it is scrum master’s responsibility to ensure that the conversation happens after the stand up and among all relevant parties.
  7. Removing impediments and blockers. Impediments and blockers can be identified in daily stand ups as well as in other occasions. It is crucial that the scrum master acts on removing the blockers as soon as they are raised.

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:

  1. Creating user stories and bringing them to the backlog grooming
  2. Adding the corrections, enhancements and estimates to the user stories during the grooming sessions
  3. Keeping the backlog organized based on priorities
  4. Informing the project team as the priorities change
  5. Answering questions on product/business needs of user stories
  6. Informing the project team whenever a story is added to the sprint work mid-sprint
  7. Informing the project team whenever a story has been removed from the sprint work

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.