Instead of fighting about “who’s agile” or “who’s more agile than whom”, it would be useful to create a set of patterns, that once recognized would help us define if we are or have been able to successfully implement an Agile life-cycle for our project and portfolio. In this session we will explore how it “feels” to work in an Agile project. It is not enough to do Scrum or Kanban, you need to know if you are doing it right.

1. REAL WORLD AGILE PATTERNS
Vasco Duarte

2. Vasco Duarte
@duarte_vasco
http://bit.ly/vasco_blog
http://bit.ly/vasco_slideshare
2

3. 3

4. No!
Mine is
more
Agile! My
project
is Agile!
Can you
please talk
WITHOUT
using Comic
Sans?
Live from the Agile Wars
Many of us have seen this happen before. Someone from the outside (company or
team) comes in and sentences “you are not Agile” or “you are not doing Agile”. This
disdain and comtempt!
Or you are having a discussion about your projects with your mates at the bar and Tom
(always the smart ass) tells you off for not “doing it right”!
Or better yet, your team is diagnosed with a terminal illness called Scrum-Butt. Oh My
God! You say, what should I do? How long do I have to live?
http://www.flickr.com/photos/jacklazar/4561367729/sizes/l/
4

5. Don’t
Panic!
Well, don’t panic! Labels are there to make religious wars interesting, but they don’t
really help you with your work!
It is much more useful to talk about what happens in reality when you do or don’t do
Agile.
It is more interesting to answer questions like:
-How does it feel to work in your Project?
-What is the stress level now or at the start/middle/end of your project?
-What is the primary tool to follow progress in your project?
-How do you organize your testing?
-How do the different teams interact?
So I decided to make a contribution. How about collecting this information? How about
detecting the underlaying patters that we’ve seen in Agile/Waterfall/Traditional
projects?
5

6. These patterns or symptoms are useful for us when analyzing a project (e.g. for a
retrospective) and assessing the progress of a team or a company from waterfall to
Agile software development. These are necessarily only a small collection of patterns.
Many more are needed to create a complete language that would help us define better
what an Agile project should feel and look like or don’t.
This can be the start of our collective knowledge base about patterns we see in these
different types of projects.
The start of a real dialogue, instead of a religious war about who can use the “Agile”
label.
6

