PhuNguyeAgileStudyReport201506

UDERSTANDING AGILE METHODOLOGIES 1
Understanding Agile Methodologies: Scrum, XP, Lean, and Kanban
Phu Nguyen
Bellevue College

Abstract
This paper summarizes a study of Agile methodologies for project management. The
study is based on the book Learning Agile by Andrew Stellman and Jennifer Greene as well as
six online resources for Agile project management and software development. The paper
explores four Agile school of thoughts: Scrum, Extreme Programing (XP), Lean, and Kanban.
Even though all of these Agile ways of thinking and doing are built around incremental and
iterative processes, each is developed for specific purpose. Scrum is an Agile methodology for
project management that relies on self-organization and collective commitment. XP is an Agile
methodology for software development that embraces changes. Lean is an Agile mindset that
promotes eliminating waste and seeing the whole. Kanban is an Agile method for process
improvement that focuses on flow and constantly improving. Agile practices can help teams
achieve better results than traditional project management and software development process
if teams and their organizations embrace the mindset behinds each Agile methodologies.
Keywords: Agile, Agile Manifesto, Agile values, Agile Principles, Agile Methodologies,
Scrum, XP, Lean, Kanban

Introduction
Agile project management has become popular in project management field, especially
Information Technology (IT) project management. Agile Manifesto organization was established
in 2001 to promote Agile software development. Since then, many groups have been formed by
Agile practitioners during its revolution, and often claim that Agile project management and
software development process give better results than the traditional project management and
the waterfall software development process. This study examines the four popular Agile
mindsets and methodologies Scrum, XP, Lean, and Kanban that have been practiced in project
management and software development fields.
Agile
According to Stellman and Greene (2015), Agile movement in software development
starts with ideas, values, and principles. In other words, it is a mindset that helps individuals
become more agile as practitioners, and more valuable as project team members.
Agile Manifesto
Understanding Agile begins with understanding its four simple values called Agile
Manifesto. According to the Manifesto for Agile Software Development, the Agile Manifesto
values are:
 Individual and interaction over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
It is important to notice that Agile Manifesto acknowledges the values of the items on
the right side in the above bullets, but it values the items on the left side (in bold font) more.
Stellman and Greene (2015) interpret these values as: a team should focus on its
members and their interaction first, and tools and processes second; delivering software that

users need is more important than delivering a specification of the software; treating
customers like team members to collaborate with; and incorporating changes to deliver
valuable software at the current moment is more important than working the plan.
The Agile Principles
There are twelve Agile principles besides the Agile Manifesto that guide Agile
practitioners to work on software project teams. According to the Manifesto for Agile Software
Development, the twelve Agile principles are:
1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in the 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. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
5. Businesspeople and developers must work together daily throughout the project.
6. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
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 reflect on how to become more effective, then turns
and adjusts its behavior accordingly.

