From Zero To Agile

FROM ZERO TO AGILE
Agile mindset.
A book by
Massimo Albani

This is a short introduction of the
book content.
Every chapter is summarised and
the main concepts are outlined.
A retrospective example is
presented for each topic but you
can find many more examples
inside the book.

WHY?
Agile: you do not introduce such a
complex change (change is hard) in a
system / organisation with a top-
down approach.
With this book I want to show how is
possible to introduce gradually a
series of changes so that at the end
your organisation will BE agile  
(i.e., it has understood the Agile
values and principles and know how
to apply them)

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.
Manifesto for Agile Development
http://agilemanifesto.org/

OUR EXAMPLE, A PILOT
The goal:  
collect meaningful data and
identify the barriers

The project: 
a new release of an existing
product, in 8 weeks, in time for
an industry world exhibition.

The team: 
a dedicated team, with mixed
experienced and new members.

Week 1
THE FREQUENT MEETING
The ﬁrst procedure that I like to introduce in a new
team moving to agile is a daily meeting.

The most important things in the regular meeting
are :

• the regular frequency (it enforces a rhythm to
the team and makes it a habit)

• that it is time-boxed (i.e. a ﬁxed duration, to
avoid that things drag on).

• that the entire team participates.

Content: what I did yesterday, what I will do today
and if something is in my way or blocking my work.

THE GOAL
Each project shall have a proper goal, a
vision.  
Not the requirements, nor the features but
what is the ultimate goal of this project?
At the end if you don’t know where to go,
then any road will be the same…
The goal can usually be expressed in a few
sentences on a single page.
Once you have it, hang it on the wall or put 
it in the main page of your project intranet,
so that everyone can always see it and
remember what is the project final scope.

THE PRODUCT OWNER
The Product Owner is a person.  
One person, not a committee.
He/she is the person in charge of converting
the project goal into requirements. He/she
is also the person who takes the final
decision.
The Product Owner is the proxy of the
customer towards the team, can speak for
the customer, can clarify doubts and
provide feedback, including positive
confirmation when the team did a great job.
Principle #4.
Business people
and developers
must work together
daily throughout
the project.

EMBRACE CHANGE
Changes are inevitable.
By the time you fully and correctly
specify, freeze and “sign off”
requirements and design the
business already changed.
Early feedback is worth its weight in
gold.
Consequently, work quickly
proceeds through a series of
structured build-feedback-adapt
cycles.

THE RETROSPECTIVE
“Principle#12.  
At regular intervals,
the team reflects on
how to become more
effective, then tunes
and adjusts its
behaviour
accordingly.”

THE RETROSPECTIVE
The retrospective happens regularly,
ideally after every iteration.  
If you have short iterations you may
decide to have a retrospective every
second iteration.
Focus on short term and identify and
set small and actionable
improvements.  
The goal of the meeting shall be to
answer the question “how can we
improve the next iteration and the way
we work on a short term”?
Make clear this Prime Directive
before the retrospective:
“Everyone did the best job they
could, given what they knew at
the time, their skills and abilities,
the resources available, and the
situation at hand.”

THE BACKLOG
The backlog is just a prioritised
collection of things to be done, all
aiming to the project goal. 
 
Not (only) the list of requirements
but all topics of value (features,
questions, issues, ...) to be
discussed during the project
lifetime.  
The Product Owner owns it.
Week 2

THE PRODUCT BACKLOG
IS NEVER COMPLETE
The initial cut only lays out the
known and best-understood
requirements.
The Product Backlog evolves
as the product evolves.  
No big up-front effort !
Principle #2.
Welcome
changing
requirements.

RETROSPECTIVE
Some of the features are not ranked by
value by the product owner.

Why is it bad? Ranking is important
because the value is everything. What
has more value to the customer
comes ﬁrst. In this way you will show
early visible progress, early visible
value, and on-time completion.

More smells and their ﬁxes in the book !

THE ITERATIONS
The next thing to do is to divide the project
into a series of iterations where each one of
them should produce a measurable
outcome and spark feedbacks.
Why to split the project into smaller pieces?
To minimize risks of producing nothing at
all or what it was not expected.
To ensure that we are able to continuously
revisit our vision because the world out
there is uncertain.
Principle #3.
Deliver working
software
frequently.
Week 3

KEY PRACTICES
iterations are time-boxed and
lenght does not change. You want
to gain a rythm.
build a cohesive, core
architecture in early iterations
tackle high-risk and high-value
issues in early iterations
continuously engage users for
evaluation, feedback and changes
always verify quality; test early,
often and realistically

RETROSPECTIVE
The most common problem with
iterations is inconsistency, such as the
durations are not always the same or
even change during the iteration.

This is bad because rhythm helps
make things routine. When iteration
duration varies, teams have a harder
time selecting the right amount of work.

