Part 1 of the Project Management Blueprint: A Comprehensive Analysis of Agile, Scrum, Kanban, and Lean

Overview

In recent years, a variety of techniques have been employed in software development, including Waterfall, Agile, Scrum, Kanban, Lean, and Extreme Programming. Each method has its own advantages and drawbacks, and it is important for a development team to carefully evaluate the options before deciding which approach best suits their needs and goals.

In this essay, I will define various concepts and explain how they are related to and differ from one another. Of particular relevance are the terms associated with Lean Manufacturing, which originated from the Toyota Production System (TPS). As such, I will commence my discussion by exploring the origins of Lean Manufacturing.

Lean Methodology

Lean Manufacturing and Its Origins

The term “Lean Manufacturing” was coined to refer to the Toyota Production System (TPS) developed by Sakichi Toyoda, Kiichiro Toyoda and Taiichi Ohno. This production model was heavily influenced by Henry Ford’s ideas, particularly the concept of eliminating all forms of waste. In 1990, the book “The Machine That Changed the World” popularised the notion of “Lean Manufacturing”, thus introducing the concept to a wider audience.

Toyota’s TPS recognised three primary categories of waste:

• Muda:

  Toyota has identified seven distinct forms of muda, with an additional form added later. These forms of muda, which can be translated literally as “waste”, are as follows:

  • Defects:

    the time and effort required to identify and correct flaws

  • Overproduction:

    production in advance of demand

  • Waiting:

    waiting for the next manufacturing step, disruptions, and so forth.

  • Non-used Talent:

    underutilization of talents, insufficient training, and so on

  • Transport:

    products or moving components that are not necessary for processing

  • Inventories:

    inventory completed and work in progress

  • Motion:

    moving or walking more than necessary for processing

  • Excess Processing:

    as a result of inadequate tooling or product design

• Muri:

  Muri, which translates as “burden”, is the result of mura and/or muda. This can manifest itself in a variety of ways, such as breakdowns, absenteeism, safety concerns, and the like.

• Mura:

  Mura can be described as an imbalance or unevenness in a system. This can be evidenced in changes in customer demand, the time it takes for a product to complete its process, or the cycle times of different operators. When mura is left unchecked, it can lead to an increase in muri and muda. To reduce mura, organisations should strive for increased transparency in their supply chain, improved design of their products, and the generation of equal tasks for all operators.

TPS sought to decrease waste by using two key concepts:

• Jidoka:

  The concept of “automation with a human touch” suggests that quality should be an integral part of the production process. This implies that when a problem is identified, the machinery should be designed to automatically halt production, thereby preventing the manufacture of substandard items.

• Just-in-Time:

  Producing just “what is required, when it is required, and in the quantity required.”

These essential pillars and principles grew established as TPS progressed, building on the ideas of Jidoka and JIT:

• Continuous Enhancement:

  • Challenge:

    establishing a long-term vision and confronting problems with bravery and ingenuity in order to accomplish aspirations

  • Kaizen:

    Continuously enhancing company procedures, continually pushing for innovation and progress, removing one muda at a time

  • Genchi Genbutsu:

    By engaging in genchi genbutsu, which involves going to the source to obtain accurate information, we can make well-informed decisions, come to a consensus, and meet our goals in a timely manner.
• Respect for People:

  • Respect:

    respecting others and making every effort to understand one another, accepting responsibility and doing our best to foster mutual trust

  • Teamwork:

    encouraging personal and professional development, sharing development opportunities, and enhancing individual and team performance

• Andon:

  an indication of status or problem

• Heijunka:

  levelling refers to production levelling

• Hansei:

  implies self-reflection Workers should question the assumptions behind present procedures in order to develop better ones.

• Kanban:

  a signboard used to regulate production visually

• Poka-yoke:

  Also known as mistake-proofing or error-proofing.

• Pull System:

  Material is brought into a workstation only when it is required.

• Seiri:

  is the waste-reflective principle. What is unneeded should be deleted, according to Seiri. This includes all of TPS’s initial seven wastes.

• Standardisation:

  By organising all tasks to take into account the physical limitations of human labour, we are able to create a production sequence that is free from confusion and errors. This ultimately leads to higher quality goods, consistency in the production rate, and continual advancement in our production processes.

Lean Management

