Agile Overview

Raj Mudhar, September, 2011

Overview

Agile is not a process or a methodology. Agile is a set of values and principles. It is a way of thinking. The Agile way of
thinking is supported by a set of business and technical practices.

Agile is not a an “R&D Efficiency tool”.

Agile values and Principles

Values
We are uncovering better ways of developing software (products) by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value items on the left more.

The 12 Principles of Agile software development

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's
competitive advantage.

3. Deliver working software/product frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to
get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.

Agile Overview & Glossary of terms 1

7. Working software/product is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain
a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour
accordingly.

Agile Methods and practices

Lean - A set of 21 thinking tools and corresponding practices that come from Toyota and manufacturing in general. Lean
has been in use for decades. Taichi Ohno is credited with the creation of the Toyota Production System which is the
foundation of Lean.

Scrum - a lightweight process framework that is used for product development as an alternative to waterfall. Scrum
takes its name from the game of rugby. In the 1986 Harvard Business Review paper, The New New Product
Development Game, Taekuchi and Nonaka describe how high performance teams moved the ball downfield together, as
one, hence the reference to rugby. The paper describes, ironically, hardware development. What distinguishes Scrum
from more traditional process frameworks is:

• Scrum is based on Empirical Process Control. Empirical processes are based on the Deming cycle of Plan-Do-Check-
Act. The idea is to create frequent feedback loops and to learn from these feedback loops. Empirical Processes have
inherent variance, common to any new product innovation activity. Scrum assumes that we cannot remove inherent
variance, but we use it as a feedback loop to inspect and adapt.
• The use of self-organization over command and control. Teams organize and plan their own work. They take full
responsibility for its delivery and quality. The manager does not assign or control the work.
• Small integrated multidisciplinary teams instead of large specialized teams that hand off work to each other. A Scrum
team contains all the skills necessary to deliver a product end-to-end.
• Short, time-boxed iterations called Sprints in which a team builds a potentially shippable product increment.
• The ability to change priorities easily to adapt to changing market conditions rapidly. Rather than trying to find the one
best plan and execute it, Scrum teams begin implementation as early as possible, and plan incrementally and
iteratively as they work. This allows them to adapt plans to changing conditions based on actual results. It allows
teams to take advantage of opportunities as they arise.
• A continuous improvement cycle that is built into the process framework. This is one of the more powerful elements of
Scrum, when done in a disciplined fashion.
• A focus on TTM over efficient use of resources.
• A customer feedback cycle called the Sprint review, which occurs every four weeks or less.
• Contrary to popular myth, Scrum is highly disciplined, invests in continuous planning, and has a fanatical focus on
quality.

Agile Overview & Glossary of terms 2

XP - Extreme Programming - a collection of technical practices that operationalize Agile thinking at the technical level.
Some of the better known XP practices include Continuous Integration (CI), Test Driven Development (TDD), Acceptance
Test Driven Development (A-TDD), Pair Programming, and Behaviour-Driven Development (BDD).

There are many Agile methods and practices which are not covered in this document. For more information, additional
references, papers, eBooks check the links on my blog. I have selected what I think are some good references and put
them here: http://rajile.com/web/web2/.

Glossary of terms
• Agile - the name coined for the wider set of ideas that Scrum falls within; the Agile values and principles are captured
in the Agile Manifesto

• Burndown - (see Sprint Burndown, Release Burndown)

• Backlog Item - (see Product Backlog Item)

• Business Value - the return on investment associated with a User Story

• Chicken - (arch.) term for anyone not on the team, the term offended some people so is now rarely used, cf. Pig

• Daily Scrum - a 15 minute daily team meeting to share progress, report impediments and make commitments -
driven by 3 questions: What did I do yesterday, What will I do today, and What are my impediments.

• Done - also referred to as “Done” or “Done Done”, this term is used to describe a product increment that is
considered releasable; it means that all design, coding, testing and documentation have been completed and the
increment is fully integrated into the system

• Emergence - the principle that the best designs, and the best ways of working come about over time through doing
the work rather than being defined in advance, cf. Empiricism, Self Organization

• Empiricism - the principle of “inspect and adapt” which allows teams or individuals to try something out and learn
from the experience by conscious reflection and change, cf. Emergence, Self Organization

• Epic - a very large User Story that is eventually broken down into smaller stories; Epics are used as placeholders for
new ideas that have not been thought out fully.

• Estimation - the process of agreeing on a size measurement for the User Stories in a Product Backlog done by the
team, usually using Planning Poker

• Fibonacci Sequence - the sequence of numbers where the next number is derived by adding together the previous
two; the sequence has the quality of each interval getting larger as the numbers increase; the sequence is often used
for Story Points, simply because estimates are always less accurate when dealing with progressively larger Product
Backlog Items.

