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

Learn Scrum with JIRA

Many organizations use JIRA as a one-shot solution to automate their processes, and JIRA has almost become synonymous with Agile. Even organizations that don’t deploy it across all levels use it for at least some of their projects. Such is the popularity of JIRA. So, what exactly makes it so popular? JIRA provides a simple and easy-to-use solution for project management tasks, right from gathering requirements to maintaining releases and generating all sorts of reports and metrics. The best part of the tool is that it is highly customizable, attending to the needs of one and all. If it is said that there isn’t a thing that one cannot do using JIRA in terms of project management, then that is not an understatement.  Since Agile is the buzzword now and most organizations are opting for it, this article will provide users with a detailed insight on how to carry out their project management tasks and software development activities by using a Scrum framework.   Before moving ahead, there are two basic pre-requisites that the user who intends to use JIRA must have and they are: Pre-Requisites:  An active account on JIRA Required permissions (Super Admin, Project Admin, etc. – Defined by organizations) 1. Creation of Project: The first and most important thing is to create a project in JIRA under which we will be carrying out our activities and tracking the progress of those. There are two ways a user can create a project.  Method 1:  Step 1: Log in to JIRA using your credentials. Once you are logged in, you will land on the project dashboard which will look something like this.  Step 2: Click on Settings icon and select the Projects option as highlighted in the image below.   Step 3: Select “Create Project” option as shown in the image.   Step 4: After clicking on “Create Project”, you will be prompted with two options to select from.  Classic Project  Next Gen Project Step 5: Once you have selected the type of project, you will be asked to enter the Project name. You will also have the option to change the type of template i.e Scrum, Kanban or Bug Fixing, depending on the purpose for which you wish to use JIRA.  Once done, you must click on the “Create” button.  And voila, it’s that simple. Once you have clicked on the create button, you will land on the project dashboard with the name of the project highlighted on the top left. As we can see in the image below, project name “My Scrum Project” is visible. Method 2.  The steps remain the same, only difference is that instead of navigating through settings, once you have logged in, you will have the option to navigate via “Projects” link as depicted in the pic.  2. Creating Backlog: Once the project has been created the second important step is to define requirements in a backlog. As you can see in the pic below, there is the option to select “Backlog” from the left side panel/navigation pane to navigate to the backlog section.  Here you can start creating backlog items. This backlog serves as the “Product Backlog”. Users can outline requirements in terms of Epics, User Stories, Tasks and Bugs which are known as “issue types” in JIRA. In short, everything that is created is an issue in JIRA. Please note that for ease of understanding and reference, I am sticking to the most basic issue types as mentioned above.  Step 1: To create issues in JIRA, all that is needed to be done is to click on the “Create” button on the top most navigation bar. This bar remains visible at all times by default, no matter whichever page you navigate to. Step 2: Once the user clicks on “Create”, a dialog box to enter details of the issue will open.   The two most important fields in this are:  Project: This field, by default, is populated with the name of the project you are in. But in case you wish to change the project field, the same can be selected from the dropdownIssue Type: This option by default is selected as “Story” but can be changed depending on which issue you want to create. The relevant issue can be chosen from the dropdown. Below image shows how it all looks like in JIRA. There are two types of fields on the dialog box; Mandatory and Non-Mandatory. Mandatory fields are marked with a red Asterix. Also, these fields change on change of the issue type i.e. on basis of what is applicable to the issue type being selected.  As already mentioned, JIRA is highly customizable and a JIRA admin can add or change more issue types based on what terminology is being used by the project and/or organization on the whole. E.g. Issue type of Features can also be added in case teams follow a feature-based development approach wherein features are divided across teams and encompass the hierarchy of epics and stories.  In a similar manner, issue type “Story” can be amended to be displayed as “User Story” or at times to be more specific, something like “Functional User story” and/or “Technical User story”. In addition to this, the fields are also customizable. New fields can be added and the rule of mandatory and option field can also be altered depending on what works best for the team. To make these changes, the JIRA admin needs to navigate to the settings section and then to the desired settings type to change them. Please note that these settings will only be available to the user who either is a JIRA admin or has permission to perform these activities. Permissions are issued by the JIRA admin to the user.  Coming back to the topic of creation of backlog, once you fill up the details and click on “Create” at the bottom of the dialog box, a new issue is created in JIRA that now starts reflecting in the backlog.  Issues can also be created by using the short cut link available in the backlog section as highlighted below.  Once you click on “+” icon, you will be able to select the type of issue to create and provide a summary for the same.   After entering the summary details, you are required to click enter and the issue is created. To enter other details, you will have to navigate to the created issue by clicking on it in backlog or opening the same in a new tab and then doing the needful.  As soon as an issue is created, the same starts reflecting in the backlog. Here you can see two stories and one bug that were created, are visible in the backlog. 1. Linking Issues:  We all know the hierarchy of requirements goes something like Epics > Stories > Tasks. JIRA gives us the capability to link one issue type with another. To start with as a very basic ask, stories will fall under the epics and thus need to be linked with the correct epic. This linkage is something which replaces the requirement traceability of traditional models. When everything is perfectly linked then it can be easily known which requirement from the customer was covered under which epic and if we go into a granular level, under which story and even tasks the requirements fall under. Similarly, if a bug is found in the story while working on it, the bug can also be logged and linked against the story.  To link issues, the steps below can be performed.  Epic Link: To link stories under an epic, JIRA specifically provides the field “Epic Link” in stories. The field at most times is made mandatory by organizations to make sure that every story that is created in JIRA is by default linked to the epics. Here the epic becomes the parent issue of the story and thus it also becomes easy to make sure that every requirement has been worked upon.  Step 1: There are two ways to create the Epic link. While creation of the story, you will have the option to mention Epic link or if the story is created using shortcut link, the same can be added by opening the story and then mentioning the epic in the epic link field as shown below. Step 2: Once selected the same starts reflecting in the story details.   Step 3: To see the linkage, you need to navigate back to backlog. The link starts displaying in the backlog.   2. Linking Bugs:  Once the bugs are created, they can be used to block user stories in a similar fashion, though there is no specific field like epic link in case of bugs, they can be linked using the “Link issue” option.  Step 1: Once the bug is created, note the issue ID and open the story which needs to be blocked and select the “Link Issue” option.  Step 2: By default, “is blocked by” option is selected, indicating that the story is blocked due to the following issue. As soon as you enter the bug issue id and click on link, the story is linked with the bug or to be more specific, the story is marked ‘blocked’ by the bug. In this way multiple stories can be blocked with a single bug and vice versa.   Note – Stories can be linked to other stories to showcase linkage, to mark dependency, to display duplicity/redundancy etc in the same manner, all that is needed is to select the correct option from the dropdown after selecting “Link issue”. Issue Prioritization in Backlog.  As the rule goes, the product backlog must be prioritized at all times i.e. the issue with the highest priority should be at the top and the issue with least priority should be at the bottom of the backlog, so that the teams working on the backlog have a clear idea about the work they need to pull in once the next iteration starts or to understand if they have capacity for more during the ongoing sprint. Keeping the backlog prioritized also helps the team to keep working as per the product roadmap in the absence of the product owner and as such the team does not get blocked.  JIRA also provides the capability to keep the backlog prioritized at all times by the simple function of dragging and dropping the issue above or below the other ones. Below images will give you an idea of the same.  Scenario 1: Once you start creating issues in the backlog, the issues start reflecting in the ascending order of their Issue IDs i.e. the order in which they are created. For ease of reference, the issues have been named as 1, 2, 3, 4 and placed one after the other.  Now assume that the priority of Story 4 is the highest and thus it should be at the top of the backlog, followed by test story 2, followed by 1 and 3 respectively. Thus, they should be placed in order of 4,2,1 and 3 in the backlog. This can be done by simply dragging the items to bring them in the desired order.  Scenario 2: Below image gives you a backlog which is sorted on the basis of prioritization of stories as per the priority defined by the PO. Bugs too can be dragged and placed at the relevant position in the backlog depending on their severity and priority. All these activities of creation and prioritization of backlog are done primarily by the PO. In case the PO is supporting multiple teams and there are BAs supporting individual teams or acting as proxy POs for the teams, then POs can leverage them for backlog management. Scrum master needs to ensure that the backlog is prioritized, properly detailed and at least the stories for the immediate next sprint remain in a ready state.   3. Creating & Starting a Sprint:  Once the backlog has been created, the next step for the team is to gather and hold the sprint planning event. PO can open the stories and discuss the details and Acceptance Criteria with team members. Once all the stories have been discussed, the team can start pulling the stories in the sprint and for that to happen the team will need a sprint in JIRA. It is again very simple.  Step 1: In the backlog section, there is a “Create Sprint” button.  Step 2: Once you click on the button; a sprint is created, starting from sprint 1 with a prefix of project ID as shown in the image below. You have the option to create issues directly in the sprint using the quick link as mentioned above for the backlog or the issues can be dragged and dropped in the sprint created. All the issues dragged and dropped in the sprint created, as discussed in sprint planning, will serve as the sprint backlog.  Step 3:  Once all the issues are dragged and dropped in the sprint, the sprint is ready to be started. As an example, we see that test story 4 and 2 as well as a bug have been dragged to sprint 1 as displayed in the image below.Please note as part of sprint planning session, details like Story Assignee, story points and hourly estimates can be filled in the stories using the fields available. Also, in case the story owner wants to highlight the individual tasks they intend to perform as part of working on the story like Analysis, Coding, Review etc or in case multiple team members are working on a single story then to highlight individual work assignments, the option of creating tasks can be used. Tasks can be created just like stories, as mentioned above. It is similar to work breakdown in traditional models.What needs to be made sure is that before marking the sprint planning as being complete, all the stories have been pulled in sprint and assigned and estimated in terms of story points or hours or both, according to the approach the teams have decided to take. All the sub tasks that have been created, can optionally be assigned. If desired, these subtasks can also be estimated. Once all this is done, the Scrum Master can then mark sprint planning as complete and proceed to start the sprint.  As we know that before sprint planning, a goal is provided by the PO to the team. The same goal can be added in the sprint. Just select the three dots option besides the sprint on right side and select edit sprint and you will be able to enter the sprint goal.  4. Starting Sprint: Once the planning is complete and activities like estimations, assignments and tasking have been done, it is time to start the sprint. This is simple to do. In the backlog, there is a “Start Sprint” button. Once you click on it, a dialog box appears where you can verify sprint goal and set a duration for the sprint. After reviewing the details, you can click on “Start” and we are good to go.  5. in Progress:  Once the sprint has started, you can navigate to the “Active Sprint” section to visualize the progress on the stories in the sprint. Team members can update the stories to depict statuses from “To Do”, “In Progress” and “Done” and also update their daily hours in the stories in case teams are estimating in terms of hours.  6. Completing/Closing Sprint:  On the last day of the sprint, it is important to mark the ongoing sprint as closed in JIRA so that next sprint can be planned and started.  All the items which are marked done are considered complete. Anything pending to be completed is either moved to the next sprint or to backlog in consultation with the PO.  Step 1: In the “Active Sprint” section. On the top right corner, you need to click on “Complete Sprint” button.  Step 2: Once the “Complete Sprint” button is clicked, a dialog box appears with details of issues that have been completed and the ones which are pending. Select the place where you wish to move the pending items to, either to the backlog or next sprint which is to be started.Step 3: Once you select the desired value under “Move to” field and click on “Complete” button the Sprint is marked as complete.   
5911
Learn Scrum with JIRA

