Search

Waterfall Vs Agile – Must Know Differences

In this article, my focus is to the bring out the differences between Waterfall and Agile methodologies based on my experience as a PMP® and Agile Coach.  What will you learn in this article? In this article, you will learn the definition of Waterfall and Agile, key differences between the two, advantages and limitations of each, how to make the right choice for your project and an example on Waterfall and Agile methods. What is Waterfall Methodology?  “The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, although Royce did not use the term waterfall in that article….The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer” This methodology describes a linear and sequential approach to Software Development. It is termed “Waterfall” as the life cycle phases in the Software Development cascade from one phase to another systematically from top to bottom. After the completion of every phase, the subsequent phase is expected to start and there is a stage-gate or kill-point review at the end of each phase. Progress of the project is evaluated during this stage-gate review and the decision is made to continue to the next phase or cancel the project. For example, the entire requirements for the project are elicited by the project team from the stakeholders and documented. The team can proceed to the next phase –Design- only after the evaluation of the requirements during the stage-gate review is completed, and a “Go” decision is made. This is also known as Traditional or Predictive approach in project management, as it applies a predictive planning strategy which uses baselines and milestones to control the project.  What is Agile Methodology? “The appearance of Agile methods has been the most noticeable change to software process thinking in the last fifteen years [16], but in fact many of the “Agile ideas” have been around since 70’s or even before. Many studies and reviews have been conducted about Agile methods which ascribe their emergence as a reaction against traditional methods” This approach of software development is also known as Adaptive approach. Agile Methodology promotes an iterative & incremental approach throughout the entire software development life cycle of the project. This focuses on the values and principles defined in the Agile Manifesto which states Agile Manifesto: Individuals and Interactions over processes and tools Working Software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace, indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity–the art of maximizing the amount of work not done–is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. Key differences between Waterfall and Agile MethodologyRequirements: In traditional approach, an extensive business analysis is performed (typically by the business analyst) in order to meet the requirements of the product, service or result. Requirements are fully documented and signed off by the key stakeholders. The business analyst walks through the requirements to the project team which then performs the design, development and testing of those requirements. Since requirements are elicited at the beginning of the project and subsequently baselined, it is possible that requirements may decay over a period as the business dynamics keep changing in today’s world. In Adaptive approach, the requirements are progressively elaborated and stored in the requirements backlog or product backlog. They are stored in the form of Epics/Features/User Stories in the product backlog.  The entire agile team collaborates on grooming the requirements later.   Responding to Changes: Waterfall methodology tries to control the amount of change within a project. It is very rigid to any change in the project and has to go through a process of change requests. Change management plan is well defined to handle any change in a systematic manner to avoid scope creep or gold plating (doing something extra for the customer without them actually asking for it). Welcome change is a powerful tool in adaptive approach. The agile approach to planning, executing, prioritizing, grooming etc allows the agile team to respond to change quickly. Changes are considered as opportunities to provide value to the customer. Please note “responding” to changes does not mean “accepting” all the changes. It is rather “welcome changes” as the agile team collaborates with the customer more from the value perspective.  Project Team: There is no specific team size limit in the traditional approach. It can go from a few team members to hundreds in a huge project. This limits the collaboration between the individuals involved in the project, especially in a big-sized team. Team members may be allocated from different functional units and may not be seated together. In Agile methodology, team size is limited to achieve high collaboration through co-location (team sitting together in the same workspace). Each agile team comprises of a cross-functional team who can produce a working software increment in every iteration. Development Life Cycle: In Waterfall methodology, the software development life cycle goes through a series of phases like requirements, design, coding, testing and UAT, sequentially. The entire product or working software is available at the end of the project phase. In Agile methodology, the development happens in iterations/sprints, and the duration of the iterations ranges from two weeks to a month. The phases of analysis, design and development happens within an iteration and the team is able to produce a working software increment in every iteration. Feedback cycle: In Waterfall methodology, the feedback of the project is received at the end of the project when the customer conducts the validate scope process (UAT). In Agile methodology, feedback of the increment is received by the team at the end of every iteration. Multiple feedback loops provide opportunities for the team to learn quickly. Testing: In waterfall methodology, testing cycle or phase starts after the development phase is completed. Test plans are finalized at the beginning of the project and test cases are written for the product of the project while the development is in progress. Development and test teams are looked at separately within a project team. In Agile methodology, every iteration planning includes planning for test and test cases are written for those prioritized features or stories for every iteration. Testers and coders work in an integrated manner to deliver the product increment. Focus: In waterfall methodology, the focus is more on producing the project deliverable as defined and baselined. In Agile methodology, the focus is more on collaborating with the customer and welcoming changes that provide value to the customer. Documentation: In waterfall methodology, due importance is given to formalized documentation which helps in monitoring and controlling of the project for the project manager. In Agile methodology, minimal documentation is prescribed as working software is preferred over comprehensive documentation (as per Agile Manifesto). Roles: In waterfall methodology, there can be many roles defined like Project Manager, team lead, developer, tester, business analyst, design architect, quality analyst etc., In Agile methodology, roles are very limited. Especially in Scrum framework, there are only 3 roles. Scrum Master, Product Owner and Development Team (cross functional team). Project Management: In Waterfall methodology, project manager is responsible for managing the project and is accountable for the entire project. Project manager manages the project team by assigning work to the team members and getting the task done. In other words, project manager “pushes” the work to the team. In Agile methodology, the team manages the project themselves as they are a self-organizing team. The team “pulls” the work from the product backlog into the iteration backlog. Team Empowerment: In waterfall methodology, the project manager is directly answerable for the outcome of the project and team members are not empowered to take decisions. In Agile methodology, the agile team is empowered to take decisions and hence they are collectively accountable for the outcome of the project. Project Metrics: In waterfall methodology, the project team measures the project progress using techniques like Earned Value Management and Schedule compression to compress the schedule in case of any deviations. In Agile methodology, the metrics are derived in terms of velocity (how many story points the team produced during an increment cycle) and other metrics like sprint burndown/burnup charts to monitor daily progress within an iteration. Advantages and Limitations of Waterfall MethodologyAdvantages:Ability to apply due diligence in planning for well-defined requirements and scope Dependencies are managed effectively as the entire requirements are known well in advance Well defined processes pave the way for quality deliverables Phase-gate reviews allow stakeholders to eliminate any ad-hoc changes and unplanned additions to the project Works well for small projects for a well-defined requirement that is very well understood, and is not likely to change over the duration of the project Avoids scope creep with systematic implementation of change management process Simple and easy to understand Scope, time and cost baseline helps the management to monitor and control the project accordingly Limitations:Requirements are expected to be defined well prior to development which delays the project Less flexibility in changes makes it difficult to manage Feedback is received from the customer at the end of the project and hence any negative feedback or defects proves costly for the team to fix  Does not accommodate any changes due to market dynamics and its rigid approach to changes Cost of change is more as the defect is identified by the customer at the end of the project Ineffective team collaboration as the team works in silos (dev, testing etc) Integration is considered at the end and that prevents identification of any technical or business bottleneck Advantages and limitations of Agile MethodologyAdvantagesFocusses on business value as developers and business work together Stakeholders are engaged effectively in every iteration Motivated and self-organizing teams that manage themselves Predictable and ensures less variations in the project Harnesses change and is more customer centric Working software is the measure of progress. Feedback is received from the key stakeholder during every iteration and the cost of change is very less Teams retrospect every iteration to look at improvement areas and finetune themselves Provides transparency through the process Focuses on Minimum Viable Product to release to the customer Due attention is paid to specific customer needs and changes are accommodated even late in development Limitations Not suitable for all types of projects May not work well in a large traditional organization due to its flexible and less formal processes Minimal depth in requirement analysis and frequent planning may derail the end project goals Self-organizing and empowering teams solely depends on team’s maturity level at handling decisions and may backfire Working software over comprehensive documentation is misunderstood and hence teams may not focus even on necessary documentation that is required Waterfall vs Agile Methodology – Which is right for your project? A typical question that is raised before the software development starts is “which approach should we follow, Waterfall or Agile?”   The following table can be used to determine the approach (please note all the factors do not carry equal weightage)     Waterfall (works)Agile (works)Well defined scope and changes are very limitedScope/FeaturesWhen scope is not known in advance or changes are expected as the project moves onWhen uncertainty is low and low-level riskRiskWhen uncertainty is high and high-level riskWhen market is stableMarket dependencyWhen market dynamics change/evolve frequentlyWhen customer involvement is required only at certain milestonesCustomer FeedbackWhen customer is available and requires involvement throughout the projectWhen the focus is on planning, monitoring and control and predictabilityFocusWhen the focus is on innovationWhen conforming to requirements as agreed upon in the contractProduct FeaturesWhen minimum viable product (which gives more value to the customer) is implemented first and we can implement the low valued features laterWhen a large sized team with minimal collaboration or handoff is requiredTeamWhen small team with high collaboration is requiredWhen the budget is fixedFundingWhen the budget is not a constraintWhen it is less important and not urgentTime to MarketWhen it is critical, important, and urgent to meet the desired outcomeExamples of Agile vs Waterfall: How is the software developed?  Waterfall Methodology: (example) Scope: To provide an employee timesheet software having the following features: Ability to login Ability for the employees to describe the task and enter the number of hours spent Ability to submit for approval to the manager Manager Ability to login Ability to add a resource to a project Ability to link project to a resource Ability to assign task to a resource Ability to approve/reject the timesheet Administrator Ability to login Ability to add/modify/delete users  Ability to add/modify/delete projects Reports Report on individual user timesheet data for a specified period Report on project timesheet data for a specified period Report on approved/rejected timesheets for a project for a specified period Let us assume the above is the scope and timeline for completion is given as 6 months. Requirements Phase: Detailed requirements on individual features are discussed and elicited from the stakeholders until they are well understood and documented. The requirements document is then signed off by the customer. Scope is identified and baselined during this phase. Project manager comes out with the detailed plan for the entire project and assigns team members accordingly to perform the task. The scope, schedule and cost are baselined considering all the other project constraints like resources, quality, risks, stakeholders, communication etc. Design and Development Phase: Development team works on design and coding all the requirements stated above and delivers to the testing team. Testing phase: Testing team validates the deliverables to see whether they conform to the requirements. They raise defects and the development team works on them. Testing team signs off on the deliverables once they work as per the requirements. UAT Phase: Customer validates the deliverables and signs off. Raises defects in case there are issues or requirements are not meeting the expectations Agile Methodology: (example) Scope: To provide the following features for an ATM Cash withdrawal Check balance Change ATM Pin Print statements Deposit Cash Deposit Cheque Product owner elicits high level requirements from the stakeholders and documents them in the form of features/user stories in the product backlog. Product Owner then prioritizes the features based on value that can be realized by the customer. Minimum viable product is finalized. 80/20 rule may be applied to find which 20% of the features give 80% value to the customer. In this case, Cash withdrawal and Check balance features are selected as the first increment to be implemented. Agile dev team along with the Product Owner sizes the features and stories and comes up with the release planning for the MVP identified. Product owner grooms and prioritizes the user stories in the product backlog. Agile team pulls the work in the iteration backlog and starts defining goals for every iteration until the features are completed. Meanwhile Product Owner continues to progressively elaborate the requirements for other features. Key business stakeholders, along with the Product Owner review the product increment created by the agile team and provide feedback. The team retrospect after each iteration with respect to people, process and product and finetunes accordingly. This iteration cycle goes on until the first implementation is complete and then the agile team takes up the next available set of features. Summary:As we have seen, Waterfall and Agile methodologies have their own set of advantages and limitations. While waterfall approach is more methodical and predictive, agile approach is more adaptive and dynamic in nature. Depending on the project circumstances and using the table provided under Waterfall vs Agile Methodology, the project team can decide which works better for them. 

