Agile 101 FAQ

What is Agile?
Agile is an umbrella term that refers to a collection of methodologies that support a particular
philosophy and set of values about engineering practices. Types of Agile include Scrum, Kanban, Extreme
Programming, Lean, and Adaptive Engineering. These have many overlapping practices aimed at
responding to changing business demands by reducing waste, releasing more quickly, and working
collaboratively.

How does Agile compare to the waterfall method?

In the waterfall method, individuals are on teams with a common feature, but they spend most of their
time individually producing their part of a solution or product, whether it is a document, code, or
systems and architecture. It is a linear development process that moves through phases from design to
development, to stabilization and release in distinct milestones, with clear roles.

Agile, on the other hand, requires a mind shift from individual performance to team progress. It
emphasizes the ability to adapt to changes from the customer or market and provide organizations the
framework to adapt to the market in a predictable way with a minimal amount of waste, such as from
over planning. In Agile, teams incorporate frequent customer feedback, whether from an internal or
external customer, and work in short iterations, with the goal always to get something viable in front of a
customer for feedback. Everyone works as one team to get work done. Most of the Agile practices are
as much about developing the teams shared tacit knowledge as they are about getting work done.
Balancing Agility and Discipline

What are the core Agile principles?

The official values are stated in the Agile Manifesto:

We are uncovering better ways of developing software 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 the items on the left
more.

These values describe the common ground between all Agile approaches. Each Agile methodology
expands upon this set in some way.
There are also a set of common principles.

Work tiny: Whatever you do, do it in a smaller chunk today than you did yesterday.
Prove everything: Know what it means to finish and always demonstrate that you have met the
requirements before moving on.
Work for a customer: Know your customer. Anything that doesnt serve your customer is waste.
Work for yourself: Anything that doesnt serve you is waste.
Work sustainably: Optimize for consistent, stable output, not for short-term gains.
Work as a team: The team owns all objectives and work products. The team succeeds or fails as
a whole.
Focus the whole team: Work on one thing at a time.
Target simplicity: Design code and processes to eliminate dependencies.
Achieve technical excellence: Rather than settling for an adequate solution to a complex
problem, simplify the scope to todays needs and solve it excellently.
Learn constantly: Each individual and team learns each day. The team uses these lessons to
improve its processes.
Get done: Dont let anything drag on. Pick an objective and meet it before moving on. Working
software is the primary measure of progress.

How do roles change when using Agile?

At a high level, here are the significant changes for each role:
PM: PMs inform the team about the needs of external stakeholders (customers, partners, and
management). The backlog becomes part of your spec process. Where PMs tend to be the
interface for the required set of features in a spec, this now moves into backlog iteration.
Documentation should be developed iteratively and incrementally just like the code test a
little, code a little, and document a little. Specs can be another format for prototyping and
defining stories that align with a given sprint and the teams priorities.

Dev: Code is proven to do what the team expects. Devs inform the team about the needs of the
system, including reducing duplication, eliminating dependencies, and others. Engineering
practices, such as unit tests, help prove the code and often replace the need for detailed
functional specifications. The code and tests now document the systems behavior.
Tester: Tests are about learning, not just proving. Testers help Devs learn where their current
standard of proof is insufficient.
Other roles: Other individuals work directly with the core team and inform them about needs
they know about, such as UX, localization, operationalization, and monitoring.
Everyone together: Manages the project, understands the customer, improves the process,
chooses product direction, and learns.

How do Agile methodologies get work done?

Agile development is implemented through a series of feedback loops. The process iterates multiple
nested loops simultaneously. It uses the feedback from each iteration to improve the next iteration at
that level.
eXtreme Programming involves all of these loops. Scrum involves iteration plan and standup. Both also
include a process improvement loop (not shown).

How do Scrum, Kanban, eXtreme Programming, and Lean relate or

differ?
All of these embrace Agile values and tenets as an overarching philosophy. Scrum, Lean, and eXtreme
Programming are methodologies. Scrum is a planning methodology that works for any kind of project;
Lean optimizes and improves any process or methodology. eXtreme Programming (XP) is specialized for
software and includes planning, design, implementation, maintenance, and operationalizing. Kanban is a
planning technique that can be used in any methodology whether Agile or not.

What is a scenario?
A scenario is a story told from the customers point of view that describes their problem and what they
want to achieve. It does not solve the problem or include implementation details, but it does describe
the happy ending. Here is an example of a scenario:

Gene is an IT generalist in a company whose policies require extensive logging, so he must

make sure there is always enough free disk space on the 200 web servers that he manages.
 Currently, he performs this task manually several times per day. He wants to automate this, but
he is not a programmer and he always struggles to get scripts working.

<magic happens>

Gene discovers a new way to easily automate common IT tasks, and finds it straightforward
despite his limited programming background. Within 5 minutes, he is able to automate his first
task on a local machine. When he tries to run it on multiple machines, the task fails, but with
troubleshooting, soon he can run the task successfully across his entire cloud. Gene is pleasantly
surprised at how easy it was to achieve such a time savings in his day-to-day work.

What is a user story?

A user story is a statement that supports a scenario. It is written from the customers perspective and
describes the customers intent, not what the software does. A user story fills in the <magic happens>
section of the scenario. It describes what the user is doing during that time in order to accomplish the
magic. As such, it is showing a solution to the problem. It still doesnt get fully into solution space,
however. A story does not tell how the software helps the user take each action; it just shows an action
that the user takes.

A user story follows this format: As a <user>, I want (or need) <some stuff> so that I can <value: why I
want or need it>. Here is an example:

As an online video user, I want to search for games and get results that match my interest level.

Youll notice that there are no implementation details.

What is the value of user stories?

Here is how one engineer expressed their value:

User stories help focus everyones energy on a tangible, customer-facing goal. They help avoid putting
energy into extra code capabilities that are not actually adding value to a specific scenario. They also
help ensure that when everyone thinks something is done the discussion stays around whether the
customer-facing goal has been accomplished, rather than a bunch of people doing tasks that dont add
up to a coherent goal. -- Chris Flaat, Principal Developer Lead, IEB

What is a sprint?
A sprint is defined length of time, typically 1- 4 weeks long, in which to complete chunks of work. A
sprint generally includes user stories, estimates of how long they will take to complete, and acceptance
criteria (the definition of done). They focus on the completion of something tangible that a customer
can give input on, which is referred to as a minimally viable product (MVP).
 Whats involved in a sprint?
At the beginning of each sprint, the team writes user stories that support scenarios. It then prioritizes
and estimates the work, with the team agreeing on what done looks like. As the sprint continues, the
team holds daily standup meetings, aimed at less than 15 minutes, using a storyboard or wall to track
progress. During each standup, work tasks are updated and unblocked if necessary. At the end of the
sprint, the team demos the work to get feedback and celebrate. It then holds a retrospective to discuss
how the sprint went from a process standpoint and to agree upon a change for the next sprint.

The following graphic shows whats involved in a sprint:

Standup

User stories Planning meeting Doing the work Retrospective

estimating Velocity, Burndown Storyboard, Standups & demo
What are some Agile best practices?
Work in tiny steps
o Make each iteration add value to your solution
o Agree to what done is
o Prove and complete each iteration before moving on
Tune engineering systems to optimize for the flow of work getting done. If it takes hours or days to
verify the quality, its hard to work tiny without wasting time waiting.
Measure the teams velocity to understand organizational capacity and to drive for consistency and
increased efficiency over time (continuous improvement). Dont increase the sprint to fit the story;
rather, decrease the story to fit the sprint.
Use relative estimation for planning. Dont try to predict vacations, sick leave, or scope creep.
Focus on eliminating dependencies.

What are product and sprint backlogs?

A product backlog is a list of the teams prioritized work. It consists of user stories that the team is
considering adding to the product in the future.

A sprint backlog (sometimes called a sprint commitment) is a list of stories that the team has committed
to complete this sprint. A new backlog is created at the beginning of each sprint.

What is velocity?
Velocity is the calculation of what the team actually delivered from each weeks sprint plan. That figure is
then used to accurately plan work for the next sprint. For example, if a team planned to deliver 18 units
of work in a sprint, but only delivered 11, the teams velocity is 11.

What hasnt been covered?

This FAQ covers the aspects of Agile related to planning. It does not cover:

The core changes in how people write code that enables everything else.
How to transition into agile approaches.
What cultural changes will occur as a result of practicing agile methods.
How to choose an Agile methodology.
How to lead an agile team.
Tools and infrastructure that support agile teams.

Where can I learn more?

Visit the Engineering Excellence RAPID website, where youll find training, videos, case studies, blogs,
and other resources to help you get up and running with using Agile. If you have questions, please email
the EE RAPID team.