Many organizations use JIRA as a one-shot solution... Read More

Top 5 Agile Trends to Take You Safe Through 2021 and Beyond

In recent times, Agile has proved to be more than just a buzzword in the IT industry.The amazing results of Agile project management have widened its scope for implementation in other than IT industry also; therefore, we often come across the terms like “being Agile” and “doing Agile”.More and more organizations and enterprises irrespective of size and business niche are adopting Agile with an eye on commitment, delivery values, profitability, customer’s satisfaction etc. Because of continuous Agile evolvement, you need to align Agile practices with the latest trends to compete with excellence in 2018 and beyond. Following are the top five Agile trends that will help you plan and sail safe through the competitive marketing environment.1) Short-Term Activities Oriented Agile Training:Organizing the short-term activities oriented intensive workshop/training, planned to train the participants for implementation of specific skill in real projects, is a new emerging trend in Agile organizations. The long and exhaustive classroom training of 4 or 5 days are no longer a preference. The short–term Agile workshops/training leave the Agile team members with new ideas and cohesive understanding of the Agile roadmap. The improved capability to execute short iterations supports to market the product early. In addition, Agile workshops are helping the organizations to develop multi-disciplinary Agile specialists to maximize overall performance.2) Rapid Feedback:Predictions are good to plan but the ever-changing working conditions, new demands, and altered quality standards etc deviate the results. The biggest trend in Agile management for 2018, I noticed recently, is to focus more on rapid feedbacks of developments rather than depending on the predicted outcome. Rapid feedback is vital for Agile teams to understand the way project development is going. Creating a friendly environment allowing every team member to comment and even seek the feedback saves considerable time besides giving a true picture of progress. Continuous Integration (CI) is the best tool to maximize the benefits of rapid feedback.3. Embracing Agile Spirit:  Over the years, a number of organizations twisted & curled Agile methodology to meet their interests and suitability; as a result, some of these tasted just the semi-success. The new trend shows that organizations are embracing the Agile spirit as a part of organizational culture. Organizations are conducting short-period objective oriented trainings to strengthen the Agile mindset of team members.The application of modern Agile principles leads the organizations to deliver more values with satisfactory profit. There are four core characteristics of Agile mindset - value matters, small cycles matters, ecosystem in entire organization matters and culture matters. Agile Spirit embracement can be improved by following the five simple tactics- be transparent, be disciplined, ensure participation, get everyone aligned and set up collaboration as an Agile tool.  4) Cloud-Based Solutions:More Agile teams are adopting cloud-based solutions to find new ways for envision (prediction), coding, testing and deployment faster than they are/were doing now with the intention to have an edge over their competitors. Server-less computing has become the favorite of Agile teams; as, it reduces the need of ‘always on’ traditional server infrastructure, in addition to reducing the infrastructure and operational costing. The organizations that follow cloud-based Agile methodology have enormous competitive advantages supporting for higher quality, greater agility, faster market responsiveness, reducing costing, improving client’s experience etc. It can be said that Cloud technology is going to be an Agile accelerator.5) More Focus on ‘Business Value’ of User Stories:“If you can’t measure the results, you can’t improve the process” fine fits to modern Agile culture. Today, Agile organizations are more focused on measuring the lagging indicators like ROI of new products/ features, Net Promoter Score (NPS) of team members & customers, cycle time and operational stability etc. Using three-dimensional metrics, encompassing complexity, ROI and business value, is the new approach to measure the business value of a user story. Identifying business values before writing a user story rather than writing a user story and then evaluating the business values is a significant shift in modern Agile practice.Summary:Agile culture adoption is growing fast in organizations around the world. Internal Agile coaches, consistent Agile practices, and implementation of a common tool across Agile teams are the top three factors encouraging businesses to continue their Agile journey. According to ‘12th annual State of Agile report’, the top five Agile benefits reported by the organizations are –Better project visibility – through- rapid feedbackFaster delivery – through – cloud-based solutionEnhanced productivity – through – activities oriented learning workshopsImproved ability to manage the changing priorities – through – deep focus on business value of a user storyBetter IT alignment – through – Agile spirit embracementKnowledgeHut provides objective-oriented customized Agile training that helps the organizations match the steps with the latest trends in Agile methodology.
1131
Top 5 Agile Trends to Take You Safe Through 2021 a...