Waterfall Vs Agile – Must Know Differences

9K
Waterfall Vs Agile – Must Know Differences

In this article, my focus is to the bring out the differences between Waterfall and Agile methodologies based on my experience as a PMP® and Agile Coach.  

What will you learn in this article? 

In this article, you will learn the definition of Waterfall and Agile, key differences between the two, advantages and limitations of each, how to make the right choice for your project and an example on Waterfall and Agile methods. 

What is Waterfall Methodology?  

“The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, although Royce did not use the term waterfall in that article….The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer” 

What is Waterfall Methodology

This methodology describes a linear and sequential approach to Software Development. It is termed “Waterfall” as the life cycle phases in the Software Development cascade from one phase to another systematically from top to bottom. After the completion of every phase, the subsequent phase is expected to start and there is a stage-gate or kill-point review at the end of each phase. Progress of the project is evaluated during this stage-gate review and the decision is made to continue to the next phase or cancel the project. For example, the entire requirements for the project are elicited by the project team from the stakeholders and documented. The team can proceed to the next phase –Design- only after the evaluation of the requirements during the stage-gate review is completedand a “Go” decision is made. 

This is also known as Traditional or Predictive approach in project management, as it applies a predictive planning strategy which uses baselines and milestones to control the project.  

predictive planning strategyWhat is Agile Methodology? 