Over time, the Toyota Product System and Lean Manufacturing matured and were implemented in a variety of domains, including management.

Lean Management encapsulated the core concepts of continuous improvement and respect for people into a framework of five fundamental Lean principles, which have been repeated and reinforced throughout the years in order to continually enhance efficiency and eliminate waste.

1. Identify Value:

   By product family, provide a value from the perspective of the end customer.

2. Map Value Stream:

   Identify all of the processes in the value stream for each product family, removing any steps that do not provide value wherever feasible.

3. Create Flow:

   Make the value-creating stages happen in a certain order so that the product flows smoothly toward the buyer.

4. Establish Pull:

   Allow consumers to extract value from the next upstream operation when the flow is introduced.

5. Seek Perfection:

   As the concept of value is articulated, value streams are identified, inefficient processes are removed, and flow and pull techniques are implemented, the cycle is repeated until a state of perfection is achieved in which perfect value is created with no waste.

When Womack and Jones released “Lean Thinking” in 1996, they codified these ideas and other parts of Lean management.

Lean Software Development

Since then, Lean has been used in management, software development, and other industries.

The software development industry was facing an imminent crisis during the 1980s and 1990s due to the protracted timelines of projects using traditional waterfall approaches. This created a huge disconnect between the initial identification of a business requirement and the delivery of a software solution, with some sectors, such as the aircraft industry, experiencing a gap of several years or even decades.

Over the course of multiple years, the needs of an organisation, its systems, and even the companies themselves have evolved. Unfortunately, this often resulted in initiatives being abandoned before completion or, even if completed, not meeting the business requirements originally set out at the outset of the project.

The Waterfall process incentivized stakeholders to take into account all aspects of their project, as contracts were written out even if the exact specifications were not initially known. This approach necessitated key decisions to be made in the requirements or design stages, and these choices were challenging to reverse without revising the contract and raising project expenses. Unfortunately, many software projects turned out to be unsuccessful, were delivered late and over budget, or failed to meet the customer’s expectations.

Due to the widespread dissatisfaction with the Waterfall approach, various influential individuals sought to improve the model. One of the earlier attempts at doing so was Rapid Application Development (RAD), which aimed at reducing waste by shortening the requirements and design stages by quickly producing a prototype and collaborating with stakeholders to further clarify their needs. Additionally, there was a shift towards iterative development, wherein a basic project was completed and further features were added in incremental stages. While these strategies were beneficial, they were unable to resolve the root issues associated with the Waterfall method.

In the 1990s and early 2000s, a number of authors wrote books that explored the application of Lean principles to software development. Dr. Robert Charette, in particular, released “Lean Software Development” in 1993, and then followed up with “12 Principles of Lean Software Development” a decade later in 2003.

In 2003, Tom and Mary Poppendieck published “Lean Software Development: An Agile Toolkit“, a book that outlined seven Lean Development concepts which are closely aligned with the seven types of waste that are identified in Lean Manufacturing. This book provides a comprehensive overview of the principles behind Lean Software Development and offers strategies for improving software development processes.

DIFFERENCES BETWEEN LEAN AND AGILE

One of the key contrasts between Lean and Agile, according to Dr. Charette, is that Agile is bottom-up, while Lean is top-down.

Goals

Charette’s Lean Software Development

1. 1/3 Human effort
2. 1/3 Development hours
3. 1/3 Time
4. 1/3 Investment
5. 1/3 Effort to adapt

The Agile Manifesto

1. Individuals and interactions
2. Working software
3. Customer collaboration
4. Responding to change

Principles

Charette’s Lean Software Development

1. Customer satisfaction
2. Value for money
3. Customer participation
4. Team effort
5. Everything is changeable
6. Domain, not point solutions
7. Complete, don’t construct
8. 80% Solution today
9. Minimalism is essential
10. Needs determine tech
11. Product growth is feature growth
12. Mind the limits

The Agile Manifesto

1. Customer satisfaction
2. Welcome changing requirements
3. Frequent cycles of delivery
4. Stakeholder collaboration
5. Culture of trust, support, and motivation
6. Face-to-face communication
7. Working software is the metric
8. Sustainable development
9. Technical excellence
10. Simplicity
11. Self-organising teams
12. Team reflection

Poppendieck’s Lean

1. Eliminate waste
2. Amplify learning
3. Deliver as fast as possible
4. Decide as late as possible
5. Empower the team
6. Build integrity in the product
7. See the whole process