In recent times, Agile has proved to be more than ... Read More

The Spotify model - Agile

Many companies find it hard to scale Agile due to the various complexities that come with multiple teams, locations, time zones and different cultures. Over the past decade, many Scaling frameworks like SAFe, LESS, DAD have been introduced into the Agile world by various Agile practitioners and groups. This article is about one such scaling model called the “Spotify Model”. Origins of Spotify Model “Spotify” is a Sweden based music streaming company founded in 2006. The structure used by the company to scale agile across its various teams located in different locations came to be called as the Spotify Model. This model is becoming increasingly popular due to its flexibility and simplicity. Need for change in Organization Structure Today’s world is constantly changing due to social, political, and economic disruptions. The 2019-2020 COVID is a classic example of disruption in the entire world to the “business as usual”. To keep up with the disruption and competition, companies must be nimble and innovative to respond quickly and stay ahead of their peers. The hierarchical structures and organizational processes that worked well for decades are no longer enough to keep up with this fast-paced world. While traditional hierarchies and managerial processes are still very much required to run the show, the need of the hour is to also have an additional network structure operating in tandem with the traditional norms. The purpose of this network is to continually assess the business, the industry, and the organization, and react with greater agility, speed, and creativity than what has existed before.  There are so many examples around us where Start-up organizations thrive in the network structure and fail miserably when they have to scale, and cannot continue with traditional hierarchy and processes. In equal measure, around us are examples of Enterprise giants collapsing under the weight of the traditional hierarchy alone without the nimbleness and speed of the network structure.  Both the operating structures – the hierarchy and the network, are essential for today’s businesses to thrive. Kotter’s theory of establishing a dual operating system within an organization resonates heavily in the Spotify Model and compels us to draw parallels. In the Model we can see that there are innovative and thriving network structures and at the same time there is space to establish the traditional hierarchy as well. Spotify Model Squad: The Squad is the basic entity of the model which comprises the team that does the work. The Squad does not have a dedicated Squad lead but has a dedicated Product Owner.  The Product Owner tells the Squad “What” has to be done , prioritizes the work and maintains the backlog. Each Squad is self-organizing and can choose to follow Scrum, Kanban, XP or a hybrid of these. Squads are aligned to their mission, product strategy and short-term goals. Each Squad owns the release and delivery end to end. Typically, an infrastructure / DevOps Squad enables them to carry out smooth releases but does not do it for them. The Squad has access to an Agile Coach who runs retrospectives and Sprint Planning meetings. The coaches help the Squads to continuously improve. Tribe: A Tribe is a group of Squads that are related to each other by nature of the work being done by them. for e.g multiple Squads working together on the same product feature or closely related product features/ same product within a portfolio of different products.The number of people in a Tribe is recommended to be 100 in line with the Dunbar number. As per the Dunbar number, most people cannot maintain a social relationship with more than 150 people or so. All the Squads within a Tribe are co-located and physically able to interact in common areas dedicated for this purpose. There is a Tribe Lead who is responsible for creating a productive and an innovative environment for the Squads. The Tribe Lead can be part of a Squad as well.  Tribes meet often to showcase what they have been working on, what has been delivered and their learnings. The showcase could include the working software, new tools and techniques. Handling Dependencies One of the foremost challenges to resolve in a scaled agile environment are “conflicts and dependencies”. These can crop up during the development of a product among the Squads within a Tribe and also exist among Squads in other Tribes as well.   Dependencies could slow down or block the progress. Such dependencies are identified and are handled by reprioritization or through technical solutions. Sometimes innovative ideas could help remove the dependencies.  The end goal is to avoid dependencies between Tribes by making the Tribes self-organizing; and once that is achieved by having minimal dependencies among Squads within a Tribe. Survey for Continuous Improvement: A survey is done for all Squads at the end of every Quarter to understand the pain points and areas for improvement. For e.g multiple Squads having issues with the release process need urgent attention. One of the Squads not getting enough support from their Product Owner needs leadership intervention. Chapter: Certain disciplines/technological areas within the Tribe, like QA, Database Specialists, Front-end developers, Back-end developers, UX Specialists will benefit with regular discussions and interactions. People within these functions across multiple Squads and within the same Tribe constitute the Chapter. Constant communication within the Chapter members is encouraged. Each Chapter meets regularly to discuss their achievements and challenges in their respective areas of expertise e.g QA Chapter, UX Chapter, DB Chapter. There is a Chapter Lead who can guide the various members of the Chapter on “How” things can best be done. For e.g the QA Chapter lead can strategize the End-to-End Functional, Performance and Security Testing to be carried out for the new version of the product in an upcoming release. This will ensure the testers within all the Squads have a common well thrashed out testing strategy for the upcoming product release.  The Chapter lead can also be the line manager of the members in his Chapter, performing the traditional managerial responsibilities like people development, performance appraisals, career growth etc. The Chapter lead is also a member of one of the Squads in the Tribe, making him remain closer to ground realities.x` All the Chapter leads within a Tribe typically could report to the Tribe lead, and the Tribe Lead performs all the managerial responsibilities for the Chapter Leads within his Tribe as well as the next level Squad members of his Tribe.  Guild : A Guild is like a “community of interest” cutting across Tribes throughout the Organization/ Business Unit.  Imagine an Enterprise that has three Tribes each located in three different locations. There could be QA Chapters for each Tribe with respect to the location. There is also a need for QA members of one Tribe to exchange and share processes and learnings with QA members of the other two Tribes. The Guild is an organic structure that serves this purpose.  The Guild cuts across the Tribes spread across the organization across locations. Knowledge, tools, and practices are shared. For e.g the QA Guild includes all the QA Chapter members and in addition can include other members who are interested.  Guilds usually are not focussed on a specific release or delivery but on their area of expertise in a generic way. They have mailing lists, publish newsletters and conduct unconferences once in a while.  Spotify as a “Scaling Agile Model” Many of the foundational elements within the model become the backbone to scale agile in the organization adopting it. Spotify Model recognizes the need for a Network Structure within the organization to make it nimble and agile. The elements within the Spotify model help to establish Agile scaled to multiple teams spread across various locations and areas of work. The Spotify Model recognizes self-empowerment and self-organization, and at the same time aligns the Squads within a Tribe to work in tandem, in order to create complete and usable software products. The Chapters across Squads provide the environment for cross Squad collaboration. The Quarterly Survey in the Squads and handling dependencies within and across Tribes enables agility and continuous improvement. The Guilds help in improving the organizational culture to better adapt to the technological advancements and provide competitive readiness. Unique Benefits of the Model Spotify focusses on Agile Principles rather than mandating specific practices. Squads are autonomous to choose their own agile way of working. (Scrum/XP/Kanban/Scrumban etc. Not all Squads within a Tribe follow the same method) Specific Agile ceremonies and artifacts are not imposed on the Squad. Practices which work well with multiple Squads are automatically adopted by other Squads without the resistance that comes with standardization. This creates a balance of consistency across Squads along with the flexibility needed for autonomy. Though Squads are autonomous and loosely coupled they are tightly aligned by grouping them into Tribes. How Spotify is different from other Scaled Agile frameworks  While SAFe is a heavyweight scaled agile framework having many different flavours like Essential SAFe, Portfolio SAFe, etc, Spotify is more of a lightweight framework.  It might work very well for start-ups that are growing into medium Enterprises or for larger enterprises that are not ready yet for something as heavy as SAFe. The role of the Scrum Master is absent in Spotify, but the Squads have access to Servant Leaders in the form of Chapter and Tribe Leads and Agile Coaches. Conclusion  The Spotify Model has been a popular buzzword due to its unique nomenclature, flexibility and simplicity. It recommends the need for a community-based networking structure within the organization and focuses on the Agile Principles rather than Practices. It is a very unique and liberating Scaled Agile model and requires the practitioners to be extremely mindful and responsible while adopting it, so that it can be tailored for their specific organizational needs. 
5428
The Spotify model - Agile

Many companies find it hard to scale Agile due to ... Read More