“The appearance of Agile methods has been the most noticeable change to software process thinking in the last fifteen years [16], but in fact many of the “Agile ideas” have been around since 70’s or even before. Many studies and reviews have been conducted about Agile methods which ascribe their emergence as a reaction against traditional methods” 

This approach of software development is also known as Adaptive approach. Agile Methodology promotes an iterative & incremental approach throughout the entire software development life cycle of the project. This focuses on the values and principles defined in the Agile Manifesto which states 

Agile Manifesto: 

  • Individuals and Interactions over processes and tools 
  • Working Software over comprehensive documentation 
  • Customer collaboration over contract negotiation 
  • Responding to change over following a plan 

Principles: 

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 
  4. Business people and developers must work together daily throughout the project. 
  5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. 
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 
  7. Working software is the primary measure of progress. 
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace, indefinitely. 
  9. Continuous attention to technical excellence and good design enhances agility. 
  10. Simplicity–the art of maximizing the amount of work not done–is essential. 
  11. The best architectures, requirements, and designs emerge from self-organizing teams. 
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. 

Key differences between Waterfall and Agile Methodology

Agile VS Waterfall

Requirements: 

In traditional approach, an extensive business analysis is performed (typically by the business analyst) in order to meet the requirements of the product, service or result. Requirements are fully documented and signed off by the key stakeholders. The business analyst walks through the requirements to the project team which then performs the design, development and testing of those requirements. 

Since requirements are elicited at the beginning of the project and subsequently baselined, it is possible that requirements may decay over a period as the business dynamics keep changing in today’s world. 

In Adaptive approach, the requirements are progressively elaborated and stored in the requirements backlog or product backlog. They are stored in the form of Epics/Features/User Stories in the product backlog.  The entire agile team collaborates on grooming the requirements later.   

Responding to Changes: 

Waterfall methodology tries to control the amount of change within a project. It is very rigid to any change in the project and has to go through a process of change requests. Change management plan is well defined to handle any change in a systematic manner to avoid scope creep or gold plating (doing something extra for the customer without them actually asking for it). 

Welcome change is a powerful tool in adaptive approach. The agile approach to planning, executing, prioritizing, grooming etc allows the agile team to respond to change quickly. Changes are considered as opportunities to provide value to the customer. Please note “responding” to changes does not mean “accepting” all the changes. It is rather “welcome changes” as the agile team collaborates with the customer more from the value perspective.  

Project Team: 

There is no specific team size limit in the traditional approach. It can go from a few team members to hundreds in a huge project. This limits the collaboration between the individuals involved in the project, especially in a big-sized team. Team members may be allocated from different functional units and may not be seated together. 

In Agile methodology, team size is limited to achieve high collaboration through co-location (team sitting together in the same workspace). Each agile team comprises of cross-functional team who can produce a working software increment in every iteration. 

Development Life Cycle: 

In Waterfall methodology, the software development life cycle goes through a series of phases like requirements, design, coding, testing and UAT, sequentially. The entire product or working software is available at the end of the project phase. 

In Agile methodology, the development happens in iterations/sprints, and the duration of the iterations ranges from two weeks to a month. The phases of analysis, design and development happens within an iteration and the team is able to produce working software increment in every iteration. 

Feedback cycle: 

In Waterfall methodology, the feedback of the project is received at the end of the project when the customer conducts the validate scope process (UAT). 

In Agile methodology, feedback of the increment is received by the team at the end of every iteration. Multiple feedback loops provide opportunities for the team to learn quickly. 

Testing: 

In waterfall methodology, testing cycle or phase starts after the development phase is completed. Test plans are finalized at the beginning of the project and test cases are written for the product of the project while the development is in progress. Development and test teams are looked at separately within a project team. 

In Agile methodology, every iteration planning includes planning for test and test cases are written for those prioritized features or stories for every iteration. Testers and coders work in an integrated manner to deliver the product increment. 

Focus: 

In waterfall methodology, the focus is more on producing the project deliverable as defined and baselined. 

In Agile methodology, the focus is more on collaborating with the customer and welcoming changes that provide value to the customer. 

Documentation: 

In waterfall methodology, due importance is given to formalized documentation which helps in monitoring and controlling of the project for the project manager. 

In Agile methodology, minimal documentation is prescribed as working software is preferred over comprehensive documentation (as per Agile Manifesto). 

Roles: 

In waterfall methodology, there can be many roles defined like Project Manager, team lead, developer, tester, business analyst, design architect, quality analyst etc., 

In Agile methodology, roles are very limited. Especially in Scrum framework, there are only 3 roles. Scrum Master, Product Owner and Development Team (cross functional team). 

Project Management: 

In Waterfall methodology, project manager is responsible for managing the project and is accountable for the entire project. Project manager manages the project team by assigning work to the team members and getting the task done. In other words, project manager “pushes” the work to the team. 

In Agile methodology, the team manages the project themselves as they are self-organizing team. The team “pulls” the work from the product backlog into the iteration backlog. 

Team Empowerment: 

In waterfall methodology, the project manager is directly answerable for the outcome of the project and team members are not empowered to take decisions. 

In Agile methodology, the agile team is empowered to take decisions and hence they are collectively accountable for the outcome of the project. 