Agile Framework

The Agile Manifesto and its Origins

At the same time that Charette and the Poppendiecks released their books seeking to address the same issues, the Agile Framework was designed. In order to address the problem, a collective of early Agile advocates convened at the Snowbird conference in Snowbird, Utah in February of 2001.

The Agile Manifesto was the result of a collective effort to create a methodology that would enable organisations to better respond to changing customer demands, reduce waste, and deliver value in a more efficient manner. This methodology is based on the principles of incrementality and iteration, enabling organisations to quickly respond to changes and capitalise on emerging opportunities. By employing this iterative approach, organisations can reduce the time to benefit and quickly deliver value to their customers.

According to the Agile Manifesto:

“By doing it and helping others do it, we are discovering better methods of producing software.” This effort has taught us to value:

• People and their interactions

  over processes and tools

• Working software

  trumps extensive documentation

• Customer involvement

  in contract negotiations

• Responding to change

  by sticking to a plan

That is, although the goods on the right have worth, we value the ones on the left more.”

The 12 Agile Manifesto principles are aligned with the manifesto’s values:

“We adhere to the following principles:

1. Our first aim is to satisfy the client by delivering useful software on time and on a consistent basis.
2. It is important to be responsive to changing needs, especially if modifications need to be made late in the development process. By adopting agile methods, organisations can take advantage of changes to gain a competitive edge for their customers.
3. Deliver functioning software on a regular basis, from a few weeks to a few months, with a preference for the shorter duration.
4. Throughout the project, businesspeople and developers must collaborate on a regular basis.
5. Build initiatives around motivated people. Give them the atmosphere and support they need, and trust them to do the task.
6. Face-to-face communication is the most efficient and effective way of transmitting information to and within a development team.
7. The key indicator of progress is functional software. Agile procedures foster long-term growth.
8. Sponsors, developers, and consumers should be able to keep up the pace forever.
9. Continuous focus on technical excellence and smart design improve agility.
10. Simplicity—the skill of doing as little labour as possible—is crucial.
11. Self-organising teams provide the finest architectures, requirements, and designs.
12. The team thinks on how to become more successful at regular intervals, then tweaks and modifies its behaviour appropriately.”

The implementations of Lean principles, such as Jidoka, Just-in-Time (JIT), Genchi Genbutsu, Kaizen, Hansei, Heijunka, and waste reduction, are all based on the aforementioned values and concepts. Each of these principles has a unique purpose and application; Jidoka is the automation of processes, JIT is the practice of producing only what is needed, when it is needed, Genchi Genbutsu is the concept of going to the source of the problem to analyse and solve it, Kaizen is the continuous improvement of processes, Hansei is the practice of self-reflection and improvement, Heijunka is the practice of levelling the production process, and waste reduction is the practice of minimising waste.

Software Development Using Agile Principles

Agile is a broad framework that encompasses any process that adheres to the Agile set of ideals and principles.

Here are several examples:

• Excessive Programming
• Scrum
• Kanban

Scrum

Scum’s Brief History

Scrum is a methodology for implementing Agile concepts that was developed independently by numerous persons, some of whom signed the Agile Manifesto:

• Hirotaka Takeuchi and Ikujiro Nonaka introduced the concept of “scrum” in a manufacturing setting in their seminal paper “The New Product Development Game,” which was originally published in the Harvard Business Review in 1986. This publication marked the beginning of a new era in production management, and their ideas have had a long-lasting impact on the field.
• Scrum was introduced at the Easel Corporation in 1993 by Jeff Sutherland, John Scumniotales, and Jeff McKenna.
• In the 1990s, Ken Schwaber’s business, Advanced Development Methods, adopted what would become Scrum.

In the 1990s, Ken Schwaber and Jeff Sutherland worked in collaboration to develop and enrich the framework to be utilised in the context of software development. To share their findings, they presented at a multitude of conferences. Schwaber then partnered with Mike Beedle to articulate the process in their 2001 publication, “Agile Software Development with Scrum.

Schwaber went on to create both of the major Scrum accreditation bodies:

• Scrum Alliance: It was founded in 2001. Create the Certified Scrum credentialing program.
• In 2009, Ken Schwaber made the decision to leave the Scrum Alliance, and subsequently established Scrum.org to introduce the Professional Scrum accreditation series.