Principles to Practices and Methodologies
Stellman & Greene (2015) group these twelve principles into four categories to help
practitioners understand the directions and insights these principles provide for Agile practices
and methodologies. The four categories are delivery, communication, execution, and
improvement.
Delivery (delivery the project): “Agile teams satisfy their customers by getting feedback
early in the project, and continuously delivering software to keep the feedback up to date
(Principle #1)” (p. 64). “They embrace change by treating project changes as positive and
healthy developments for the project (Principle #2)” (p. 64). “By using timeboxed iteration to
deliver working software frequently, agile teams constantly adjust the project so that it delivers
the most value to the customer (Principle #3)” (p. 64).
Communication (communication and working together): “Agile teams communicate
most effectively when they focus on face-to-face conversation and rely on the minimum
amount of documentation necessary for the project (Principle #4)” (p. 74). “Developers work
with business users every days so that they can deliver the most value (Principle #5)” (p. 74).
“Everyone on the agile team feels responsible for the project, and feels accountable for its
success (Principle #6)” (p. 74).
Execution (project execution): “The most effective way to communicate the progress of
the project is to deliver working software and put it in the hands of the users (Principle #7)” (p.
78). “Teams are most productive when they work at a sustainable pace and avoid heroics,
shortcuts, and overtime (Principle #8)” (p. 78). “Software that’s designed and implemented well
is fastest to deliver because it’s easiest to change (Principle #9)” (p. 78).
Improvement (constantly improving the project and the team): “Agile team keep their
solutions as simple as possible by avoiding building unnecessary features or overly complex
software (Principle #10)” (p. 81). “Self-organizing teams share responsibility for all aspects of
the project, from conceiving the product to project management to design and implementation
(Principle #11)” (p. 81). “By taking the time to look back and talk about lessons they learned

after each iteration and also at the end of the project, agile teams constantly get better at
building software (Principle #12)” (p. 81).

Scrum
Ken Schwaber and Jeff Sutherland developed an Agile methodology for software
development in 1990 that is now known as Scrum. According to Schwaber and Sutherland
(2013), Scrum is “a framework within which you can employ various processes and techniques.
[It] makes clear the relative efficacy of your product management and development practices
so that you can improve” (p. 3). In other words, Scrum is an Agile methodology for managing
projects. It has its own practices, values and principles that focus on self-organization and
collective commitment.
Scrum Values
Stellman and Greene (2015) listed five values that a team must embrace to become an
effective Scrum team: commitment, respect, focus, openness, and courage. They elaborate that
(p. 104-108):
Each person is committed to the projects’ goals. The level of commitment can be
achieved when the team has the authority to make decision in order to meet those
goals, and everyone has a say in how the project is planned and executed.
Team members respect each other. When team members have mutual respect, they’re
able to trust each other to do a good job with the work they’ve taken on.
Everyone is focused on the work. When a Scrum team member is working on a sprint,
that’s his only job for the duration of the sprint.
The teams value openness. When you’re working on a Scrum team, everyone else on
the team should always be aware of what you’re working on and how it moves the
project toward its current goals.
Team members have the courage to stand up for the project. Scrum teams have the
courage to live by values and principles that benefit the project.

Rules of Scrum
Schwaber and Sutherland (2013) explain that the rules of Scrum bind together the
events, roles, and artifacts, governing the relationships and interaction between them. The
detailed rules of Scrum can be found in The Scrum GuideTM, by Ken Schwaber and Jeff
Sutherland. A typical Scrum project follows these rules:
Scrum Team
The Scrum Team is a self-organizing and cross-functional team that consists of a Product
Owner, the Development Team, and a Scrum Master. The Product Owner is solely responsible
for managing the Product Backlog. The Development Team consists of 3 to 9 professionals who
organize and manage their own works to deliver a useable product increment at the end of
each Sprint. The Scrum Master is responsible for ensuring the Scrum team and related
organizations understand and adhere to Scrum theory, practices, and rules.
Product Backlog
Every project has a Product Backlog that lists all features, functions, requirements,
enhancements, and fixes that the users and stakeholders have bought into. Throughout the life
of the product, the Product Owner works with the Scrum Team to maintain and prioritize the
Product Backlog items based on feedback from the users and stakeholders.
Sprint
The product is incrementally and iteratively developed using a series of Sprints. A Sprint
is a time-box of one month or less during which a “Done”, useable, and potentially product
increment is created. A new Sprint starts immediately after the conclusion of the previous
Sprint. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work,
the Sprint Review, and the Sprint Retrospective. The Scrum Master coordinates these events
for a Scrum team during the product development. When doing development work, each
member of the Development Team collaboratively picks up tasks from the prioritized Sprint
Backlog and works on them.

Increment and Definition of Done
Each Sprint delivers a useable product increment. According to Schwaber and
Shutherland (2013, p. 15):
The Increment is the sum of all the Product Backlog items completed during a Sprint and
the value of the increments of all previous Sprints. At the end of a Sprint, the new
Increment must be “Done,” which means it must be in useable condition and meet the
Scrum Team’s definition of “Done.” It must be in useable condition regardless of
whether the Product Owner decides to actually release it.
Schwaber and Shutherland (2013, p. 15) also discuss about “Done” as follows:
When a Product Backlog item or an Increment is described as “Done”, everyone must
understand what “Done” means. Although this varies significantly per Scrum Team,
members must have a shared understanding of what it means for work to be complete,
to ensure transparency. This is the definition of “Done” for the Scrum Team and is used
to assess when work is complete on the product Increment.
Sprint Planning and Sprint Backlog
Each Sprint starts with a Sprint Planning done by the Scrum Master, Product Owner, and
the Development Team. The planning meeting is divided into two parts, each is time-boxed to
four hours. In the first part of the Sprint Planning meeting, the Product Owner works with the
Development Team to select the Product Backlog items for delivery in the product Increment at
the end of the Sprint, based on the Sprint objectives, the items’ functions, and the team’s
estimates. After selecting the items, the Scrum Team crafts a Sprint Goal that will be met
through the implementation of the selected items. In the second part of the Sprint Planning
meeting, the Development Team, with the Product Owner’s help, figure out the individual tasks
to implement the selected items. These tasks are work units of one day or less. The
Development Team negotiates with the Product Owner to keep the effort within one month
time-box. At the end of Sprint Planning, the selected items plus a plan for delivering them and
realizing the Sprint Goal become the Sprint Backlog.

Daily Scrum
After a Sprint Planning, the Scrum Team holds a 15-minute Daily Scrum meeting every
day during the Sprint to synchronize activities and create a plan for the current day. All team
members including the Scrum Master and Product Owner must attend. Each Development
Team member answer three questions:
 What did I do yesterday that helped the team meet the Sprint Goal?
 What will I do today to help the team meet the Sprint Goal?
 Do I see any impediment that prevents me or the team from meeting the Sprint
Goal?
If needed, the Development Team or team members will meet after the Daily Scrum for
detailed discussions, or adaptation for the remaining work of the Sprint. The Product Owner
must keep the Sprint Backlog up to date and visible to everyone. The Development Team can
request to add more work to the Sprint Backlog if they find that they will complete all work
early. If they however discover that they overcommitted, they need to inform the Product
Owner as soon as they realize that. The Product Owner can reset the expectations with the
users and stakeholders, and update the Sprint Backlog to match the team’s actual capacity. If
the team discovers that they cannot deliver working software, the Product Owner can
terminate the Sprint early and initiate new Sprint Planning.
Sprint Review
At the end of the Sprint, the Scrum Team holds a Sprint Review to demonstrate working
software to users and stakeholders. This is a four hour meeting for one month Sprints. The
demo only includes items that are completely implemented, tested and accepted by the
Product Owner as complete (or “Done”). Incomplete items are added back to the Product
Backlog together with the estimates for their remaining works. The Scrum Team will collaborate
with users and stakeholders about the Sprint’s result during the Sprint Review, answer their
questions, and get their feedback on the working software. The Product Owner will update
work items or add new work items to the Product Backlog to address all necessary changes

based on the feedback and collaboration. These changes will be considered in the next Sprint
Planning.
Sprint Retrospection
After each Sprint, the Scrum Team holds a Sprint Retrospective meeting with the
participation of the Development Team and Scrum Master (and optionally the Product Owner)
to identify process improvements. This is a three hour meeting for one month Sprints. Each
person will give feedback on what went well during the Sprint, and what can be improved in the
future. The Scrum Master documents any improvements that will be added to the Product
Backlog as nonfunctional items.

Extreme Programing (XP)
XP is an Agile methodology for software development that embraces changes. It
recognize the nature of change in system requirements during a software development cycle.
XP is made up of practices, values and principles developed by Kent Beck in early 1990s when
he worked on the Chrysler Comprehensive Compensation System project.
In a nutshell, a XP team uses a release planning meeting to collaboratively create a
release plan for the overall project. This release plan is then used to develop iteration plans for
each iteration which is typically one week long. The team holds an iteration planning meeting at
the beginning of each iteration to select adequate user stories and create a plan of
programming tasks. The whole team sits together in an informative workspace. They start each
day with a standup meeting. They write code in pair, develop unit tests first before coding, and
integrate their code continuously. They focus on simple solutions and incremental design, and
refactor whenever and wherever possible to improve the system design (Wells D., 2009).
The XP Values
Wells D. (2009) states on his page The Values of Extreme Programming that XP is based
on five core values that help individuals work in harmony with their personal and corporate
values. They help get the team into a mindset that naturally see great practices as the obvious
way to build quality software. The five XP values are (Wells D., 2009):
Simplicity: We will do what is needed and asked for, but no more. This will maximize the
value created for the investment made to date. We will take small simple steps to our
goal and mitigate failures as they happen. We will create something we are proud of
and maintain it long term for reasonable costs.
Communication: Everyone is part of the team and we communicate face to face daily.
We will work together on everything from requirements to code. We will create the best
solution to our problem that we can together.
Feedback: We will take every iteration commitment seriously by delivering working
software. We demonstrate our software early and often then listen carefully and make

any changes needed. We will talk about the project and adapt our process to it, not the
other way around.
Respect: Everyone gives and feels the respect they deserve as a valued team member.
Everyone contributes value even if it's simply enthusiasm. Developers respect the
expertise of the customers and vice versa. Management respects our right to accept
responsibility and receive authority over our own work.
Courage: We will tell the truth about progress and estimates. We don't document
excuses for failure because we plan to succeed. We don't fear anything because no one
ever works alone. We will adapt to changes whenever they happen.
In other words, “XP team focus on writing the most simple and direct solutions
possible”. “Each team member is aware of the work everyone else is doing”. “Constant tests
and feedback loops keep the quality of the product in check. Each team member is focused on
making the best choices for the projects, even if it means having to discard failing solutions or
approach things differently”. “Every team member is important and valuable to the project”
(Stellman and Greene, 2015, p. 196).
The XP Principles
In addition to the five core values, XP has a set of principles that provide more details
about how XP team think about their problems. Together, XP values and principles help guild
team in applying XP practices to their project. According to Stellman and Greene (2015, p. 201-
202), the XP principles are as follows:
Humanity: Remember that software is built by people, and there’s a balance between
the needs of each team member and the project’s need.
Economics: Somebody is always paying for software project and everybody has to keep
the budget in mind.
Mutual benefit: Search for practices that benefit the individual, the team, and the
customer together.

Self similarity: The pattern of a monthly cycle is the same as a weekly cycle and the
same as a daily cycle.
Improvement: Do your best today, and stay aware of what you need to do to get better
tomorrow.
Diversity: Lots of different opinions and perspectives work together to come up with
better solutions.
Reflection: Good teams stay aware of what’s working and what isn’t in their software
process.
Flow: Constant delivery means a continuous flow of development work, not distinct
phases.
Opportunity: Each problem the team encounters is a change to learn something new
about software development.
Redundancy: Even though it can seem wasteful at first blush, redundancy avoids big
quality problems.
Failure: You can learn a lot from failing. It’s OK to try things that don’t work.
Quality: You can’t deliver faster by accepting a lower quality product.
Accepted responsibility: If someone is responsible for something, they need to have the
authority to get it done.
Baby steps: Take small steps in the right direction rather than making wholesale
changes when adopting new practices.
The XP Primary Practices
The best known concept of XP methodologies are its 13 primary practices. To help make
a good sense of these practices, Stellman and Greene (2015) divide them into 5 categories in
term of software developments: programming practices, integration practices, planning
practices, team practices, and holistic practices.

Programming Practices
There are two practices that are designed to help those programmers write better code.
They are test-first programming and pair programing. Stellman and Greene (2015, p. 178-179)
wrote:
Test-first programing, also known as test-driven development (or TDD), it means that
before he writes code, he builds an automated test. These automated tests are usually
called unit tests.
In pair programing, two developers sit together at a single workstation when writing
code. In most case, one programmer types, while the other watches-and they constantly
discuss what is going on. One developer can take over typing when the other gets
mentally tired.
When build unit tests first, XP teams express the behavior that is expected of the code
to be developed. Then they write code that pass these tests. This practice creates a feedback
loop that helps to prevent defects. In addition, pair-programing provides immediate feedback
that will help catch any potential bugs as early as possible.
Integration Practices
Two XP practices focus on integration to assure the quality of the code that is developed
in to the codebase. They are as follows (Stellman and Greene, 2015, p. 180):
In 10-minute build, the team creates an automated build for the entire codebase that
runs in under 10 minutes. This build includes automatically running all of the unit tests
and generating a report of which tests passed and which failed.
In continuous integration, the team will use a version control system that has a central
master set of files, which individual developers will check out, or copy into a private
copy of the entire codebase that’s only used by that programmer (often called a
sandbox). The developer will work on the copy of the code in her sandbox, and
periodically check it back into the repository. Integrating continuously means that each
team member constantly keeps his or her own copy of the codebase up to date. Team

members periodically integrate the latest code from the repository back into their
sandboxes.
The 10-minute build helps XP encouraging continuous integration for quality check.
Individual developers use continuous integration to constantly integrate code changes from
their teammates so everyone’s sandbox is up to date. Any bugs introduced by new code will be
detected and fixed quickly.
Planning Practices
XP teams use iterative development to manage their project. These concept is well
demonstrated in three XP practices that are described by Stellman and Greene (2015, p. 181) as
follows:
In quarterly cycle, the team meets to take a look at the big picture. XP teams will talk
about themes, or larger ideas in the real world that they can use to tie their project’s
stories together. The team also steps back and talks about internal and external
problems that they’re experiencing, nagging bugs, and repairs that haven’t been
addressed yet. They take the time to reflect on the progress they’ve made so far, how
well they’re meeting their users’ needs, and how the project is going overall.
In weekly cycle, the XP team uses one-week iterations, and it works closely with the
stories practice. Each cycle starts with a planning meeting, where the team members
review the progress they’ve made on the project, work with the customers to pick the
stories for the iteration, and then break the stories into tasks that are estimated and
assigned to developers.
In slack, the team add minor, lower-priority stories to each weekly cycle. These stories
are broken down into tasks during the planning meeting, but those tasks are left for the
end of the iteration. That way, if the team runs into unexpected problems, it’s very easy
for them to cut out those “slack” stories and still deliver complete, working software at
the end of the cycle.

Another XP primary practice should be included in this category is Story. The software
developers work with their customers and users to write user stories which address who use
the system, how they use it, and what they use it for (Westfall, 2009, p. 208).
By practicing iterative development, XP teams make their planning decisions in last
responsible moment where they have enough information to make the best choices for their
development. In addition, making decisions as late as possible helps the teams stay flexible to
any changes occur during their projects.
Team Practices
XP is not just about programming. It is also about how teams work together. Stellman
and Greene (2015, p. 181-182) explain:
In sit together, the team sits near each other, and have easy access to everyone else on
the team. Team members constantly consult each other about problems, ask each other
for advice, and alert each other to problems.
In informative workspace, the team’s working environment is set up to automatically
communicate important project information to anyone who happens to be working in it.
When sitting together, XP teams absorb project information through osmotic
communication. Together with using information radiators like wall charts, they become truly
working in an informative workspace.
Holistic Practices
Stellman and Greene (2015) call these three XP practices holistic practices because they
are closely interconnected, and have to work together to be effective. They are described as
follows (p. 247):
Incremental design is about making code design decision at the last responsible
moment, avoiding trying to build everything at once. When the team has developed the
habits that lead them to build decoupled code made up of small, solid, independent
units, they don’t need to come up with the complete design up front. They can come up
with a high-level design, without having to think of every possible scenario that might

not fit into it. They can be confident that when they discover an edge case that isn’t
handled, they’ll have the tools in place to deal with it later. This frees people up to think
about the problem in the way they would naturally think about it, and to build the code
piece by piece as they learn more about the problem they are tackling. This is the idea
behind incremental design, and it results in a highly flexible, adaptable, and changeable
codebase. But it only works when every developer truly believes in making design and
code decisions at the last responsible moment. Everyone on the team needs to believe
that it’s faster to build a small, decoupled piece of the system today, and trust
themselves to fix it tomorrow if it isn’t quite right.
Energized work means establishing an environment where every team member is given
enough time and freedom to do the job. This keeps them in the mental space where
they can develop and use good habits that lead to better, more naturally changeable
code. This, in turn, lets them produce much more code, and deliver more valuable
features (and features that are more valuable) to the users and customers, in a shorter
period of time.
Whole Team is about helping the individuals on the team come together as a whole.
They encounter obstacles, they work together to overcome them. When there’s an
important decision that affects the direction of the project, that decision is made
together. Everyone on the team learns to trust the rest of the team members to figure
out which decisions can be made individually, and which decisions need to be brought
to the rest of the team.
The XP Corollary Practices
In addition to the 13 primary practices, XP also has 11 corollary practices. Stellman and
Greene (2015) describe them as follows (p. 214-215):
Real customer involvement: Bring customers into the quarterly and weekly planning
sessions-and actually listening to them.

Incremental deployment: Deploy small pieces of the system individually, rather than
one “big shot” deployment (also, believing that a system can really be deployed this
way).
Team continuity: Keeping effective teams together.
Shrinking teams: As a team improves, they can get more work done more quickly;
instead of adding work each week, remove a team member (and use that person to
bring the XP culture to another team).
Root-cause analysis: When something goes wrong, figure out what the problem was,
and then figure out why that problem occurred, and what caused that occurrence, and
eliminate the problem further upstream.
Shared code: Every person on the team feels comfortable working on any piece of it,
and everyone owns it collectively.
Code and test: Only the code and tests are maintained by the team; the documentation
is generated automatically from the codebase, and history is kept alive as word-of-
mouth culture (because people rarely crack open dusty binders of old project plans,
anyway).
Single codebase: Don’t manage multiple version of the code.
Daily deployment: Push a new version of the software into production every day.
Negotiated scope contract: For a consulting company, instead of fixing the scope and
negotiating time (and, often, sacrificing quality to meet the deadline), fix the time and
have an ongoing negotiation of the scope.
Pay-per-use: This another consulting-related practice-instead of charging for
development work, charge the customer when they use the system; this gives real-time,
constant feedback about which features are being used, and which aren’t.

Refactoring Practice
One practice XP teams adopt and use constantly is refactoring code, “changing the
structure of the code without changing its behavior” (Stellman and Greene, 2015, p. 237).
According to Stellman and Greene, each iteration as XP teams learn more about the system
functions, they try to refactor existing code to create simple code units that do unique
functions that can be reused in different areas of the system. This practice helps XP team
practice incremental design and make design and code decisions in the last responsible
moment. In addition, refactoring code help “build a codebase that is much easier to change” (p.
240) that enables XP teams to embrace changes during the software development.

Lean
Lean, also known as lean thinking, is an Agile mindset that aims to provide a new way to
think about organizing activities to deliver more value while eliminating waste. It was coined by
James P. Womack and Daniel T. Jones based on their study about Toyota Production System
that centers on Value, Value streams, Flow, Pull, and Perfection.
Lean Values
As any other mindsets, Lean comes with a set of values that provide guidance for lean
thinking. According to Stellman and Greene (2015), The Lean values are as follows (p. 270-271):
Eliminate waste: Find the work that you’re doing that doesn’t directly help to create
valuable software and remove it from the project
Amplify learning: Use feedback from your project to improve how you build software
Decide as late as possible: Make every important decision for your project when you
have the most information about it-at the last responsible moment.
Deliver as fast as possible: Understand the cost of delay, and minimize it using pull
system and queues.
Empower the team: Establish a focused and effective work environment, and build a
whole team of energized people.
Build integrity in: Build software that intuitively makes sense to the users, and which
forms a coherent whole.
See the whole: Understand the work that happens on your project-and take the right
kind of measurements to make sure you’re actually seeing everything clearly, warts and
all.
Lean Principles
Besides the Lean values, lean thinking have five fundamental principles for guiding the
implementation of lean techniques. Womack and Jones (2003) describe the five principle of
lean thinking as follows:

1. Specify Value: from the end users standpoint on specific products or services with
specific capabilities.
2. Identify the Value Stream: including all the activities necessary to create products or
services. These activities can be (1) activities that unambiguously create value, (2)
activities that create no value but seem to be unavoidable with current technologies
or production assets, and (3) activities that create no value and are immediately
avoidable. Eliminate activities that do not create value if possible.
3. Flow: Make the value-creating steps occur in tight sequence so the product will flow
smoothly toward the customer.
4. Pull: let customers pull value from the next upstream activity as flow is introduced.
5. Perfection: begin the process again [(from principle #1)] and continue it until a state
of perfection is reached in which perfect value is created with no waste.
Lean Thinking Tools
Lean comes with a set of ways to think that support Lean values. Stellman and Greene
(2015) call them Lean thinking tools (p. 272-273, 284, 288-289, 292-299, 304):
Last responsible moment: Support decide as late as possible value. Similar to Scrum and
SX, it is about making decisions at the last responsible moment.
Feedback: Support amplify learning. Similar to Scrum and XP.
Iterations: Support amplify learning. Similar to Scrum and XP.
Synchronization: Support amplify learning. Similar to continuous integration and
collective ownership in XP.
Set-based development: Support amplify learning. Running a project in a way that gives
you more options by having the team follow several paths simultaneously to build
alternatives that they can compare.
Self-determination: Support empower the team. Similar to ideas behind the XP
practices of whole team and energized work.

Motivation: Support empower the team. Similar to ideas behind the XP practices of
whole team and energized work.
Leadership: Support empower the team. Similar to ideas behind the XP practices of
whole team and energized work.
Expertise: Support empower the team. Similar to ideas behind the XP practices of whole
team and energized work.
Options thinking: Support commitment (part of Lean thinking). Seeing the difference
between something that you’re committed to and something that you have the right
(but not the obligation) to do.
Seeing waste: Support eliminating waste
Refactoring: Support build integrity in (internal integrity). Similar to refactoring of XP.
Testing: Support build integrity in (internal integrity). Similar to test-driven development
of XP.
Perceived integrity: Support build integrity in (external). How well the product meets
the needs of the person using it-and how well the person immediately see that his or
her needs are met.
Conceptual integrity: Support build integrity in (external). How well the features of the
software work together to form a single, unified product.
Measurements: Support see the whole. Everyone can see the project the same way.
Choosing the right measurement helps the team get a better picture of the project.
They will take different measurement depending on what problem they want to solve.
Taking objective measurement helps get everyone to see the project on the same term.
Root cause: Support see the whole. Understanding the actual reason that the problem
is happening. XP teams and Lean teams both utilize a technique called Five Why to
figure out the root cause of a problem. The team members ask why a problem

happened, and when they answer the question they continue to ask why (usually
around five times) until they discover a root cause.
Pull system: Support Deliver As Fast As Possible. A way of running a project or a process
that uses queues or buffers to eliminate constraints.
Queuing theory: Support Deliver As Fast As Possible. Make sure that people are not
overloaded with work; so that they have time to do things the right way. Queue is a list
of tasks, features, or to-do items for a team or for an individual developer. Queue has an
order, and are typically first-in, first-out. Lean tells us that making a team’s queue of
work public, and making it central to the decision-making process, helps teams to
deliver more quickly.
Cost of delay: Support Deliver As Fast As Possible. If a part was in short supply, a delay
in getting that part to the assembly line was very expensive; if the part was abundant,
the cost of delay was low.
Value stream map: Support See the Whole. A visual tool to help team see the reality of
how their project works by showing the entire lifespan of a minimal marketable feature
(MMF), including the work and waiting time at every state. MMF is the smallest “chunk”
of value or functionality that the team can deliver, such as a story or a user request-
something that might end up on a Product Owner’s backlog.
Work In Progress (WIP) area chart: Support Deliver As Fast As Possible. A visual tool
that shows how MMFs flow through your project’s value stream.

Kanban
According to Stellman and Greene (2015), Kanban is a method for process improvement
used by Agile teams. It is an application of Lean mindset to the way Agile teams work that
create a solid foundation for continuously improving their process. “When teams use Kanban to
improve, they focus on eliminating the waste from their process” (p. 315).
Kanban Principles and Practice:
According to Kanban Yahoo! Group Using the Kanban Method, David J. Anderson
describes Kanban defined Kanban method as follows:
First follow the foundational principles:
 Start with what you do now
 Agree to pursue incremental, evolutionary change
 Initially, respect current roles, responsibilities and job titles
Then adopt the core practices:
 Visualize.
 Limit WIP
 Manage Flow
 Make Process Policies Explicit
 Implement Feedback Loops
 Improve Collaboratively, Evolve Experimentally (using models/scientific method)
It is not expected that implementations adopt all six practices initially. Partial
implementation are referred to as “shallow” with the expectation that they gradually
increase in depth as more practices are adopted and implemented with greater
capability.
Stellman and Greene (2015) interpret the Kanban principles as Kanban teams should
start with understanding the current system for running their project, setting a goal of making

small improvements to that system, recognizing that the current roles, responsibilities and job
titles are important part of the system.
Visualize the Workflow
Stellman and Greene (2015) describes Kanban “visualizing means writing down exactly
what the team does, warts and all, without embellishing it” (p. 327). A Kanban team visualize
their system workflow using a Kanban board, consisting of columns represent each stage in the
workflow of a work item. Each work item in the system flows across the board as it advances
through the system. Each column has sticky notes to represent work items, usually stories not
task, in the associated stage. “It is important to understand that a kanban board visualizes the
underlying workflow and process in use” (p. 328), not what is on a process documentation.
During a “walking the board” meeting, which is often held daily, the team discusses the
state of each work item listed on the board. Items that are completed in the current stage
should be moved to the next stage in the workflow by moving the associated sticky notes to the
next column on the board.
Limit Work in Progress
According to Stellman and Greene (2015), “limiting work in progress (WIP) means
setting a limit on the number of work items that can be in a particular stage in the project’s
workflow” (p. 333). The WIP of a column limits the stories or features that can flow into the
associated stage of the workflow. It means to prevent the overburden because of work items
piling up at a bottleneck stage. Kanban teams initially choose a WIP limit that makes sense for
everyone in the team, then measure the workflow to adjust the WIP limit experimentally to
optimize the system performance.
After a column WIP limit is reached, the teams avoid performing work that will advance
work items into that column, and focus their effort on the work items on other columns whose
WIP limits have not been reached or columns that have no WIP limits. In other words, a column
with WIP limit becomes a queue where work items are managed smoothly and orderly. This will
keep the work items flowing through the system as efficiently as they can be.

To set a WIP limit for a column on a Kanban board, Kanban teams add a number to the
column that represent the maximum number of work items allowed in that stage in the
workflow. “Kanban teams work with their users, managers, and other stakeholders to make
sure that everyone agrees that when a column is at its WIP limit, they will focus their work
elsewhere in the project and not advance any more work items into that workflow stage” (p.
339).
Measure and Manage Flow
Stellman and Greene (2015) explain the rate at which work items advance through the
system is called the system flow. The system flow reaches maximum level when a team
deliveries work items at their optimal space with a comfortable amount of feedback. The less
unevenness and overburdening, the better chance for maximizing the system flow. As the team
is able to finish their work without dealing with bottleneck in the system, the system flow will
increase. If the team experience unevenness in the system because of work piling in a stage of
the workflow, the system flow will decrease. A Kanban team practices managing flow by
measuring the system flow and making necessary process improvements. They work
collaboratively to increase the system flow so that the unevenness and lead times can be
decreased.
Cumulative flow diagram (CFD) is an effective tool for visualizing the system flow using
area chart where each area on the chart represents accumulated work items in a stage of the
system workflow. In other words, the areas are corresponded to the columns on a Kanban
board (Stellman and Greene, 2015). In addition to the areas, CFD also shows the arrival rate
(the number of work items added to the workflow every day), the inventory (the total number
of work items in the workflow), and the lead time (the amount of time each work item flows
through the entire system).
The CFD helps Kanban teams see the performance patterns of their process over time,
so they can identify the bottlenecks and eliminate the root causes in the long run. As we know
Kanban teams use WIP limits to control the workflow in the day-by-day basis, and find the
optimal WIP limits by experimentation. When they get the WIP limits right, the arrival rate of

work items will eventually match the rate that the team can complete the work items. As a
result, the inventory trend and arrival rates will be flat, and the system becomes stable.
Little’s Law, a theorem that’s part of queueing theory, states (Stellman and Greene,
2015) that when the system is stable, the following is true:
L (average inventory) = W (average lead time) * λ (average arrival rate)
W = L / λ
When the system is stable (average inventory L is constant), Kanban teams can cut
down the work items’ lead time by increasing the arrival rate such as extending the starting
time between work items or features.
Stellman and Greene conclude that (2015, p. 357):
Controlling the flow across the entire project helps everyone on the team relax and
focus on the work that they’re doing now, without having to worry that tasks are piling
up behind them. They can trust the WIP limits to keep the chaos out. And they know
that if chaos starts to leak in, it will show up when they measure the workflow, and they
can adjust the WIP limits and cadence to keep work focused and flowing.
Make Process Policies Explicit So Everyone Is on the Same Page
Stellman and Greene (2015) elaborate that Kanban teams can make policies explicit to
everyone by simply writing WIP limits at the tops of the columns in a Kanban board, and adding
“definitions of done” or “exit criteria” to the bottom of each column to guide the team on when
work items can be advanced through the stages of their workflow. “This is especially effective
when these policies were established collaboratively and evolved experimentally by the whole
team, because it means that everyone understands why they’re there” (p. 358).

Conclusion
Agile Manifesto for Software Development provides four simple values for all Agile
methodologies and mindsets: individuals and interaction over processes and tools, working
software over comprehensive documentation, customer collaboration over contract
negotiation, and responding to change over following a plan. Scrum, XP, Lean, and Kanban are
built on these values with specific practices, values and principles that are applicable for
different purposes. Scrum is an Agile methodology for project management that relies on self-
organization and collective comment. XP is an Agile methodology for software development
that embraces changes. Lean is an Agile mindset that promotes eliminating waste and seeing
the whole. Kanban is an Agile method for process improvement that focuses on flow and
constantly improving. All of these Agile methodologies and mindsets are based on the concept
of incremental and iterative evolvement. Although teams may achieve better results by
implementing Agile practices, Agile mindsets help them to achieve the best results of applying
Agile methodologies within their projects and organizations.

References
Stellman, A., & Greene, J. (2015). Learning Agile: Understanding Scrum, XP, Lean, and Kanban.
Sebastopol, CA: O’Reilly Media.
Beck, K., Beedle, M., Bennekum, V. A., Cockburn, A., Cunningham, W., Fowler, M., . . . Thomas,
D. (2001). Manifesto for Agile Software Development.
Retried from http://www.agilemanifesto.org.
Schwaber, K., Sutherland, J. (2013). The Scrum GuideTM. Retried from
http://www.scrumguides.org.
Wells, D. (2009). The Values of Extreme Programming. Retried from
http://www.extremeprogramming.org/values.html.
Womack, P. J. and Jones, T. D. (2003). Lean Thinking: Banish Waste and Create Wealth in Your
Corporation. New York, NY: FREE PRESS. (Retried from http://www.amazon.com/)
Westfall, L. (2009). The Certified Software Quality Engineer Handbook.
Milwaukee, Wisconsin: American Society for Quality Press.
(Retried from http://www.amazon.com/)
Yahoo! Group Using the Kanban Method. Group Description.
Retried from https://groups.yahoo.com/neo/groups/kanbandev/info.

PhuNguyeAgileStudyReport201506

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (17)

Similaire à PhuNguyeAgileStudyReport201506

Similaire à PhuNguyeAgileStudyReport201506 (20)

PhuNguyeAgileStudyReport201506