Project Metrics: 

In waterfall methodology, the project team measures the project progress using techniques like Earned Value Management and Schedule compression to compress the schedule in case of any deviations. 

In Agile methodology, the metrics are derived in terms of velocity (how many story points the team produced during an increment cycle) and other metrics like sprint burndown/burnup charts to monitor daily progress within an iteration. 

Advantages and Limitations of Waterfall Methodology

Advantages:

  • Ability to apply due diligence in planning for well-defined requirements and scope 
  • Dependencies are managed effectively as the entire requirements are known well in advance 
  • Well defined processes pave the way for quality deliverables 
  • Phase-gate reviews allow stakeholders to eliminate any ad-hoc changes and unplanned additions to the project 
  • Works well for small projects for a well-defined requirement that is very well understood, and is not likely to change over the duration of the project 
  • Avoids scope creep with systematic implementation of change management process 
  • Simple and easy to understand 
  • Scope, time and cost baseline helps the management to monitor and control the project accordingly 

Limitations:

  • Requirements are expected to be defined well prior to development which delays the project 
  • Less flexibility in changes makes it difficult to manage 
  • Feedback is received from the customer at the end of the project and hence any negative feedback or defects proves costly for the team to fix  
  • Does not accommodate any changes due to market dynamics and its rigid approach to changes 
  • Cost of change is more as the defect is identified by the customer at the end of the project 
  • Ineffective team collaboration as the team works in silos (dev, testing etc) 
  • Integration is considered at the end and that prevents identification of any technical or business bottleneck 

Advantages and limitations of Agile Methodology

Advantages

  • Focusses on business value as developers and business work together 
  • Stakeholders are engaged effectively in every iteration 
  • Motivated and self-organizing teams that manage themselves 
  • Predictable and ensures less variations in the project 
  • Harnesses change and is more customer centric 
  • Working software is the measure of progress. Feedback is received from the key stakeholder during every iteration and the cost of change is very less 
  • Teams retrospect every iteration to look at improvement areas and finetune themselves 
  • Provides transparency through the process 
  • Focuses on Minimum Viable Product to release to the customer 
  • Due attention is paid to specific customer needs and changes are accommodated even late in development 

Limitations 

  • Not suitable for all types of projects 
  • May not work well in a large traditional organization due to its flexible and less formal processes 
  • Minimal depth in requirement analysis and frequent planning may derail the end project goals 
  • Self-organizing and empowering teams solely depends on team’s maturity level at handling decisions and may backfire 
  • Working software over comprehensive documentation is misunderstood and hence teams may not focus even on necessary documentation that is required 

Waterfall vs Agile Methodology – Which is right for your project? 

A typical question that is raised before the software development starts is “which approach should we follow, Waterfall or Agile?”   

AGILE vs   WATERFALL

The following table can be used to determine the approach (please note all the factors do not carry equal weightage)     

Waterfall (works)
Agile (works)
Well defined scope and changes are very limitedScope/FeaturesWhen scope is not known in advance or changes are expected as the project moves on
When uncertainty is low and low-level riskRiskWhen uncertainty is high and high-level risk
When market is stableMarket dependencyWhen market dynamics change/evolve frequently
When customer involvement is required only at certain milestonesCustomer FeedbackWhen customer is available and requires involvement throughout the project
When the focus is on planning, monitoring and control and predictabilityFocusWhen the focus is on innovation
When conforming to requirements as agreed upon in the contractProduct FeaturesWhen minimum viable product (which gives more value to the customer) is implemented first and we can implement the low valued features later
When a large sized team with minimal collaboration or handoff is requiredTeamWhen small team with high collaboration is required
When the budget is fixedFundingWhen the budget is not a constraint
When it is less important and not urgentTime to MarketWhen it is critical, important, and urgent to meet the desired outcome

Examples of Agile vs Waterfall: How is the software developed?  

Waterfall Methodology: (example) 

Scope: To provide an employee timesheet software having the following features: 

Waterfall Methodology

  • Ability to login 
  • Ability for the employees to describe the task and enter the number of hours spent 
  • Ability to submit for approval to the manager 

Manager 

  • Ability to login 
  • Ability to add a resource to a project 
  • Ability to link project to a resource 
  • Ability to assign task to a resource 
  • Ability to approve/reject the timesheet 

Administrator 

  • Ability to login 
  • Ability to add/modify/delete users  
  • Ability to add/modify/delete projects 

Reports 

  • Report on individual user timesheet data for a specified period 
  • Report on project timesheet data for a specified period 
  • Report on approved/rejected timesheets for a project for a specified period 

Let us assume the above is the scope and timeline for completion is given as 6 months. 

Requirements Phase: Detailed requirements on individual features are discussed and elicited from the stakeholders until they are well understood and documented. The requirements document is then signed off by the customer. Scope is identified and baselined during this phase. 

Project manager comes out with the detailed plan for the entire project and assigns team members accordingly to perform the task. The scope, schedule and cost are baselined considering all the other project constraints like resources, quality, risks, stakeholders, communication etc. 

Design and Development Phase: Development team works on design and coding all the requirements stated above and delivers to the testing team. 

Testing phase: Testing team validates the deliverables to see whether they conform to the requirements. They raise defects and the development team works on them. Testing team signs off on the deliverables once they work as per the requirements. 

UAT Phase: Customer validates the deliverables and signs off. Raises defects in case there are issues or requirements are not meeting the expectations 

Agile Methodology: (example) 

Scope: To provide the following features for an ATM 

  • Cash withdrawal 
  • Check balance 
  • Change ATM Pin 
  • Print statements 
  • Deposit Cash 
  • Deposit Cheque 

Product owner elicits high level requirements from the stakeholders and documents them in the form of features/user stories in the product backlog. Product Owner then prioritizes the features based on value that can be realized by the customer. Minimum viable product is finalized. 80/20 rule may be applied to find which 20% of the features give 80% value to the customer. In this case, Cash withdrawal and Check balance features are selected as the first increment to be implemented. 

Agile dev team along with the Product Owner sizes the features and stories and comes up with the release planning for the MVP identified. 