Given the popularity of the Scrum framework in today’s project management environment, it has become necessary to develop additional frameworks and accreditation bodies to ensure the scalability of Scrum for larger teams and projects. Initially designed for teams of seven to nine people, these frameworks and accreditations provide the necessary tools to effectively manage larger teams and more complex projects.

• SAFe: Scaled Agile Framework
• LeSS: Large Scale Scrum
• Scrum@scale: Jeff Sutherland established Scrum at Scale.

Scrum Values

The Scrum Alliance states:

Scrum is an effective, straightforward system of principles and practices that enables teams to deliver products in small intervals, allowing for quick feedback, constant improvement, and a swift response to any changes. This system of agile development helps teams stay agile and react quickly to any changes in the market, ensuring that their product is as up to date and relevant as possible.

Scrum is an iterative, incremental and prescriptive methodology of software development, which is based on Agile concepts. Its values and principles, which are quite analogous to those of Lean and Agile, are presented in the form of tables below.

Overview of Scrum

Work is divided into sprints, which are short, time-limited iterations lasting from one to three weeks. This stands in stark contrast with Waterfall methodology, which requires extensive preparation. At the start of each sprint, the most pressing items in the prioritised Product Backlog, referred to as a pull system or heijunka, are selected for work. As the sprint progresses, the backlog is continually revised to meet changing needs. The objective is to have a functional software product at the end of each sprint, allowing for rapid feedback and review.

At the end of each sprint, the team convenes to review the completed tasks, evaluate the sprint’s success, and outline the next sprint’s timeline, rituals, and cadence, which have already been predetermined.

Cross-functional teams consisting of representatives from all of the necessary disciplines are utilised to conduct sprints. Daily progress is monitored and planned using visual tools, such as the scrum board and sprint burndown charts, in order to ensure the successful completion of the sprint.

A sprint’s tasks and activities are drawn from a backlog that has been prioritised according to the needs of the project. This strategy enables the project team to adjust to changing requirements and encourages ongoing feedback from the end users.

Scrum Teams

Scrum has three functions:

• As the Scrum Master, you serve as the leader and coach to the Scrum team. Your role is to facilitate cooperation, remove obstacles, and ensure the Scrum process is followed and protected. This could include organising and facilitating sprint rituals, making sure the product owner has a properly prioritised and groomed backlog, preventing the team from over-committing to a sprint, and verifying the Definition of Done is adhered to. It is important to note that the Scrum Master does not assign tasks to team members and is not held accountable for project completion.
• The Product Owner is the individual accountable for the successful delivery of the product. They are responsible for defining and communicating the vision of the product to the team and the company, as well as ensuring that business and market requirements are met. The Product Owner also has the important task of prioritising work that is to be done via the Product Backlog. They select which features should be released and when, collaborating with the team and other stakeholders to ensure that all necessary items are included in the backlog. At the end of each sprint, the Product Owner makes the final decision on the approval or rejection of the work performed.

• Team Member

  The Scrum team is an autonomous, multi-disciplinary group of five to seven people, who cooperate and support each other regardless of their roles as architects, programmers, designers or testers. All members of the team work together to achieve the set of objectives, deciding how much work can be accomplished during each sprint and taking responsibility for the plan (Genchi Genbutsu).

Flow of Scrum, Activities, and Ceremonies

Scrum, as previously described, has a defined flow as well as a set of rituals and tasks. The sprint flow is as follows.

SPRINT PLANNING:

Prior to the commencement of a sprint, the Scrum Master organises a sprint planning meeting with the Scrum team and the Product Owner. During this meeting, the Product Owner outlines the objectives of the upcoming sprint, while the team prepares their work according to these goals.

This is often accomplished by the following activities:

• Sprint Capacity:

  The sprint capacity is determined by the team, taking into consideration the number of days, team members, holidays, and so on.

• Sprint Objectives:

  The Product Owner is responsible for determining the goals of a sprint. It is essential that the Product Backlog be prioritised and groomed in accordance with these goals, ensuring that the most relevant stories are at the top of the list.

• Work Selection:

  Until the desired capacity is achieved, stories and tasks are taken from the top of the backlog and included in the sprint. The product owner will then explain the story behind these tasks, and answer any questions that the Scrum team may have, making any necessary modifications to the story until the product owner and the Scrum team have a shared and comprehensive understanding of it. When this process is complete, the team will have a recommended scope for the sprint.