7. The typical life-cycle phases of a
project
We’ll look at how different models feel at different lifecycle phases of your project.
Before getting deeper into the patters let me define at the outset what I mean by life-
cycle. In my context life-cycle refers to a stage/phase in the life of a project. Example: a
project that is "about to end" is in a different life-cycle phase than a project that is
"about to start" or "ramping up". I define the following useful, although not exhaustive,
life-cycle phases: Start, Middle, End.
In this talk I’ll try to define what different types of projects (Waterfall, Linear Iterative
and Agile/Incremental Iterative look and feel like during these different life-cycle
phases.
7

8. The waterfall life-cycle model
Here’s the waterfall life-cycle model, where each phase follows the previous phase in a
Linear and pre-defined way.
Yes, I know no-one really uses waterfall anymore. But there’s a lot of people TRYING TO!
8

9. The Linear-Iterative life-cycle model
Design phase
Development phase
Testing phase
I want to introduce also the Linear-Iterative Life-Cycle model. This Life-Cycle model is
iterative in it’s definition, but it is also Linear, in that there are specific phases in a pre-
defined sequence.
This linearity of Phases, like in RUP, is the distinguishing feature of this Model.
9

10. The Linear-Iterative life-cycle model
Design phase
Development phase
Testing phase
I want to introduce also the Linear-Iterative Life-Cycle model. This Life-Cycle model is
iterative in it’s definition, but it is also Linear, in that there are specific phases in a pre-
defined sequence.
This linearity of Phases, like in RUP, is the distinguishing feature of this Model.
10

11. The Agile (aka Incremental and
Iterative) Life-cyle model
Do all activities
simultaneously in short
iterations until ready…
Release
the
product
Finally we have the Agile or, as I also call it: “Incremental-Iterative” model. Here the
distinguishing feature is the fact that it is an incremental approach to software
devleopment, i.e. what you develop in the next iteration is Built on top of a self
contained, working increment that you developed in the previous iteration.
11

12. P lan
The
Waterfall
Waterfall
But how does it feel to be in these different types of projects? Let’s start with the
Waterfall.
Life-cycle phase: Start
In this life-cycle phase a waterfall project is typically in a situation where only the
project management team is assigned to the project and the goal is to create a plan,
THE PLAN.
The plan is typically composed of a set of requirements, an architecture target (maybe
an architecture plan or just a high-level picture to be developed further), a budget and
(most importantly) a project plan.
You know you are in a waterfall project when in the life-cycle phase Start you are mostly
spending time in front of a presentation or word editing software and have some
meetings (maybe weekly) where scope, budget and project plan are discussed. This
phase typically ends with a "gate" where the project plan and Requirements +
Architecture are approved.
A dead give away of a waterfall project is that, in this phase no one asks or worries
about writing a single line of code. Some sophisticated waterfall projects may include a
"prototype" in the life-cycle phase Start, but it will usually be a throwaway and
developed by a sub-contractor who will not actually work in the project (after all the
other teams are busy with the other projects).
12

13. I’m confused, I
don’t have
requirements ready
by I am allowed to
start coding?
Linear Iterative
Iterative, aka Linear Iterative
But what about an iterative Project? How does that start?
Life-cycle phase: Start
In an iterative project the Start phase will typically be called Inception and will, like the
waterfall projects focus mostly on defining requirements and creating/approving the
project plan.
You know you are in an iterative life-cycle project when people start actually coding, but
only a few features. Programming is still being "ramped up", but there's no
milestone/gate that formalizes "start-programming" order.
In some sophisticated Iterative projects people will mention Use Cases, customers,
experience, business cases and may even have a prioritized list of Use Cases to be
implemented. Typically you will find that the Requirements document is quite shallow,
delegating the clarification of most requirements to the actual "design" phase of the
project.
13

14. Do what
it
takes to
trace a b
ullet
through
the
system
Agile
Agile, aka Incremental Iterative
How about Agile?
Life-cycle phase: Start
In an agile project this phase is typically extremely short. A product manager will
present a proposal for a new product or a new version of an existing product. This
proposal will be discussed and approved. One or more teams are assigned to the project
for a short period of time (called Sprint or Iteration -- confusing, I know) and produce a
running product, called a Product Increment.
You know you are in an Agile project when the team talks about "releasing" the
software starting from day one. Each development team will include testers and each
Requirement (aka story or feature) will be discussed in order to create acceptance
criteria (aka conditions of satisfaction, aka test cases). These will typically be agreed
before the team sets out to design the implementation but can also be updated during
the Sprint/Iteration.
14

15. Waterfall
Let’s now move to the “Middle” phase of the project life-cycle. Where most of the work
happens.
Life-cycle phase: Middle
In this phase the project is in "full speed", which usually means that teams are working
with very little coordination (after all they have a "plan" to follow). Typically
components are assigned to teams and they work on those in isolation.
A dead give away that you are in a waterfall project is that your team does not integrate
code with the other teams at all. Some sophisticated waterfall projects may have "sync-
points" or "integration camps" where the component teams come together after a long
period of development to integrate their code. These are grim affairs with much
overtime and gritting of teeth.
In short. This is when the real work starts for Waterfall projects and that’s when the fun
ends. Very soon the schedule pressure increases a lot! And of course no one remembers
anymore the weeks and months spent on Project Plan and Requirements Collection.
At this point we also have serious risks for the health of the proejct members. Pressure
leads to burn-outs. We change their lives without their permission.
15

16. Linear Iterative
How about our friend RUP? (an instance of Linear Iterative)
Life-cycle phase: Middle
Now the teams are working very clearly on the code. Some Iterative projects may even
have several sync points (see above) within this life-cycle phase. They will be easier than
in a waterfall project, but "integration camps" are still common (although less frequent)
and teams actively discuss the "code-line" policy (i.e. version control is an active part of
project management.
A dead give away of an iterative life-cycle is that there will be several iterations of about
2-3 months in length at which point many teams try to integrate their code. In some
sophisticated Iterative projects the teams will actually try to hold demonstrations of the
existing code and in some (far fetched) cases there will be a project-wide retrospective
at this point.
BTW: many agile adoptions go through this phase. It is ok to go through this Phase.
Embrace the good practices and slowly move towards Agile.
16

17. Agile
So, how does agile feel at this point in the project life-cycle?
Life-cycle phase: Middle
In this life-cycle phase you will notice that the teams start to gel (if they are new) and
the project gains momentum. The teams demonstrate regularly what they have
accomplished and some teams will have stopped holding retrospectives, because they
"have nothing to improve". The pressure is always high in an Agile project, but never too
high, and in this phase of the project the team is already used to the pressure level, they
know how to tackle their stakeholders.
You know you are in an agile project when the Product Manager is not the Product
Owner and is never or almost never present in the Sprint/Iteration planning meetings.
That work is delegated to someone in the team that knows the technical product and
works with guidance from the product management to help the team manage and
prioritize their backlog (aka Technical Product Owner).
In practice this means that teams start to take responsibility over the product design.
This is craftsmanship at its best. It is not the code, it is the product that is in the team’s
minds.
17

18. Development
Desperately testing and fixing phase
phase
Waterfall
Life-cycle phase: End
Now we come to where the differences are the largest, and where Waterfall fails
miserably. This is where we lose all knowledge/insight about the real progress of the
Project. The End-phase.
In this phase the waterfall project is "code complete" and aiming to "code freeze".
There is usually a milestone/gate that was passed exactly at the start of this life-cycle
phase called "code complete" or "feature complete". It is at that point that the teams of
testers (typically many and in some far away country) are assigned to "test" the product.
Obviously what they will be doing is a rather superficial sweeping of the floors to check
that everything works. It is only after that that the project can pass the "code freeze"
milestone/gate and the real testing can start.
You know you are in a waterfall project when the project runs out of time before it has
quality enough to be released. The number of bugs being found is still very high, but
probably at about the same level of the bugs being fixed. This is when "management"
comes in and pushes all the teams to fix as many bugs as they can (pulling all-nighters or
all-week-enders if needed). Much motivational language is used but the count of bugs
being fixed stays about the same. The project will eventually ship something, but the
actual quality level can only be vaguely understood. Business takes precedence in the
decision making.
In this graph we see a project “out of control”!
18

19. The “landing” curve
But we are here…
We should be here…
Pre-determined length…
Linear Iterative
How about RUP/Linear Iterative projects? I’m sorry to report that things are not much
better here…
You'd be tempted to think that Iterative life-cycle projects would have an easier "End"
phase, but you would be wrong. Just like in waterfall, the teams develop a lot of their
code in their own version control systems and integrate seldom (although much more
frequently than in a waterfall project). In large iterative projects there will be "vertical"
sub-projects (typically less than 100 people) that will actually integrate their code
frequently but the multiple concurrent sub-projects will only really integrate their code
at the end.
In this type of projects you will still find a very hectic "test and fix" phase at the end, but
it will typically be focused around "complex use cases" as many of the simple use cases
have already been tested during the "Middle" life-cycle phase.
You know you are in an iterative project because just like in waterfall Quality is an after-
thought and you will find many, many bugs in the end of the project. The defect/error
metrics will be the main focus of the project management team in this phase, up to the
point that sophisticated statistical models will be created to try to predict when the
project will end.
Don't be fooled, in a project where error/defect metrics are used as the main project
management tool no one is in control. The project end date is essentially unpredictable
and typically management will decide (arbitrarily) when the product should be released.
In some sophisticated Iterative projects I've seen that a length is pre-set for this life-
cycle phase based on history and, ironically, that seems to hold pretty well (although
not for the reasons you may think! -- stuff for another post)
19

20. Cod
e
Co d e Com e
pl e t
F reez e
Agile
Life-cycle phase: End
How about Agile? Can that really be much better? Really?
This is the life-cycle in which the Agile project will differ the most from the other two
life-cycle models. In the end of the project the team will still be developing new features
at full speed. No one will talk about "code freeze" or "feature freeze" in the project, but
the testers and project management team will closely follow the Defect list.
You know that you are in an Agile project when the defect/error list is short and the
selection/prioritization of defects/errors is easy. Some teams will just start their
iterations/sprints by picking the most important defects out of the defect backlog,
others will reserve some time/bandwidth in iteration/sprint planning specifically to
improve the quality of their product.
The most noticeable difference however, will be that people will feel the pressure to
add more features at the end, rather than the pressure to avoid changing any code.
Agile projects typically deliver a large amount of "test" code (i.e. code that is there to
test the production code) which makes them confident that they can change the code
up to the last minute of the project.
The focus is on the Value we deliver. New featurew, improvements, feedback from
customers.
VALUE drives decision making. Not fear! Fear is the most common feeling in the other
two approaches, but not in the Agile approach.
20

21. Self-awareness and Reflection
I hope that this collection of patterns from different types of projects will help you talk
about the level of agility in your project with your team.
We should really stop bickering about "how agile we are" and start defining how an
agile project "feels" like. What patterns do we see, what benefits and constraints we
have, etc.
At the end of the day, what matters is that you understand your context. That's the first
step to changing it!
Use what you have learned here to reflect on your current projects. Use these patterns
as a guidance in your experiments.
But, please, change the way you work. Improve at all times and use this roadmap of
patterns as your guide. Good luck and may the force be with you.
21

22. The force is
strong with this
audience
So, now you’ve heard about some of the patterns that we have witnessed in real life.
But that’s not enough.
The next step is for you to review your own experience. Which of these apply to you?
And how much?
I’ve put together an Agility Scoring Sheet. You can use it to review how your fare with
some of these patterns.
Over the next few minutes, please hook-up with someone and ask them which of these
patterns apply in their last project. Do cross-scoring, ask a question, and agree on a
score based on the answer.
22

23. Currently an Agile Coach in Nokia, Vasco Duarte is
an experienced product and project manager,
having worked in the software industry since
1997. Vasco has also been an Agile practitioner
since 2004, he is one of the leaders and a catalyst
in the adoption of Agile methods and an Agile
culture at Nokia and previously at F-Secure.
Vasco's contributions to the improvement of the
software development profession can be read in
his blog:
http://softwaredevelopmenttoday.blogspot.com.
You can follow Vasco on twitter: @duarte_vasco
I’d like to invite you to continue this conversation on Twitter and on your own blogs.
We, as a community, need to develop our knowledge and blogs and twitter are great
tools to create connections and build a conversation that can develop our industry
23