Product owner grooms and prioritizes the user stories in the product backlog. Agile team pulls the work in the iteration backlog and starts defining goals for every iteration until the features are completed. Meanwhile Product Owner continues to progressively elaborate the requirements for other features. 

Key business stakeholders, along with the Product Owner review the product increment created by the agile team and provide feedback. The team retrospect after each iteration with respect to people, process and product and finetunes accordingly. This iteration cycle goes on until the first implementation is complete and then the agile team takes up the next available set of features. 

Summary:

As we have seen, Waterfall and Agile methodologies have their own set of advantages and limitations. While waterfall approach is more methodical and predictive, agile approach is more adaptive and dynamic in nature. Depending on the project circumstances and using the table provided under Waterfall vs Agile Methodology, the project team can decide which works better for them. 

Krishnakumar

Krishnakumar Kuppusamy

Author

Krishnakumar Kuppusamy is one of the highly experienced Agile Coaches and SAFe Program Consultant (SPC 5.0). He has 24+ years of experience in information technology industry handling both traditional and agile projects. He has worked with companies like Citibank (USA) & Polaris Software at various capacities in project & program management. 

He has worked for ANZ and Ford India, coaching multiple Agile teams in their transformational journey. He is also a freelance trainer, conducted trainings in SAFe/PMP/PMI-ACP/ITIL/CBAP for over 2000+ professionals helping them getting certified and excel in their respective areas. 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Who is the Target Audience for Certified Scrum Master Certification Course?

Who is the target audience for Certified Scrum Master certification course? It is easy to understand the Scrum rules, but it is difficult to implement it in real-time projects. CSM course is the best to learn both in detail. It not only teaches you the principles and practices of Scrum but empowers and energizes you to make meaningful changes. Certified Scrum Master course focuses mainly on the Product Owner, Scrum Master and the Team in a software development company. Who will be benefited from this course? Certified Scrum Master course is helpful for everyone who wants to become smart in implementing Scrum in their organizations. Doing a certification course in Scrum strengthens the Scrum Master's experience.  This learning event is highly productive and effective for both leaders and members. As the course is completely revolving around the Scrum Master role, individuals who are planning to take up this role will get benefited more from this course. There is one reputed company in Denmark that sends all the employees from receptionists to senior management to the Scrum training, in order to make them knowledgeable about Scrum concepts and enhance operations throughout their company.  Target Audience There is no such fixed set of target audience for the Scrum Master Certification course. It is designed not only for Scrum Masters but also for the complete project or product delivery teams and anyone interested to work with the Agile teams. You may be a- Software Engineer Product Manager Project Manager Team Leader Business Analyst Development team member Testers etc. Irrespective of your current designation, there are a few basic qualities you should have as a Certified Scrum Master.    It is best for organizations or teams who need memorable and practical instructions. Even students can join this course to get real-time work experience in Scrum by Certified Scrum Trainers (CST) such as: Understanding Scrum framework Building a backlog Estimating a project Different techniques to improve team productivity Effective, project-proven exercises You will also find a CFO, CIO, or CEO in the Certified Scrum Master training classes and others as well who are intended to expand Scrum throughout their organizations. The State of Scrum in 2017 The 2017 state of Scrum report by Scrum Alliance suggested that most of the successful businesses are using Scrum irrespective of the sizes. Agile and Scrum are not limited to only software and IT departments, they are being applied to different industries such as government, education, manufacturing, banking, and finance. Moreover, some other departments such as human resources, finance, and accounting, sales and marketing reported their ongoing Scrum projects. Here are 3 statistics by Scrum Alliance: 89% of Agile users said that they use Scrum approach. 86% reported that they hold a daily Scrum meeting.  83% reported that Scrum was responsible and important to improve the team’s quality of work. Taking a 2-day CSM course, qualifying the CSM exam, and accepting a license agreement primarily establishes you as a Certified Scrum Master. This certification is a way to tell your peers and the world that you have strong knowledge of Scrum and are fit to work as a Scrum Master.  After all, in the Agile confines, CSM certification is the ultimate answer and the way forward.
1590
Who is the Target Audience for Certified Scrum Mas...

Who is the target audience for Certified Scrum Mas... Read More

Why CSPO Certification Is Important For Your Career