• Task Breakdown:

  The Scrum team will conduct a thorough analysis of each story, ensuring that all acceptance criteria and the Definition of Done are met. They will create a list of subtasks necessary for the successful completion of the story, and assess the estimated time to complete each task. If necessary, the story estimate will be revised.

• Sprint Commitment:

  After all the stories have been broken down and the estimations revised, the initial scope of the first sprint should be evaluated. It may be necessary to delete stories from the sprint and move them to the backlog, or to add new stories. Once these changes have been made, it is only the Scrum team that should commit to completing the work in the sprint, and the sprint can then begin.

Story points represent the overall amount of effort or scope committed to during the sprint.

EXECUTION IN SPRINT

During the sprint, team members will work on items from the sprint To Do list, which may include user stories, tasks, or their subtasks. Each of these items will be handled by different members of the team. As they progress through the item, they will update the state of the item on the Scrum Board by moving it from one column to the next (typically To Do, In Progress, Testing, and Done, or any other variation of this sequence) until it has been completely finished.

A Burndown Chart is a useful tool to monitor progress when working on narrative tasks. It illustrates the amount of work performed and the amount of work left to be completed, by plotting the remaining narrative points on the Y axis and the remaining time on the X axis. The chart is updated as stories are completed.

On a daily level, the Scrum Master is concerned with:

• Facilitates the daily standup meeting, which is used to organise the day and monitor progress (see below)
• Ensures that the team has a daily strategy.
• Removes obstacles
• Keeps distractions away from the sprint scope and the team.
• Maintains the team’s burndown chart and other Scrum information.

Daily Standup

At the start of each sprint day, the Scrum Master leads a concise 15-minute meeting with the Scrum team and product owner. This meeting is designed to assess sprint progress and plan out the day ahead. During the meeting, each participant stands in front of the Scrum Board and answers a set of questions in two minutes or less, while referring to specified items on the sprint board.

• What did you do the day before?
• What are your plans for today?
• Is there anything keeping you from finishing your work?

By allowing all members of the team to observe the progress of each individual’s work, it is possible to gain a comprehensive understanding of the collective progress being made. Furthermore, this visibility can help to identify any potential obstacles that need to be addressed, as well as any assistance that may be necessary to ensure success.

COMPLETION OF A SPRINT

Before planning the next sprint, the Scrum Master organises two rituals to finish down the sprint.

Sprint Demonstration

At the end of the sprint, the Scrum Master will hold a sprint demonstration meeting, in which each completed story is presented to the product owner and the rest of the team in the form of working software. If the acceptance criteria for each story have been met, the product owner will either approve or reject the story. If a story is not accepted, any deficiencies will be documented, and the story will be added back to the product backlog in its original priority order to be completed later or not at all. In cases where elements of a story do not meet the product owner’s expectations, they may be separated into separate stories, and the original story can then be closed.

At the end of the sprint, the total amount of story points achieved was calculated (also known as Velocity). This metric is used to monitor the productivity level of the team and can be used to predict when certain features or releases will be completed.

Sprint Review

The Scrum Master should facilitate a sprint retrospective after the sprint demo and before the next sprint planning meeting. During the retrospective, the team should discuss their successes and failures from the previous sprint, in order to continuously improve their processes and the quality of their work (Kaizen, Hansei). Various retrospective styles and activities can be used to generate conversation and help the team reach the desired objectives.

A list of action items for improvement has been created, which could potentially lead to the addition of items to the product backlog, modifications to the Definition of Done (DoD) or the team charter, or could result in other outcomes.

MANAGEMENT OF PRODUCT BACKLOGS

Product Backlog Development

Before a sprint can be planned or executed, the Product Owner must create a product backlog which initially includes feature development stories, composed by the Product Owner, followed by any development or Quality Assurance tasks, spikes, and defects which may be added by any member of the team. The items of the backlog are organised in order of priority.

Grooming the Backlog

The ongoing backlog grooming process takes over once the initial product backlog has been created and prioritised. The goal is to always have the highest priority items in the backlog groomed and estimated to the point that they can be included in a sprint during the sprint planning meeting. This is typically accomplished through regular backlog grooming sessions that the Scrum Master organises with the product manager and the team.