More smells and their ﬁxes in the book !

THE CROSS-
DISCIPLINARY TEAM
Why in Agile is there stress on the team being multi-disciplinary
and as much as possible self-contained?
to create customer-centric value: you want to be able to deliver a
working product increment that brings some value to your customer.

and because cross-functional teams are faster. 
The more disciplines you include, the more complex values can be
delivered faster by the team.

You may not be able and should not go all the way in one step.  
Multi-disciplinary teams are the ﬁnal goal, that can be achieved taking
one step at a time.
Week 4

THE SELF-ORGANISING
TEAM
What does it mean exactly?
That the team has the ability
and the authority to take
decisions and implement them.
Principle #11. The
best architectures,
requirements, and
designs emerge
from self-
organizing teams.
Self-organised teams still require mentoring and
coaching, some direction and control. It is not a free for
all. Direction and control are about what values to be
achieved, and not about how the work should be done.

RETROSPECTIVE
Major smells about teams are when
there are ﬁxed roles and the team
members are not helping each other.
How to fix it:
Change the corporate structure to reward team work and not
individual heroes.
Lead by example and mentor the team. Encourage cooperation,
organise team building workshops.
Make sure all core competencies exist within the team.
Principle #5. Build
projects around
motivated individuals.
Give them the
environment and support
they need, and trust
them to get the job done.

Week 5
ITERATION BACKLOG
The iteration backlog is the list of
refined items chosen from the
Product Backlog for development in
the current iteration, basically a
subset that reflects the team’s forecast
of what work can be completed during
the iteration.
The items in the iteration backlog are
more detailed than the others in the
product backlog: you split a story in
smaller tasks with enough details that
you can start immediately working on.

RETROSPECTIVE
Tipical smells of the first iterations are:

You put in the backlog partial tasks or components.

Too much work in progress. There are started features that never get finished.

Features are assigned to the current active iteration in the middle of it.

Slack time (vacation days, sick days, meetings, …) are not considered or allowed.

“Completed” features that subsequently require extensive revision or repair.

This last one happens more than expected and it's a clear symptom that the product
owners and the team members have different opinions when a feature is done.  
Next week will address this.

Week 6
DEFINITION OF DONE
The product owner and the
team must agree on a clear
deﬁnition of “done” (DoD).

The deﬁnition is up to the
team and depends on the
project and the context.

My suggestion is to focus on
the primary artifact: a
working feature or product.

DOD IS NOT UNIQUE NOR
STATIC
Not all backlog items can be treated the same.

One example of a good DoD for development  
tasks: 
“Ready to deploy to production” that means it has been
implemented (this includes unit-tested), peer-reviewed and
veriﬁed in a test / demo environment (including acceptance-
tested).

While one for an item "Write the installation guide" could
have simply a DoD like "accepted by the operations team".
Principle #7:  
Working software
is the primary
measure of
progress

RETROSPECTIVE
The most common smell is not to have a DoD or the team
ignores it.
This is bad because the Product Owner will not get at the
end of the iteration what was expecting, cannot really plan
release dates and we have waste (unverified features).
Improve the DoD over time.  
Avoid to have a dedicated team doing this work, instead
plan a special Iteration to do all the undone work.

WHY ESTIMATE?
You need it to be able to forecast
costs for the product (either
internal production or for an
external customer).
You need it to be able to plan the
releases and the roadmap.
You need it for the current
iteration, not to overload the team
and as a key to make commitments.
To prioritize the features and tasks.
Week 7

HOW ESTIMATE?
For the initial estimates (rough
unplanned stories in the backlog)
you can just put them into
different pools based on T-shirt
sizes: Small, Medium and Large.
If you wish you can add XS or XL
pools.

FINER ESTIMATES
One of the most used method is using
story point, i.e unit-less numbers that
are relative so they can compare similar
stories but for unexperienced teams is
often better to start using man-
hours: everyone knows what man-
hours are and can judge if a task will
take half a day or more days.  
You can move to relative values on a
later retrospective (and some teams are
so efficient in estimating absolute values
that they will never need relative ones).

WHO GIVES THE
NUMBERS?
Rather than place all of the burden and responsibility for an
estimate on the shoulders of an individual estimates are owned by
teams.
Planning poker: for each task, everyone in the team decides on
an estimation value and then  
all together present their value.  
The lowest and the highest get  
to explain why they think so and  
then the process is repeated until  
the members converge on a  
common value.

RETROSPECTIVE
How to fix bad estimates:
Do release planning with the whole
team and make commitments based
on estimates in order to make clear
why proper estimations are important.
Make the release progress (for
example via a burn-down chart) visible
to the team.
Dedicate part of the retrospective focus
to the difference between the release
targets and estimations and
understand where it is coming from.

VELOCITY
A team’s velocity is simply how many stories that
team can complete in a standard iteration.