This article looks at how and why the CSPO® Certification is increasingly becoming important for today’s Product Owner (PO). The article briefly discusses on the responsibilities of the PO, how the role is becoming mandatory within the organization in today's Agile landscape, what makes a great PO and about the CSPO Certification.Who is a Product OwnerThe Product Owner is a member of the Product Management / Business team who works closely with and is a part of the Agile team throughout the Sprints/Iterations. The responsibilities of a Product Owner(PO) spans across the aspects of People, Product and Process.PeopleThe PO is a conduit between Business and Engineering teams, acting as the “Voice of the Customer” and “Voice of the Business” to the teams,Is one of the members to create the Product vision and constantly communicates the same to the teams, and Is able to interact and communicate well with all stakeholders (Customer, Engineering , Sales, Marketing, Support etc.)ProductDefines and maintains the team’s Product backlog, Can answer “Why” a requirement has found a place in the product backlog, “Why” it is prioritized and “Why” the Customer wants the features, Can provide insights into what customer problem the requirements aim to resolve, Can provide Customer Journey Maps, User Personas and Real Life Examples, and Can determine the value that the product delivers to stakeholders and identify which product backlog items would deliver the most value.ProcessPrioritizes the product backlog and is able to provide the reasons and justification of prioritization to the teams, Is part of the regular Product Backlog refinements to refine User stories and Acceptance Criteria, Is available to the team throughout the iteration and provides continuous feedback, Seeks continuous feedback from Customers, and Is able to review the features and approve User Stories once they are completed.Significance of the PO roleTraditionally the Business/Product Management teams have suffered with constant shortage of time and conflicting priorities between dedicating time for Engineering teams and Customer facing responsibilities. Usually, the Customer facing responsibilities understandably end up as the higher priority,   leaving very little time for the teams.Earlier, the time dedicated by the Product Manager to Engineering teams was very little and elusive, sometimes limited to only email interactions. The Business teams were located at the customer sites and used to visit the Engineering teams occasionally, interacting with them through email or phone calls. As a result, the product and productivity suffered immensely.With the advent of Scaled Agile Frameworks and industry wide adoption of Agile, the role of the Product Owner has been laid out as a mandate and demands the increase of manpower in Business teams. Dedicated Product Owners are becoming increasingly indispensable and significant within teams. The role of the Product Owner role has come as a big relief for Engineering teams, because they are constantly in touch with the Business stakeholders as well as the team, and can smoothen and streamline communication channels.POs are often co-located with the Engineering teams, attending Daily (Stand up) Meetings, Refinement meetings, Sprint Review, Demos etc. in person with the team. They are also available anytime for quick feedback and queries doing away with time-zone difference and delays. The POs closely work with their Customer facing counterparts in the various customer locations, serving as the liaison between Business Teams and Engineering teams.The PO ‘s role is key for the success of the Agile way of working. It has become a “Must Have” role within the Agile landscape rather than a “Good to have” role. This has created a good demand for the PO role in the Software Industry. With the surging demand for POs in the industry, there are many professionals taking up the discipline of Product Management.  There are professionals from other functions like QA/Project Management/ Development etc. moving into the Product Management discipline as well.Who makes a “Great” PO?Although a PO satisfies all the roles and responsibilities required of his/her role, there are some traits and characteristics that set apart a great PO from the crowd.A great PO has conviction in the Product Vision and knows the priorities of the Business very well, and is able to articulate the same to the Engineering teams. Shows commitment in completing the team’s goals by providing early and timely feedback. A great PO is excellent in communication, able to understand the nuances of the various stakeholders and speaks in each one’s language (Customer, Engineering, Sales, Marketing, Support etc.) Does not take sides but does what is right for the given situation and for the Customers. Is able to say “No” and has the reasons for it.Is not a task master who dictates to the team but a great Influencer who has the answers to “what has to be done” and “why it has to be done”.   Trusts the team to know best on “How” things will be implemented. Negotiates well with the team for the Business but is fair in all interactions with the team winning the team’s trust. Is always curious in terms of the product implementation but does not interfere in the team’s approach of building the product.To really excel at the job, the PO has to constantly upskill and sharpen the tools he/she has to offer. The PO is required to have keen knowledge of the various practices and techniques that are being used by his/her peers in the industry, in order to stay ahead of the competition. The PO needs to be part of a “Community of Practice”, grow his/her network outside the organization and be clued into all the relevant trends in the industry.CSPO CertificationWith the growing demand for the PO role in the market, the Industry naturally creates ways to benchmark standards, uphold quality and nourish promising talent. The CSPO Certification is one such mark of standard and quality. It equips the Product Owner to become better at the job and helps certified individuals to stand out in the crowd. The CSPO course and the CSPO community offers the right environment for the Product Owner to excel in his/her job. The curriculum of the CSPO course is outlined below for your reference.ContentsScrum Basics Understand the Scrum Framework and workflow so that the PO   Agile Principles and Scrum Values Roles and Responsibilities Product Owner role in detail Scrum Master role at high level Team role at high level Product Vision Importance of Product Vision Creating the Product Vision Just enough preparations before creating the Product Vision Qualities of Product Vision Relationship between Product Vision and Product Road Map Estimation Estimation Levels and Techniques Accuracy is more desirable than Precision in Agile Estimation What can go wrong with Estimation   Difference between Estimating and Committing Product Backlog   Understand what Product Backlog is and is not Product Backlog Grooming Prioritization Importance and Benefits of Prioritizing Product Backlog Why everything cannot be Mandatory or Highest Priority Who should Prioritize Prioritization based on Multiple Factors Applying formal approaches to Prioritization   Giving leeway to teams to sequence work after prioritization Release Management Goal Iterative and collaborative Release Planning Quality and Technical Debt Releasing Software early and frequently Measuring velocity and Release Burndown chart Forecasting future releases Sprints Product Owner’s role in Scrum Meetings Collaboration between PO and Scrum Team, between PO and Scrum Master Team Commitment Understand why Sprints are Timeboxed and Protected from other distractions Concept of sustainable paceCareer Prospects and GrowthExisting POsFor people who are already wearing the Product Owner’s hat, the CSPO certification is like one more feather in their resume. Going through this course and certification will fine-tune their skills and help add multiple tools in their toolbox.Aspiring POsIn certain organizations, there might be team members exhibiting and playing the roles and responsibilities of a Product Owner without the role title. They would have acquired all the necessary skill-sets but not the formal official title yet. By attending the CSPO course and earning the CSPO certification they convey their readiness to play the role; and this gives the thrust necessary for their formal recognition into a Product owner’s role.Salary AspectsThe CSPO certification has global recognition and so will result in an increase in the pay package for a certified professional PO.What next for an accomplished CSPO?An accomplished CSPO can further his/her career prospects by taking up the Advanced CSPO course and certification. It will set the stage for the product owner to progress in their career path and play the role in a wider scope. Depending on the Organization type and structure it could be the role of a Product Manager, Product Portfolio Owner/Manager— and for the more adventurous, even the CEO of a startup! Some Product owners might choose to diversify into a Business Analyst role as well.In conclusion, the CSPO has become a benchmark certification for Product Owners in the Software Industry. It will definitely help existing and aspiring POs to sharpen and upgrade their skillsets. It is also a badge of accomplishment and achievement for a Product Owner, not only to set them as a class apart in their own organization, but also in their wider Product Management community.
4320
Why CSPO Certification Is Important For Your Caree...

This article looks at how and why the CSPO® Certi... Read More

Roles And Responsibilities Of A Product Owner You Should Be Aware Of