Prior to the grooming meeting, a list of tales is provided to the team for evaluation and preparation. During the meeting, each item is carefully considered in terms of its acceptance criteria, complexity, risk, size, implementation plan, and other relevant elements. The product owner, Scrum Master, and the team then review and modify the story details until all parties are in agreement. Afterwards, the team will employ a method known as planning poker to estimate the story points of the narrative.

Story Point Calculation

Story points are a method of estimating the amount of effort required to complete a task by comparing it to previously completed tasks of a similar nature. This involves making a subjective evaluation of the complexity of a task relative to other tasks that have already been completed, and is often used to determine the amount of effort that a given task is likely to require. By comparing tasks to one another in this way, stakeholders can gain an understanding of how much effort is likely to be needed for a given task and better plan for resource allocation.

The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.) is the most commonly used scale for comparison. This scale works by doubling the size of each increment, so that a five-point story is roughly twice as big as a three-point story. Other scales, such as T-shirt sizes (XS, S, M, L, XL) or even fish (minnow, goldfish, trout, tuna, whale, etc.), may also be employed. Ultimately, any scale that allows for comparison of the size of one object to another will suffice.

Story points are a metric used by teams to represent the amount of work required to complete a story. This includes all aspects of a project, such as programming, testing, design, and any other activities needed to reach the established Definition of Done. When determining the size of the story, teams must consider the quantity of effort, the complexity, and the risk involved in the task. Once these factors have been taken into account, a size on the scale is assigned to the story, which serves as the estimate.

Prior to the process of estimating story points, teams should create a baseline for reference by selecting a “most medium” sized tale that the whole team is familiar with. Additionally, the team should also choose a few larger and smaller tales for further comparison.

Using Planning Poker, story points are estimated at grooming sessions and occasionally during sprint planning:

1. Each team member/estimator is given a deck of cards.
2. As previously indicated, backlog items are addressed one at a time.
3. After the subject has been thoroughly reviewed, each estimator selects a card to symbolise their estimate in private.
4. Once all of the estimators have completed their calculations, they will reveal their cards simultaneously.
   • If all estimates agree, estimators move on to the next backlog item and continue the procedure.
   • When estimates disagree, the estimators debate the subject in order to reach an agreement.

The following are the benefits of estimating tale points:

• Quick:

  Estimates are based on previously completed product backlog items.

• Accurate Enough:

  precise enough to provide a high-level overview, plan future work, prioritise, and manage expectations

• Embraces Uncertainty:

  Story points define an undefined time span. Choosing a Fibonacci-like sequence of narrative points enables for the capture of ambiguity.

• Team Sport:

  All stakeholders, including developers, designers, Quality Assurance (QA) personnel and product managers, are actively involved in the process. Multiple perspectives are employed to approximate the scope of the task, however, only team members who are responsible for executing the work may provide an accurate estimate.

• Measures Team Velocity:

  The team’s efficiency can be gauged by quantifying the amount of work achieved during a sprint in relation to the amount of time spent on the task. As the team matures and gains experience, the amount of story points delivered per unit of time will increase, indicating improved productivity.

Estimation and tracking of releases

In a release planning environment, story point estimation is also utilised using the following technique:

1. Make a list of all the articles that need to be sized.
2. Arrange the items from the smallest to the largest.
   • Consider the first and second user articles.
   • Choose the larger one and place it underneath.
   • Then pick the next one and figure out where it sits in relation to the previous two.
   • Repeat the procedure until all of the tales have been added to the list (in a sequence from smallest to largest)
3. Size the articles

By combining the story estimates for all of the stories in a release with the team’s velocity, it is possible to accurately forecast when a release will be completed and track its progress accordingly. This information is often presented in the form of a release burn-up chart, which provides a visual representation of the progress made towards the completion of the release.

Scrum Artefacts and Terminology

• Product Backlog:

  A catalogue of all work items for a certain product, including features (stories), technical tasks, spikes, and faults.

• Release Burn-up:

  A graphical chart is used to illustrate the progress of a release and to anticipate the completion date based on Sprint Velocity. The vertical axis on the chart denotes the number of narrative points that have been completed, while the horizontal axis shows the number of sprints.

• Sprint Backlog:

  A backlog of all work items to be done during a sprint. During the sprint planning meeting, the sprint backlog is decided upon.