In theory the story size should be taken into
account but in practice when you had several
iterations and stories behind you, the sizes of the
stories are quite evenly distributed and you can
just use the number of features or stories.
Principle #8:
Agile processes
promote
sustainable
development.
Week 8
The velocity is the simplest metric to predict how long will take to
complete an amount of work. E.g., a team able to complete in
average 10 features every iteration, for a project that has 90
features will estimate 9 iterations to complete it.

OTHER METRICS
Here are some examples.
how many tasks were included in the iteration
how many tasks have been completed (according to the definition
of done)
how long each task stayed in every state (new / ongoing /
developed / tested / done / etc.) and the averages
elapsed time per task: how many days it took to cross the board
(from new to done)
touch time: how many days the task was actually worked on (net of
waiting times)
process cycle efficiency % : elapsed / touch

MAKE IT VISUAL
In many knowledge-work domains there are queues of work-in-progress (WIP)
but because they are invisible (usually they are just a bunch of digital data) they
are not seen as such or felt as problems.
The idea is to make immediately visible those queues of waste: untested
features, incomplete information, half written documents and manuals, bugs, …
The most famous visual signal is the burn-down chart from Scrum.
On the X axis you have the time: the iteration days.
On the Y axis, the remaining effort measured in hours or the remaining
number of features completed.

A burn-down chart: it shows – as time goes by – how the
progress towards no remaining work is going and if you are on
track (compared to the ideal burn-down rate).

RETROSPECTIVE
Bad smell: The velocity varies a lot, sometimes fast sometimes slow
(yo-yo velocity):  
this means you have problems with quality.  
One iteration is good, great velocity but the next one is bad because
you need to fix all the previous iteration bugs.
It is important that a team learns  
from its past. Before planning the  
next iteration they need to look at  
the last iteration.

AGILE IS BUILT TO SCALE
In my own experience the best approach is to
gradually scale it: start with a small group
of talented and dedicated people (people
need to believe in the method) and grow
until it hurts.
It's critical that when scaling you adapt the
process based on your context and needs,
more than following a fixed set of “best”
practices. The agile framework and its
principles will help you to expose the
problems and to grow.

WHAT DOES IT MEAN
GROW UNTIL IT HURTS?
With success come also more features
and more team members, who will
strain the communication and a bigger,
more complex product that will require
additional activities before releasing
and then sooner or later the Product
Owner will not be able anymore to
grasp an overview of the entire product
(or of the backlog) nor to properly
interact with the team(s). When any
of these happens it will hurt.

A FIRST POSSIBILITY
Split the work among more teams (an agile team is small, no more
than 8-9 members, because of the communication and coordination
overhead) and everything else remains more or less the same.
The challenge here
is to find a work
split that makes
sense; typically
feature teams
(each team works
on a specific self-
sustainable
customer-centric
feature) works best

SCALE EVEN MORE
When the teams will be too many, the Product Owner will not be able anymore to
work with all the teams or properly detail every item in the backlog. At this point you
will need to introduce more changes.

Identify in the backlog the major requirement areas and deﬁne separate views, one
for each area, and each one will have a dedicated Area Product Owner and Area
teams.

Note that these areas are
organised around
customer-centric
requirements (really just a
coherent fragment of the
backlog) more than around
product's architecture.

CREDITS
@slide 5 (Start): https://www.flickr.com/photos/9458417@N03/
@slide 6 (one): https://www.flickr.com/photos/zigzaglens/
@slide 7 (meeting): https://www.flickr.com/photos/farrokhi/  
@slide 8 (crossroads): https://www.flickr.com/photos/9391282@N05/
@slide 11 (mirror): https://www.flickr.com/photos/infomastern/
@slide 13 (two): https://www.flickr.com/photos/geographyalltheway_photos/
@slide 14 (backlog) . https://www.flickr.com/photos/23024164@N06/  
@slide 15 (sagrada) https://www.flickr.com/photos/18614695@N00/
@slide 17 (3) : https://www.flickr.com/photos/piratealice/
@slide 20 (drummer) : https://www.flickr.com/photos/vinothchandar/ 
@slide 21 (4) : https://www.flickr.com/photos/barcoder/  
@slide 25 (5) : https://www.flickr.com/photos/smemon/
@slide 28 (6): https://www.flickr.com/photos/rvoegtli/  
@slide 29 (done): https://www.flickr.com/photos/anderssauro/
@slide 32 (7) : https://www.flickr.com/photos/masayun/  
@slide 38 (8) : https://www.flickr.com/photos/smsm89/
@slide 43 (yoyo) https://www.flickr.com/photos/ppdiaporama/  
@slide 46 (limit) https://www.flickr.com/photos/waynerd/

From Zero To Agile

More Related Content

What's hot (20)

Similar to From Zero To Agile (20)

Recently uploaded (20)

From Zero To Agile