A question I’m asked in many of my training sessions is about the difference between a Product Owner and a Business Analyst. Are they different names for the same role in different project management styles? Is a Business Analyst the person accountable for the project requirements when the software is developed using waterfall methodology; and is a Product Owner the person accountable for project requirements when the project is carried out using the Agile methodology?  This article attempts to help you understand about the warrior in Agile projects called the Product Owner. Is he / she the person in charge of software requirements? Or is he / she from the business side who will coordinate with the Business Analyst who in fact is a member of the development team? There is also an added confusion if this role belongs to the Product Management area.Who is a Product Owner?A Product Owner is an integral part of a product development or Scrum team. They are responsible for supervising the product backlog by making sure that it is up to date in terms of priorities and aligned with the vision of the product. The Product Owner represents the business or user, and is accountable for collaborating with the consumer to define what features will be present in the product release  Scrum Framework was developed in the early 2000s and since then there have been many different definitions floating around in the industry on who is a Product Owner. So, one day I decided to do some good old internet surfing on the topic “who is a Product Owner”.  I got the following answers from the Internet.Definition 1: A product owner is similar to a Business Analyst. He / she gathers software requirements from the various stakeholders and gives it to the development team. The development team goes to the Product Owner in case of any queries.Definition 2: The Product Owner is a part of the product management or development team. He / she creates the product backlog and prioritizes it. He / she will ensure that the development team is doing their job properly and are working on items that the Product Owner has prioritized.Now which of the above definitions is correct? What I have realized over the last few years as a Scrum trainer is that there is no globally accepted standard definition of a Product Owner role. The Scrum Guide does chalk out a few responsibilities of the Product Owner role, but different companies have different interpretations of this.  In some companies this role is a strategic role that involves collaborating with various stakeholders on the project and coming up with the software vision. The Product Owner then makes sure that the product vision is percolated down to the development team. And the development team develops the product exactly as per the Product Owner’s vision of the Product.In some companies this role is a very tactical or a hands-on role. The Product Owner is a very task-oriented person. He / she will write down software requirements, test the product developed by the development team, participate in the sprint review and make sure user stories are completed one after the other.What do Product Owners do?Ever since I embraced agile, I got to work with several Product Owners and mind you, this role is really critical as it collaborates with both the development team and the stakeholders. On the one hand, the Product Owner works with the stakeholders to get the right requirements or devise the requirements which they might not see or comprehend at that point. This not only improves the relationship with our customers but also helps to build trust. And on the other hand, the Product Owner helps the delivery team/development team understand the vision and the requirements. Hence, this role is similar to a bridge between the two ends that effectively paves the way for smooth communication.Deep dive into the Product Owner’s role:According to Roman Pichler, a leading Agile expert and the author of “How to Lead in Product Management”, the ultimate responsibility of a product owner is to ensure that the product creates value for its customers and users, as well as for the company. Think of the product owner as the person who champions the product, who facilitates the product decisions, and who has the final say about the product.” Pichler also says. “This includes if and how feedback is actioned, and which features are released.”The roles and responsibilities of a Product Owner include making sure that they understand the core of the product as well as how to facilitate collaboration at a 360-degree level, being both a liaison and the face of the user.At the most rudimentary level, as defined by the Scrum Guide, the Product Owner is responsible for maximising the value of work done by the development team. Let’s chalk out a few of the Product Owner’s responsibilities.1. Defining the vision: The purpose of the product is defined in the product vision. It is the Product Owner who creates this vision, manages it for the entire life of the product and owns the same. The Product Owner has the responsibility of creating a vision so that the development team clearly visualizes the expected outcome by the user. It is the Product Owner who interacts and collaborates with the users to understand their requirements, so that it can be effectively communicated with the team. Also, it is equally significant to communicate to the stakeholders the vision and goals so that they have a clear-cut understanding of the outcome.  The Product Owner has to be very passionate about this product vision. The product vision is not developed at one go but rather over many iterations, and improves over a period of time. The Product Owner makes sure that this product vision is in line with the vision of the company. He / she also creates a product roadmap for this product vision. Roadmap is a visual summary of the vision spread across a period of time. The vision will define the future state of the product and the motivations that the product tries to fulfil.2.  Managing the product backlogThe primary responsibility of the role of a Product Owner is managing the product backlog. Today’s market is really dynamic and every customer wants to stay on the top of the latest trends in the industry. This product backlog is derived from the roadmap created by the Product Owner. Even the items in the product backlog might require some movement due to changing priorities. It is the Product Owner’s responsibility to build up a stack of items in the backlog and prioritize them as per the business goals and the global approach. The product backlog is a dynamic list of items and as we call it in agile, it is a ‘live document’ that should be frequently updated, based on changing project requirements, all the way through to development. The Product Backlog exists as long as there is a Scrum team that works on the product.3. Prioritizing and Ordering Items in the Product Backlog: Another area where the product owner focusses on is to prioritize the needs of the stakeholders. A product owner should be able to determine the priority of product backlog items in order to deliver the maximum outcome. The Product Owners are constantly in touch with the stakeholders and understand the environment in which the product operates. When the needs and market conditions for the product change, the Product Owner will change the priorities in the Product backlog. He / she may add new items in the Product Backlog and remove the ones which are now obsolete due to new stakeholder needs. This means that the Product Owner must order the items in the Product Backlog to best achieve goals and missions. There are many tools to help Product Owners do this. The Product Owner is required to have the Backlog sequenced prior to the Sprint Planning Meeting. This means that each user story must be ordered by relative importance. The Product Owner will determine what needs to be developed in each iteration and how the product element will be developed over the life of the product.4. Overseeing development stagesOnce we have the basic entities in place – vision, product backlog, and the prioritization, the product owner has to make sure that he/she is participating in the overall development stages of the product. The team might need their Product Owner to get the clarity on a few queries or they might need to demo the committed item. The Product Owner will participate in the ceremonies with the team. In some ceremonies, this role can be active such as planning or backlog grooming but can also be passive or inactive such as in the daily Scrum.5. Anticipating client needs  In today's competitive environment, it is really important for someone in the role of a Product Owner, to understand the client/customer’s needs. The product owner should understand the market, the competition, and the users’ pain points. With those valuable pieces of information, the product owner can determine what features should be implemented, and in what order, with respect to time and importance. Sometimes the Product Owner can help the customers in configuring and penning down the items which they want but are not able to comprehend. And here communication plays a big role.6. Acting as primary liaison  As we have talked about at the start of our discussion, a product owner role involves acting as a primary liaison between the teams and the customers. The person in this role has to make sure the information flow is quick and clear so that there is no misinterpretation. The Product Owner has to make sure that the goal and the vision are correctly aligned with the work items on the product backlog. The Product Owner also acts as a liaison for business stakeholders and end-users, determining whether each story meets their shared expectations. When we say stakeholders, we mean the end users, or their representatives; they could be sponsors (who are paying for the product) or stakeholders who are also a part of the company's management. A stakeholder could be anyone with an interest in or an influence on the product. A Product Owner understands these stakeholders' needs and builds a vision that will drive the development team to develop the vision. Good product owners ensure that development teams can communicate directly with stakeholders, as long as they work on the priorities as chosen by the product owner.7. Evaluating product progress at each iteration   In every iteration, a product increment is created by the development team. The product owner inspects this product increment and decides if this is developed as per the vision created for the product. If it not as per the vision he / she may direct the development team to revise it in later sprints. Work that is either not complete or un-done needs to be re-prioritized or sequenced. The Product Owner makes sure that the development delivers the expected outcomes from the stories they worked upon and accepts it.  Thus, a Product Owner wears multiple hats throughout the product development effort.8. Participating in daily Scrum, Sprint Planning Meetings, and Sprint Reviews and RetrospectivesScrum ceremonies give a chance for the Product Owner to inspect and adapt. And as a result, being present at these ceremonies is identical to success. It is important for the product owner to join the Scrum meetings as it not only keeps the development team up to date with the priorities, but also helps the product owner understand the perspective of the team if there are any impediments.9. Terminating a Sprint if it is determined that a drastic change in direction is requiredIf the Sprint goal has no meaning (will not deliver business value) because of the extreme change, the product owner can terminate the sprint. The termination is most frequently the outcome of an intense change in business priorities; something previously considered important is no longer needed, or something even more significant is learned.How to become a Product Owner?Becoming a product owner requires a thorough understanding of the product as well as analytical and strategic skills. The person who wants to deep dive and become a good product owner needs to understand the market and the stakeholders. He/she should be able to create a vision and know when to juggle with the items in the product backlog so that the bucket is always prioritized.You can opt for some good certification programs provided by different authorities and gain a confidence in this area. As per my experience, I would recommend you to select a domain and master it!How to be a Good Product Owner | Product Owner Best PracticesWhat is A Certified Product Owner?As defined by the Scrum Alliance, a Certified Scrum Product Owner® (CSPO®) is someone who has been trained by a Certified Scrum Trainer in Scrum terminology, practices, and principles that will enable them to fulfill the role of Scrum Product Owner.Is the Product Owner the Project Manager?Both a project manager and a product owner watch over teams who work to carry developments across the finish line together. But the path to that finish line deviates entirely from the start. The Product Owners are product driven and customer focused. They need to be actively engaged with the team because they are the ones responsible for deciding what features will go into the final product.Also, there is a confusion between a Product Owner and Product Manager. Let us understand the difference between the two.A Product Manager is a high-level role that has responsibilities for the entire product lifecycle. The role starts by focusing on customer discovery to product delivery. The product manager will drive the overall product strategy. This is a multidisciplinary role and is very strategic in nature.  The product owner works primarily with the production team to ensure that the development team develops a product that is aligned with the product roadmap.To summarize, the product manager decides on what products to build next, and the product owner coordinates with the development team to build these products.What are the challenges a Product Owner comes across?Below are the major challenges a Product Owner is more likely to come across:1. Missing product road map2. High-level acceptance criteria3. Spending too much time dealing with product support instead of grooming the backlog4. Changing priority while sprint is in progressProduct Owners can escape these usual snares by working around the product road map, centering on high-value backlog items, defining crisp acceptance criteria, concentrating on grooming quality backlog item, and avoiding disturbing sprints.What is the learning path for a Product Owner role?Are you a business analyst who is now unable to figure out his / her new duties as Product Owner? Are you looking to venture into a Product Owner role? Or are you looking to clear your understanding of Scrum Framework and understand the Product Owner role? Then embark on this journey with us in becoming a great Product Owner.Why should you go for a CSPO certification?  Every high-functioning Agile team has a well-trained Product Owner making critical product decisions. A Certified Scrum Product Owner® (CSPO®) is one such certification that helps holders become successful product owners by training them on aspects of on-time delivery of high-value releases and maximizing the ROI. The globally recognized CSPO certification, therefore, is a career-defining credential for anybody willing to take up the challenging role of a Product Owner on a Scrum team in an organization.Increasing Demand for CSPO® Certified Professionals The industry today is ripe with endless opportunities for Product Owners. With 90% of modern teams using Scrum, the demand for Certified Scrum Product Owners has seen a steep rise. Their presence on an Agile team is guaranteed to ensure early ROI while maximizing business value.Scrum Alliance  underlines the importance of Product Owners as follows:38% of the Product Owners act as an intermediary and are responsible for maintaining relationships with the Stakeholders.24% of the Product Owners set project business priorities and work directly with the customers.15% of the Product Owner work directly with the Scrum team.The Future of a Product OwnerA Product Owner is indispensable for the Scrum teams. This role can be compared to that of a deeply rooted tree which has a firm foundation on the product side and provides vision, approach, and planned execution on the outer side. The product owners carry the ownership of the product in terms of quality and delivery as per the expectations set with the stakeholder.A Product Owner needs to have an all-inclusive view of the product along with all the other factors like business understanding, go to Market, organizational readiness, and product capabilities. All of these should be collectively managed, coordinated and aligned to drive product success.Product Owner Training:  Be an efficient Product Owner to raise product value & manage product backlog effectively!  Get trained by Scrum Alliance approved Certified Scrum Trainers® (CSTs)  Get certified from the globally acclaimed accreditation body, Scrum Alliance  Earn 16 PDUs and SEUs in just 2 days  Excel in addressing challenges through Scrum as an effective Product Owner  Advance your knowledge with an experiential learning format  Get Free E-learning Access to 100+ courses  The Scrum Product Owner Certification from the globally renowned Scrum Alliance endorses and validates your Scrum expertise while enabling you to take on the Product Owner role and responsibilities with dexterity, as you lead successful projects and ensure high-velocity releases of marketable products. 
11098
Roles And Responsibilities Of A Product Owner You ...

A question I’m asked in many of my training sess... Read More