What is Kanban throughput? What's the best way to measure it? This article reflects on these questions and provides a perspective to track a Kanban team's performance in an effective way.
What Is Kanban Throughput?
Kanban Throughput is defined as the average number of items or cards passing through the flow within a specific time duration provided that the work load stays uniform during that period. It is generally used to track team's performance. Throughput variability reflects the difference in size, complexity, and team skills.
According to the Little's Law:
Throughput = Total WIP / Average Lead Time
Measuring What Matters: Kanban Throughput
The best way to measure throughput in Kanban is with the CFD (Commulative Flow Diagram). The Cumulative Flow Diagram is the visual representation of the cards as they move from one column or state to another on a Kanban board. The CFD plots the number of cards at each stage at a given time.
Below is a sample CFD for your reference:
The different colors on this diagram represent the various states in the flow. The height of each color band indicates the number of cards in that state at that point in time.
The CFD provides you with an insight on how many cards moved from one state to another in a specific time duration. Generally, the CFD is plotted for each day, however, if there are too many moving cards in a day, it can be plotted on an hourly basis as well. Below is a sample CFD when plotted for every hour in a working day.
Moreover, the CFD provides valuable data on lead time and cycle time trends. Both lead time and cycle time denote the time a work item spends in the workflow until they are complete. Lead time is the time that a card takes from start to finish. Cycle time is the time an engineer spends to actively work on it. In a CFD, both lead time and cycle time metrics are measured along the horizontal axis.
The Cumulative Flow Diagram (CFD) also displays total cards across different columns i.e. total WIP. This data is measured along the vertical axis of the CFD diagram.
Below is a sample CFD that depicts lead time, average cycle time, and the total WIP.
Will OKRs rule the world? This article captures my thoughts on OKRs and their impact on the corporate industry.
What are OKRs?
OKR stands for Objectives and Key Results. It is a simple management methodology and an agile goal-setting system that enables everyone to align with enterprise objectives and to visualize the progress made towards them.
Founded by Intel CEO, Andy Grove, in the 1970s, the OKRs methodology was first adopted by Google in 1999. Since then, OKRs have helped Google and several other enterprises to stay focused, create transparency, gain alignment, and achieve better results. Today, several organizations across all sectors such as Spotify, LinkedIn, Walmart, Bill and Melinda Gates Foundation, and others are using this framework to set and achieve audacious goals.
In 1999, John Doerr, a venture capitalist, introduced OKRs to Google. In his meeting with Larry Page and Sergey Brin, co-founders of Google, he introduced the OKR system and explained how it can help Google to achieve its aggressive growth targets. In his book, Measure What Matters, John revealed how the system of OKRs has helped organizations achieve agility and explosive growth.
John Doerr’s formula for OKRs is:
I will (Objective) as measured by (set of Key Results).
Objectives define 'what' is to be achieved. They are qualitative, significant, concrete, short, inspirational, memorable, and ambitious. Each objective could have 2-5 key results.
Key Results define 'how' we achieve the objectives. They are a set of measurable milestones for each objective to track progress towards achieving the objective. They are quantitative, specific, measurable, time-bound, verifiable, and aggressive, but realistic. When key results are complete, the objective is necessarily achieved.
Will OKRs Rule the World?
Let’s look at some of the common problems faced these days and if OKRs can prove to be beneficial in those scenarios.
One of the common problems today is conflicting priorities. Often, different stakeholders have conflicting views on the features or capabilities that a product roadmap should include. Such conflicts lead to unpleasant conversations, strained relationships, and a demotivated team.
The OKRs framework brings focus to the purpose or objectives that a product has. The stakeholders start to think in terms of the product vision and its goals that they are trying to achieve. With OKRs, there’s also a better clarity on the success metrics or the key milestones for each product objective.
“OKRs are clear vessels for leaders’ priorities and insights.” - John Doerr
The other common problem these days is lack of measurement or tracking of the specific outcomes or product goals. Teams continue to build new features and capabilities for the product but seldom measure the outcome or the result.
With the OKR model, Key Results (KRs) are measured and tracked periodically.
“If the focus is delivering something the customer wants, you must move from primarily measuring outputs to primarily measuring outcomes.” - Mario E. Moreira
But does one size fits all? No, OKRs are not meant for all enterprises. OKRs will not work for you when:
OKRs are not agile: When OKRs are rigid, the model does not provide any room for people to make mistakes, abandon OKRs, or be agile. The OKR model is meant to inspire people and drive better alignment, focus, engagement, and performance.
OKRs don’t flow quickly down the corporate hierarchy: Some enterprises find it difficult to align corporate OKRs with portfolio and team OKRs. Thus, it takes a considerable amount of time for them to cascade strategic OKRs to the teams.
When conflicting priorities are tough to resolve: With conflicting priorities, planning becomes a nightmare and it might consume a considerable amount of time and effort to lock down OKRs for each quarter.
What's the future of Agile? This article will discuss the current and future trends for the Agile methodology.
Where Are We Today?
Agile was formulated in 2001 with a Manifesto for Agile Software Development. Since then, several enterprises across the world have adopted the agile methodology. Most organizations build complex products using Agile frameworks such as Scrum, Extreme Programming, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), or Crystal. Several organizations leverage the Lean methodology alongside the Agile methodology and track their work using the popular Kanban method. Since these frameworks didn't address the specific problems faced by large organizations, many organizations also adopted scaled Agile frameworks such as Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Disciplined Agile Delivery (DaD).
With increased Agile maturity, teams adopted DevOps practices such as Continuous Integration (CI), Automated Builds, and Continuous Deployment (CD), as well as practices as Behaviour-Driven Development (BDD), Test Driven Development (TDD), Acceptance Test Driven Development (ATDD), Automated Unit Tests, and so on...
What's The Future Of Agile?
The next big thing in Agile is the Purpose-Driven Development (PDD). There is a clear need to understand enterprise's objectives or purpose, program objectives, and product goals before starting development on any product feature. The product goals, when mapped to primary personas and to enterprise OKRs, bring the maximum benefit. Not only do they drive the product roadmap, they also bring alignment across product stakeholders.
Thus, the future is to bring strategic planning to the product. Leaders should invest time in understanding their customers or users, their problems, and how the product can benefit them. The personas, together with enterprise objectives, should drive the product's purpose or goals, which in turn, should drive the product's roadmap.
If product goals no longer align to enterprise objectives or the persona's needs, then the enterprise should have the agility to quickly adapt to the change, move funds or people, and re-plan priorities.
What is Enterprise Agility? What are the expectations vs the reality of Enterprise Agility (EA)? This article covers the six pillars of EA that sums up the expectations or the future state along with the actual state of things.
"The rate of change is not going to slow down anytime soon. If anything, competition in most industries will probably speed up even more in the next few decades." - John P. Kotter
Enterprise Agility is centered on the ability of an enterprise to quickly respond to change. Agile enterprises are expected to have:
The planning agility represents the flexibility of an enterprise to change its priorities considering changing market conditions or emerging technology trends. The expectation is that an enterprise is able to reprioritize and realign its business priorities quickly with changing market conditions or customers' preferences.
This is closely related to the planning agility. In order to quickly adapt to changing market conditions or emerging technologies, an enterprise must have the flexibility to move its funds or resources around, across teams, departments, and products, depending on the need.
Enterprise agility can only be achieved when all teams across an enterprise have adopted the agile mindset, values, and principles. For a team to be agile, they must adapt to change, learn to collaborate, self-organize their work, and consistently deliver high-quality work to generate business value.
Teams achieve technical agility by leveraging engineering practices to deliver high-quality products quickly. Some of these practices include continuous focus to architecture and quality design, test-driven development (TDD), behavior-driven development (BDD), continuous integration (CI), continuous deployment (CD), creating unit tests, and ensuring code quality.
This is an important competency for enterprise executives and leaders to develop. Leadership agility is the ability to make effective decisions, inspire people, and act with an understanding of what it takes to lead in a rapidly-changing world. With more agility, leaders become more collaborative and proactive in leading teams and driving organizational changes.
In an agile enterprise, it is important to integrate HR and other supporting departments such as Finance, Sales, Marketing, etc. with the product development process and introduce agility into their work.
But, are enterprises “truly agile”? Are you able to quickly adapt to the changing market conditions or emerging technology trends? When your corporate strategy/goals shift, how soon will the change flow from the corporate level to your own products? How soon will funds move from one product to another or from one release train to another?
Let's take a step back and think - does your roadmap even align with your corporate goals? How often do you revisit your product roadmap?
The reality is that change is slow. Larger the organization, more difficult it is to be agile. If the enterprise has adopted Scrum or Kanban, or SAFe, it doesn’t mean that they can quickly adapt to change. With SAFe, the product priorities are revisited on PI boundaries, thus it could take around 10-12 weeks to realign priorities. It may take even more time to move funds and resources between different departments. Enterprises often compromise their agility to have the desired predictability.
What is the Agile Scrum Framework? How is it different from the Kanban approach. If you are applying the Scrum framework and leveraging the Kanban board, you might be thinking that Scrum and Kanban are the same. In addition, you might be wondering which methodology is a better fit for your work.
In this article, I have listed the core differences between Scrum and Kanban. Moreover, I also covered which framework is best suited with different type of work or teams.
Scrum in a nutshell
Scrum is an iterative and incremental Agile process framework to build complex products of the highest possible value. In Scrum, the team always works on the highest priority items first. The work is performed in short, time-boxed iterations or sprints. Each sprint begins when the team commits to complete prioritized user-stories based on their available capacity in the sprint. An iteration ends when the team has delivered a potentially shippable product increment of the product. Therefore, the scrum development team delivers business value to users at the end of each sprint.
The three Scrum roles - Product Owner, Scrum Master, and the Development Team - are defined below:
A Product Owner decides what needs to be built and in what order.
A Scrum Master acts as a servant leader and coaches the team to follow Agile Scrum principles.
A Development Team is a group of self-organizing individuals who develop a high-quality product.
Scrum requires the below ceremonies to be conducted on a regular cadence:
Product Backlog Refinement
Above all, Scrum is most suited for complex projects where things are more unpredictable than they are predictable. In complex domains, there is a need to collaborate with others, have an innovative mindset to investigate, experiment with different ideas, and adapt based on the learnings.
Kanban is the most popular Lean framework. This approach works best for teams that have a continuous flow of incoming requests with different priorities. In the Kanban approach, each request or a work item is represented by a Kanban card that flows from one stage of the workflow to another until it is complete.
Kanban is very flexible in nature. New work items can be added to the backlog at any time. Even the workflow can change anytime. If team capacity changes, WIP limits get recalibrated. In addition, Kanban does not prescribe any roles or ceremonies. It optimizes an existing process by eliminating waste and improving time to market.
Below section lists the core differences between Scrum and Kanban:
Scrum was formulated for complex product development to mitigate the limitations with the traditional Waterfall approach. Kanban, on the contrary, originated to manage work and control inventory at Toyota with Just-In-Time and Lean principles.
Scrum prescribes product teams to manage work within time-boxed, short, and consistent length iterations or sprints. However, Kanban specifies a continuous flow of work across different states.
With Scrum, development teams create a potentially shippable product increment at the end of every sprint. Therefore, teams can release code at the end of every sprint if approved by the product owner. With Kanban, teams can release code anytime or on-demand.
Scrum requires three roles - Product Owner, Scrum Master, the Development Team. Kanban, on the other hand, does not prescribe any specific role.
In Scrum, the smallest piece of business value that a team delivers is a user story. Each user story may then be broken down into smaller tasks or sub-tasks. However, in Kanban, each work item is represented as a Kanban card.
Scrum is best suited for complex product development efforts that are unpredicatable in nature. Such complex efforts require research, experimentation, and an emergent design. Kanban, on the contrary, is best suited for simple and complicated efforts where things are more predictable than they are unpredictable.
With Scrum, sprint review and retrospective ceremonies are conducted at the end of every sprint to inspect and adapt. Though Kanban does not prescribe any ceremonies, teams may conduct a review meeting on a monthly or a quarterly cadence to review cycle time, flow efficiency, etc.
Scrum prescribes user stories to be estimated in terms of story points. However, Kanban does not require work items or Kanban cards to be estimated. In Kanban, estimation is optional. Some teams choose to estimate their work to have more predictability while others prefer to split their cards such that each of the cards is of the same size.
With Scrum, the most popular metrics are sprint burndown and velocity. Other useful metrics are release burndown, release burnup, and sprint burnup. The most popular Kanban metrics is cycle time. Metrics such as lead time, throughput, cummulative flow diagram (CFD), and control charts are also leveraged.
Kanban has more flexibility than Scrum as new work items can be added to the workflow at any time.
Scrum prescribes ceremonies to be conducted on a regular cadence. For instance, the sprint planning ceremony must be conducted at the start of each sprint. Sprint review and retrospective ceremonies must be conducted at the end of each sprint. In addition, the daily stand-up must be conducted each day of the sprint. However, Kanban does not prescribe any cadence or ceremonies to be conducted. In Kanban, meetings are held as needed.
With Scrum, additional or new user stories should not be added to the active or an ongoing sprint. However, in Kanban, new work items or cards can be added anytime, provided the WIP (Work-In-Progress) limit hasn't reached yet.
In Scrum, the sprint backlog is reset after every sprint. However, the Kanban board is continuous.
To adopt Scrum, enterprises need to develop an agile mindset. Scrum requires a considerable change to the existing organizational structure and processes. As a result, leaders invest into Scrum training and create new roles or positions to build the best Scrum teams. On the contrary, Kanban does not require any significant changes to onboard onto this framework.
Now that you understand the differences between the two frameworks, you can decide which approach works best for your team. For more on Agile, Lean, Scrum, or Kanban, you may read below books:
You might ask whether Agile and Lean are the same or different. Which one is the best methodology for your business? Below are my views on the main similarities and differences between the two.
Similarities in Agile and Lean
The core similarities between Agile and Lean are listed as follows:
Lean development encourages to limit the work-in-progress (WIP). Agile methodology also promotes incremental development within short, time-boxed iterations. Both methologies have a similar approach to reduce the batch size.
Lean is very focused on Kaizen or continuous improvement. Agile, too, encourages inspect and adapt activities (such as product demo and retrospectives) that promote continuous improvement.
Teamwork is one of the core values defined in Toyota Way 2001. Lean methodology encourages collaboration between team members. Agile methodology also focuses on collaboration (refer to the two statements from the Agile Manifesto below):
Individuals and interactions over processes and tools
Lean is a customer-centric methodology. It delivers the best quality work in the shortest sustainable lead time. Similarly, Agile is customer-centric as well. For instance, the 1st Agile principle, ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.’ is customer-focused.
Just-in-Time (JIT) approach
With Just-in-Time (JIT) approach, teams build only what is needed, when it is needed, and in the quantities needed. Both Agile and Lean methodologies support this approach. In Lean, work items are pulled only when needed. In other words, a lean engineer starts working on a new Kanban card only when the WIP limit allows the same.
Similarly, Agile development promotes the JIT approach. It encourages teams to refine, design, and document only the prioritized work items. Moreover, Agile concepts, such as incremental development and emergent design, reinforce this approach.
Lean is the major proponent to eliminate waste. Agile methodology, too, supports this concept by delaying decisions until the last responsible moment (LRM). With Agile, any possible rework is minimized.
Differences in Agile and Lean
Some of the core differences between Agile and Lean are as follows:
Lean management was originated in the manufacturing sector. The original intent was to reduce waste within the Toyota Production System (TPS). Agile methodology, on the contrary, was conceived by the software developmentthinkers to solve problems with the traditional, plan-based approach.
Nature of work
Lean is best suited for:
Managing work that flows through different workflow states
Optimizing an existing workflow process
Simple and repetitive tasks
Eliminating blockers or waste
Agile, on the other hand, is best suited for:
Developing complex products
Managing work that requires research and experimentation
Delivering maximum business value
Adapting to frequent changes
Encouraging team collaboration
With Lean, the end goal is to deliver work that:
Is released within the shortest sustainable lead time.
Is carried out in the most economical way.
Has minimal redundancies or waste.
With Agile, the end goal is to deliver a product that:
Has the maximum business value.
Responds quickly to the changing business needs.
Is built incrementally and iteratively.
The Lean methodology is applied to improve processes in large enterprises and teams. With Lean, the Value stream mapping helps to visualize end-to-end journeys for large organizations.
On the other hand, Agile is most effective when applied to smaller teams, with a team size of 5-8 people.
Now that you understand the similarities and differences of Agile and Lean, you can select the methodology that works best for your team. Feel free to add a comment to this post and share your experiences with me.
This article covers 10 expert Agile tips and techniques for your reference. You can use these valuable insights to create effective, self-organizing teams. These agile tips are in no particular order, so feel free to skim down the list and read the ones that are most suitable for you.
Agile Tip # 1: Discipline
Discipline is the key ingredient in achieving extraordinary results. It brings stability and structure to one’s work or personal life. For instance, it takes discipline to attend scrum ceremonies, meet sprint commitments, and continually learn.
“Discipline is the bridge between goals and accomplishment.” - Jim Rohn
Agile Tip # 2: Team Collaboration
In Scrum, the entire development team is responsible to ensure that sprint commitments are met. A team member who has completed his assigned tasks should look to assist other team members who need help. In addition, the team should practice empathy towards others, learn new skills, and meets their commitments.
Agile Tip # 3: Story Point Estimation
Story points are a relative unit of measure for estimating user stories. A team’s story point estimate should include: 1) the amount of work 2) the complexity of the work 3) any risks or unknowns in doing the work 4) must-have items on your definition of done.
Agile Tip # 4: Splitting User Stories
Split your stories into small stories. In other words, you should resist the temptation to group items together to avoid the management or process overhead. Smaller stories flow better through the sprint. For example, imagine 1,000 marbles working their way down a chute rather than 100 basketballs working their way down the same chute. Therefore, smaller stories are easier to estimate and have less variability than large stories.
Agile Tip # 5: Define personas
Define personas for your product and write persona-based user stories. A persona is a fictional character that you create based on your user research to represent different users that might use your product. In conclusion, understanding the characteristics, experiences, behaviors, and needs of your personas will help you to write valuable user stories.
Agile Tip # 6: Maximize the business value
It is important that you understand the business value associated with each prioritized user story.
"Your job isn't to build more software faster; it's to maximize the outcome and impact you get from what you choose to build." - Jeff Patton
Agile Tip # 7: Focus on One Thing
Are you multitasking or is it context-switching? Research suggests that productivity can be reduced by as much as 40% by the mental blocks created when people switch tasks. Therefore, not only should you work exclusively on what's most important, but you should also look to minimize the number of different things you work on at any given time.
"Extraordinary results are directly determined by how narrow you can make your focus." - Gary Keller
Agile Tip # 8: Prioritization
Product owners should consider both importance and urgency when prioritizing product backlog items for the team. In Scaled Agile Framework (SAFe), WSJF or Weighted Shortest Job First technique is used to sequence jobs and ensure maximum economic benefit. Read more here.
"What is important is seldom urgent, and what is urgent is seldom important."- Eisenhower.
Agile Tip # 9: Clean Code
Write a clean and high-quality code to minimize technical debt.
"Anyone can write a code that a computer can understand. Good programmers write code that humans can understand."- Martin Fowler, Author, and Programmer
Agile Tip # 10: Sprint Retrospectives
Sprint Retrospectives provide explicit opportunities to improve the existing process. In addition, retrospectives promote ownership and responsibility with respect to all aspects of the process.
"If you adopt only one Agile practice, let it be retrospective. Everything else will follow." - Woody Zuill
Also, read these expert Agile tips and techniques on Medium.
The Agile Manifesto is comprised of 12 Agile Principles that set the foundation for being agile. Often, people interpret these principles in different ways. In this article, I will break-down each principle into smaller phrases or words to clarify its meaning. Let's dive into each one, understand what they really mean, and be agile.
12 Agile Principles Explained
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
What does this Agile principle mean? The phrase “our highest priority” signifies that the entire product team should know their priorities and should work on the highest priority items first. The highest priority for the product team is to “satisfy the customer” such that the product meets the needs of the customer. The phrase “early and continuous delivery of valuable software” implies that the work completed during the iteration must be demonstrated to the customers as soon as it meets the ‘Definition of Done’ to get their early feedback. Moreover, the team must strive to deliver valuable software to the customers at the end of each time-bound iteration.
Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Agile Principle 2 - Welcome Changing Requirements 🙂 Just Kidding! Photo by rawpixel on Unsplash
This Agile principle focuses on embracing change. The phrase “welcome changing requirements” signifies the importance of accepting revised business priorities. The phrase "even late in development" signifies that changes should be welcomed irrespective of the time and effort the team has already invested to develop a feature. It's hard not to get defensive! But, think from your customer's perspective and understand the business value or the key drivers of the change.
“Intelligence is the ability to adapt to change.” – Stephen Hawking
Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Let’s understand what this principle means. The phrase, “deliver working software” means that the Agile development team should target to deliver high-quality production-ready work at the end of each iteration. The team should target to deliver working software frequently, preferably, after every couple of weeks. The shorter the delivery timescale, the more incremental development happens with the lesser cost of change.
Principle 4: Business people and developers must work together daily throughout the project.
This principle focuses on collaboration between the business and the development team. The phrase “must work together daily” implies that Agile development teams must interact with product sponsors daily throughout the work execution.
“Individual commitment to a group effort – that is what makes a team work, a company work, a society work, a civilization work.” - Vince Lombardi
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
What does this principle mean? The phrase, “build around motivated individuals” emphasizes the importance of having motivated people on the team.
“Find people who share your values, and you’ll conquer the world together.” - John Ratzenberger
“Give them the environment and support they need” – this phrase means that agile leaders should provide the necessary infrastructure that development teams need to continuously integrate and deploy their changes and should trust the team to deliver valuable software to customers.
Principle 6: The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.
Out of the 12 Agile principles, this one is based on face-to-face conversation. Face-to-face conversations boost creativity, credibility, trust, and collaboration as people better understand feelings and reactions via body language and expressions. Moreover, face-to-face conversations promote friendliness and build relationships. Therefore, agile leaders, product sponsors, and business stakeholders must meet with the development team in-person regularly.
However, face-to-face conversations are often constrained by the geographical presence of the development team. Platforms for video conferencing provide the same benefits as that of face-to-face conversations and should be encouraged.
Principle 7: Working software is the primary measure of progress.
This Agile principle focuses on “working software”. The Agile development team must deliver high-quality work at the end of each iteration that can be released on-demand to end-users or customers of the product. Working software is the primary success measure. Other metrics such as productivity, committed vs actual work, and burndown charts are secondary.
Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This principle is all about self-organizing teams. The product architecture, design, and features emerge from mature self-organizing teams who can freely take decisions and remove temporary blockers on their own. If developers are free to make decisions, they tend to be more accountable, innovative, and collaborative. Such an environment is best suited for emergent design and iterative development.
“A self-organizing team has authority over its work and the process it uses.” - Mike Cohn
Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This principle focuses on inspect and adapt. The phrase “at regular intervals” signifies the importance of setting up a regular cadence to inspect and improve. Agile frameworks recommend regular practices such as product demo and retrospectives to continuously improve the process in an iterative way.
“Continuous improvement is better than delayed perfection.” - Mark Twain
Apply these 12 Agile Principles and be agile. Please post your valuable feedback in the comments section.
The Sprint Burndown or the Iteration Burndown chart is a powerful tool to communicate daily progress to the stakeholders. It tracks the completion of work for a given sprint or an iteration. The horizontal axis represents the days within a Sprint. The vertical axis represents the hours remaining to complete the committed work. The purpose of a sprint burndown chart is to show the total amount of work remaining.
Let's take an example. The below table shows the actual number of hours remaining at the end of each day within a Sprint to create a sample Sprint burndown chart. The table also captures data for ideal remaining hours. The ideal remaining effort is calculated by assuming a uniform rate of task completion each day. In the below example, you can see that the ideal and actual remaining hours were same at the beginning of the sprint, however, as the sprint progresses, the actual remaining hours vary from the ideal remaining hours.
Next, we will plot a sample Sprint Burndown chart using the above table data. The below diagram depicts the sample chart with ‘Date’ represented on the horizontal axis and ‘Remaining Effort (Hours)’ represented on the vertical axis.
From the above chart, you can conclude that:
There were no spillover stories since the actual remaining hours at the end of the sprint were zero.
The team started a bit slow in the first week of the sprint, but then caught-up during the second week.
Let's analyze the core differences between the plan-driven Waterfall approach and the Agile methodology.
In Waterfall methodology, project development flows steadily downwards like a waterfall from one phase to another. The common phases are: Define, Analyze, Design, Build, Test, Launch, and Maintain. The preceding phase must be completed and signed-off before the next phase can begin. In Agile methodology, work evolves in an iterative and incremental manner with an emphasis on collaboration, responding to change, and continuous improvement. Its core foundation was laid with the Agile Manifesto for Software Development in 2001.
The Waterfall methodology encourages conformance to plan and processes, however, the Agile methodology values people interactions more.
Waterfall is the plan-driven or the traditional project management approach that requires comprehensive documentation, whereas, the agile methodology focuses on working software over comprehensive documentation.
The plan-driven or the Waterfall approach restricts new ideas that arise during design, build, or test phases of the project, whereas the agile methodology encourages experimentation and new ideas at all times.
Waterfall promotes a process-centric environment, whereas Agile promotes a people-centric environment.
With Waterfall methodology, projects are dependent on contract negotiation with customers or suppliers, however, Agile encourages customer collaboration more than contracts.
The traditional Waterfall methodology requires conformance to a detailed project plan, whereas, the Agile methodology embraces change. The change control process in the Watefall methodoly is a very time-consuming process that requires a detailed impact analysis, a feasibility study, and possible re-distribution of resources/funds. With Agile, desired changes can simply be written as new user-stories/work items and can be added to the product backlog at any time.
Waterfall requires a continuous effort to motivate the team. Most often, team members are not interested in the outcome of the project. On the contrary, Agile focuses on creating high performing, self-organizing, and motivated teams. In an Agile environment, team members understand the objectives and iteration goals and feel connected to the greater purpose.
The Waterfall approach requires huge rework to accommodate late changes during design, build, test, or rollout phases of the project. As a result, the cost of change in this approach is quite high. On the other hand, Agile welcomes change even late in development with minimal rework, keeping the cost of change low.
When Waterfall is synonymous with upfront planning, Agile is all about Just-In-Time (JIT) planning.
With the Waterfall methodology, there's a high possibility of mismatch between approved requirements and the released product, whereas, Agile encourages frequent feedback loops that reduce any mismatch between expectations and results.
Often, with the Waterfall approach, customers stay unhappy in spite of the effort put in by the development team. Agile methodology is customer-focused. Customers stay delighted due to frequent feedback and quick response to changes or team agility.
Waterfall requires upfront decisions and approvals for the requirements document, the design documents, test strategy, etc. In Agile, decisions wait until the last responsible moment (LRM). LRM is a strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.
In the Waterfall approach, there is a limited interaction between the developers and customers (especially once the design phase starts). On the contrary, Agile promotes frequent collaboration with customers with daily stand-ups, backlog refinement, iteration planning, and product demo, and retrospective ceremonies for each iteration or sprint.