• Fist to Five - a voting method where the team simultaneously votes on a question with their fist (bad) or 5 five fingers
(excellent) or somewhere in between

Agile Overview & Glossary of terms 3

• How - “the How” is a term used to describe the domain of the team, as distinct from the Product Owner, cf. What can
also be described as tactic (i.e. how to win the battle)

• Impediment - anything that prevents the team from meeting their potential (e.g. chairs are uncomfortable). If
organizational, it is the Scrum Master’s responsibility to eliminate it. If it is internal to the team, then they themselves
should do away with it

• Impediment Backlog - (or list) is a visible list of impediments in a priority order according to how seriously they are
blocking the team from productivity

• Information Radiator - (See Task Board)

• Kanban Board - (see Task Board)

• Minimum Marketable Feature - the collection of product increments delivered by a team in successive Sprints that
deliver sufficient Business Value to be sold to a customer.

• Pig - (arch.) term for a team member, the term offended some people so is now rarely used, cf. Chicken

• Planning - see Sprint Planning

• Planning Poker - a game used to apply estimates to stories; it uses the Delphi method of arriving at consensus

• Process - the way someone works. Everyone has a process. It can be pre-defined, empirical, or chaotic.

• Product Backlog - a prioritized list of stories that are waiting to be worked on by a team

• Product Backlog Item (PBI) - any item that is on the Product Backlog, which will include user stories, epics and
possibly technical stories to deal with technical debt, training, architectural spikes, etc.

• Product Owner - person who holds the vision for the product and is responsible for maintaining, prioritizing and
updating the Product Backlog

• Release Burndown Chart - a visible chart to show the progress of a release

• Retrospective - a Scrum ceremony where the team and ScrumMaster meet to reflect on the process and make
commitments to improve

• Roman Vote see - Thumb Vote

• Scrum Master - a servant leader to the team, responsible for removing impediments and making sure the process
runs smoothly so the team can be as productive as possible

• Scrum Meetings - the collection of meeting ceremonies defined in Scrum which include: Sprint Planning, Sprint
Review, Sprint Retrospective, Daily Scrum

• Scrum Roles - there are only three roles: Product Owner, Scrum Master, Team Member

• Self Organization - the principle that those closest to the work best know how to do the work, so set clear goals and
boundaries and let them make all tactical and implementation decisions, cf. Emergence, Empiricism

Agile Overview & Glossary of terms 4

• Spike - a short, time-boxed piece of research/exploratory work, that is intended to provide just enough information for
the team to make a decision

• Sprint - a time boxed iteration where the team is “heads down” uninterrupted to deliver on the Sprint Goal

• Sprint Burndown - a visible chart that indicates on a daily basis the amount of work remaining in the Sprint

• Sprint Goal - the key focus of the work for a single Sprint

• Sprint Planning - a meeting between the Team and the Product Owner to plan the Sprint and arrive at an agreement
on the commitment

• Sprint Task - a single small item of work that helps one particular story reach completion

• Stakeholder - anyone external to the team with an interest in the product being developed

• Story - see User Story

• Story Point - a unit of measurement applied to the size of a story, cf. Fibonacci Sequence

• Task - see Sprint Task

• Task Board - a wall chart with cards and sticky notes that represents all the work of a team in a given Sprint; task
notes are moved across the board to show progress - also known as a Kanban Board, Information Radiator

• Team - the development team responsible for committing to work, and delivering a potentially shippable product
increment

• Team Member - any member of the team, including developer, tester, designer, architect, etc.

• Thumb Vote - a quick pulse-check to get a sense of where the team members are in terms of commitment, or
agreement on a decision, etc. thumb up generally means agree, yes, or good, and thumb down disagree, no or bad;
the analog version of this allows the thumb to be anywhere on the half circle to indicate differing degrees of agreeability

• Timeboxing - setting a duration for every activity and having it last exactly that (i.e. neither meetings nor sprints are
ever lengthened. Ever.

• User Story - a method for capturing a requirement which includes FOR WHOM, WHAT, and WHY. “As a “USER” I
want “WHAT” so that “BUSINESS VALUE” (WHY). We also capture the acceptance criteria so that we know how it will
be tested.

• Value - (see Business Value)

• Velocity - the rate at which a team completes work, usually measured in Story Points.

• Vision Statement - a high-level description of the product, what it does, for whom it is, and what differentiates it from
others. One should be able to describe a Product Vision in the time it takes to ride an elevator.

• What - “the What” is a term used to describe the domain of the Product Owner, as distinct from the team. What
describes what is to be built without describing the How

Agile Overview & Glossary of terms 5