• Scrum Board:

  A Scrum Board is a type of tabular board that is used to visually track the progress of work within a sprint. The top of the board is divided into columns, each representing a different stage of the sprint, and work items are moved through each column until they have been completed. This board should be populated during the sprint planning meeting, and then reset at the end of each sprint.

• Sprint Burndown:

  A graphical representation depicting the progress of work completed and the amount of work remaining to be done in narrative points throughout the duration of the sprint can be produced. The Y axis of the graph will represent the number of narrative points that have yet to be completed, and the X axis will represent the amount of time left until the end of the sprint.

• Sprint Velocity:

  The number of story points completed by a Scrum team in a sprint.

• Impediments Backlog:

  The Scrum Master has an important role in ensuring the team’s progress. To this end, they must address any potential obstacles that might impede their progress. When a team member encounters an obstacle that is blocking their progress, they should submit the issue to the obstacles queue, so that the Scrum Master and the team can be made aware of the issue. The Scrum Master then has a responsibility to work with the team to address the obstacle, allowing them to continue working.

• Epic:

  An epic is a vast piece of work made up of many linked user tales.

• User Story:

  A user narrative is an explanation of a software feature written from the perspective of the end user. It outlines the desired outcome of the user, their motivation for this outcome, and the acceptance criteria to meet the user’s expectations. The product owner is responsible for creating and maintaining the user stories based on the user narrative.

• Task:

  A task is an element of work assigned by the Scrum Master or a team member that can be directly or indirectly associated with user stories. These tasks typically involve technical aspects and must meet specific approval criteria.

• Spike:

  A spike is an investigative technique employed when one needs to explore, prototype, and/or plan before deciding how to implement or estimate a user story. It is a useful tool for gaining insight into the requirements of a particular project.

• Subtask:

  A subtask is an individual task that is identified as part of the process of achieving a user’s desired outcome or completing a task. These subtasks are typically identified during a team’s sprint planning meeting and are intended to break down larger tasks into discrete objectives that can be addressed independently. By decomposing complex tasks into manageable subtasks, teams can more easily identify and assign work, track progress, and achieve their goals.

• Story Point Estimates:

  A Fibonacci-based relative size estimate scale (1, 2, 3, 5, 8, 13, 21…)

• Acceptance Criteria:

  The set of story-specific, tested elements that must be performed before a product owner can consider a narrative as done.

• Definition of Done (DoD):

  The team has come to a consensus regarding the typical processes or criteria that must be fulfilled for a tale to be considered complete. These processes or criteria have been noted and recorded in order to avoid having to include them in every tale.

Scrum’s Benefits and Drawbacks

The key advantage of Scrum is its incorporation of Agile principles, as well as Lean concepts such as Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System, and Iterations. Following these guidelines allows project teams to gain constant feedback, quickly respond to changing needs and uncertainties, reduce waste, improve visibility and transparency, and strive for ongoing progress. Additionally, Scrum is more customer-centric because it focuses on the most important items in the product backlog and works in short iterations that always create usable software. This enables customers to evaluate what they like (and don’t like) and make modifications as required. The cost of process and management is also lower, resulting in faster and more cost-effective outputs.

Scrum is a highly recommended approach for projects that have uncertain and/or dynamic requirements. This is applicable for a large portion of projects. Additionally, Scrum is ideal for experienced and motivated teams, as it provides them the autonomy to organise their work, while offering visibility, transparency, and accountability for their progress and any obstacles. Ultimately, this will enable teams to become more effective and productive in the long run.

Scrum has various drawbacks and is not the optimal approach in some situations:

• Transparency:

  Scrum encourages openness and accountability, which can be both beneficial and detrimental. On the one hand, it can reveal areas of improvement and inadequate performance; however, if not managed within the context of the Scrum philosophy of continual growth and development, it can cause friction and resistance.

• Team Experience and Commitment:

  Incorrect implementation of the Scrum methodology by teams or Scrum Masters who lack experience and/or commitment can cause significant problems. As Scrum teams lack designated roles, and all members are expected to take on a variety of tasks, successfully executing the Scrum process and improving over time necessitates the involvement of members with the necessary technical expertise. Furthermore, if other areas of the business are unconvinced of the benefits of Scrum, this can be extremely detrimental.

