Professional Documents
Culture Documents
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.
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
We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:
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.
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.
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:
<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.
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.
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.
Standup
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.
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.