• Scope Creep:

  Stakeholders have the potential to add to the scope of a project, however, this can be a detriment if there is no deadline in place. One of the primary advantages of using Scrum is the malleability of the scope and priorities of the project; however, this advantage can become a detriment if the team is not disciplined in its approach.

• Poorly defined work:

  Poorly defined and understood user stories or activities can lead to a number of issues, such as rework, erroneous estimations, and scope creep. It is essential for the product owner to be able to accurately articulate their desired outcome in conversations and user stories. In spite of the fact that Scrum emphasises the importance of functioning software over documentation, an effective understanding of user stories and activities is essential in order to ensure successful project delivery.

• Scaling:

  Adopting the Scrum paradigm in big teams is difficult since Scrum is designed for smaller teams.

Kanban

What Exactly Is Kanban?

Kanban is a process which is more lightweight than traditional approaches, and which incorporates many of the core characteristics of Lean and Agile philosophies, as well as a selection of Scrum values and principles. The main distinctions of Kanban are its focus on visibility, flexibility, and the reduction of work in progress. By utilising these principles, organisations can identify and reduce unnecessary work and optimise their workflow.

Kanban is an approach to project and process management derived from Japanese word ‘Kanban’ meaning ‘signboard’ or ‘billboard’. Toyota line workers utilised a kanban (a physical board) to signify additional capacity at different stages of their production process. This concept has been adapted and implemented in software with a Kanban board, which is very similar to a Scrum board. This board includes a To Do list sorted by priority, as well as vertical columns that represent each possible stage of a work item. The process of transitioning work items from one state to another in the Kanban system is similar to the practice of Scrum; however, the amount of work in progress is strictly limited, depending on the capacity of the team. This is in contrast to the Scrum approach, which indirectly limits work in progress by controlling the amount of work scheduled for a sprint.

Kanban does not incorporate the same iteration and sprint structure that is seen in Scrum, meaning that work items are not routinely refreshed on the Kanban board — instead, they are moved from one stage to the next as needed. This lack of regular structure also implies that several Scrum ceremonies, such as sprint planning meetings, sprint demonstrations and sprint retrospectives, are not utilised. While daily standup meetings are not mandatory, they are often conducted by Kanban teams in order to facilitate a more streamlined process. Furthermore, some of the actions included in these ceremonies may be carried out informally when necessary. Continuous improvement is achieved by keeping track of the movement of items from one state to another, and making incremental changes based on any issues that are identified.

Kanban does not require assigning any roles, with the only necessity being that of a team member. Nonetheless, usually a project manager is present to oversee the team and the backlog. A single Kanban board may serve multiple roles and/or teams which only focus on items with a certain state. For example, a development team may transition items from the ‘To Do’ phase to ‘In Progress’ and then to ‘Testing’, while a test team may test items within the ‘Testing’ phase and then move them to ‘Done’.

Many backlog management activities, such as prioritisation and grooming of work items, are essential to ensure that each aspect of a work item is properly understood and ready to be undertaken; however, estimating work items is not an obligatory step.

Scrum vs. Kanban

Scrum

• Sprints with time limits
• Sprint traditions and responsibilities have been established.
• focuses on swiftly finishing a set of work
• sprint velocity
• Predictability is the focus.
• Limits Work in Progress at the Sprint Level Work is pulled in batches at the Sprint Level Sprint Strategy
• Has assigned responsibilities (Scrum Master, Product Owner, Team Member)
• Scrum Board is centred on a single multi-functional team.
• Only changes in the Product Backlog are permitted. Changes are not permitted during a sprint.
• More training is required. Ideal for teams who need major adjustments.

Kanban

• Continuous Supply
• Less procedure and overhead focuses on swiftly finishing specific things
• Cycle time is measured, and the emphasis is on efficient flow.
• WIP for individual goods is limited.
• Individual work items are retrieved.
• There are no predefined roles.
• Kanban Board may be structured around a single cross-functional team or many specialised teams.
• Changes are possible at any moment -> more adaptable
• Less training is required. This is ideal for teams that merely need incremental changes.

Summary

In this section, we explored some of the most widely adopted software development approaches, such as Lean, Agile, Scrum, and Kanban, along with their historical roots in TPS and Lean Manufacturing. In the next part of the series, we will further evaluate and compare different Software Development techniques, such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid approaches, thus providing you with a comprehensive overview of all of them in one place.