This document discusses applying Agile principles to projects through examples. It provides 7 examples of Agile principles in action, including satisfying customers through early delivery, accepting changing requirements, delivering working software frequently, having business and developers work together daily, building around motivated individuals, using face-to-face communication, and using working software as the primary measure of progress. Each example compares an Agile approach to challenges with a traditional waterfall approach and discusses benefits of Agile in that situation.

1. © 2016 Robertson Consulting Ltd
APPLYING AGILE
PRINCIPLES
Being good at Agile means a combination of training,
discipline and skill!
Some examples where the Agile
Manifesto Principles apply
perfectly in projects
Examples of Agile Principles in action:
1. Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software / product.
One of the serious issues around pure
waterfall is the time it normally takes to
deliver any working software. Best
practice tells us that managing customer
expectations is key to success. Here we
have the opportunity to involve the
customer earlier as well as to address
concerns early.
Example: We were delivering a
mathematically based (algorithm based)
part of the overall solution that
calculated the expected tax to be paid
from a small private company, but had
got the formula wrong. The customer,
also a tax expert, was able to identify it
early at the first ‘show and tell’ during
our first sprint review. The code worked
fine, but the formula on which it relied
was incorrect. A small correction this
early in the project not only saved
valuable time and cost later but also
reassured the customer that we had got
it right. Great save!
Continued over…

2. © 2016 Robertson Consulting Ltd
2. Welcome (accept) changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
Because the Product Backlog is constantly under
scrutiny, and the customer involved throughout, the
customer is fully aware of what they are getting and
roughly when (from the release plan), so changes can
take place due to market demands throughout the
project life due to the fact that the Agile approach
responds to sudden change much more easier than the
waterfall approach.
Example: In waterfall projects I have often had that difficult discussion with a
customer around a change in requirements. The later that change in the project
lifecycle, the more expensive such a change can be. You can see their level of
frustration rise and their feeling of confidence with what they had actually
signed up for plummet, as you tell them politely that it will require a change
request, and usually this means more money! Agile treats this differently;
additions of scope, even late on, can take place as long as the customer
recognises something else on the Product Backlog needs to go. If it is a matter of
just changing the detail of a user story already there and it has still to be done,
the change can be minimal.
3. Deliver working software/ product (business value) frequently, from a couple of weeks
to a couple of months, with a preference to the shorter timescale.
Waterfall requires a lot of up front work around
requirements and design. This means that working
software is only delivered late on in the project
lifecycle (usually called the “Build Phase”), and
usually the customer gets to see the product of this
towards the end of the phase after it has gone
through “testing”. If the approach taken allows the
End User (assuming it has a presentation layer)
access before the UAT there is the possibility that
much aggravation and dissatisfaction can be avoided.
However, the Agile approach brings the user in to the
team and allows them to be part of the decision
making process early, close to the start of the project.
Example: We were running an Agile project to
produce a new commercial web front end for a well-
known UK charity and their staff were divided on
how useful the new website would be and very
worried about its effect on their daily routines and
customers. We invited a representative of each department in to see the
developing web front end and back end processes each sprint, which had a
dramatic effect on their views. The staff were taken aback (Continued over…)

3. © 2016 Robertson Consulting Ltd
to see how simply the web front end delivered information which helped them
to do their jobs, and at the same time they were able to make small corrections
on the process and also the ‘look and feel’, which delighted them. Getting
involved and having a say, which can be seen to be making a visible effect, has a
very strong and positive effect on staff attitude. Result: motivated and
supportive customer and staff.
4. Business people and developers (the team) must work together daily throughout the
project.
In Waterfall projects there is normally a “hand-over” between business people
to the developers – teams - early on in the project. In Agile projects they work
side by side during each sprint and can even become cross-skilled – so much so
that they can often start to show all the signs of being a “high performing team”.
The Product
Owner “speaks
on behalf of the
business” and
clarifies
requirements
and helps the
team with
prioritizing the
Product
Backlog so
highest value is delivered early. This also means that a Release plan can be
determined which helps both the business and the team to focus on their Sprint
objectives and deliver to timeframes. This also means that changes can be
introduced on a prioritised basis and the scope remains achievable due to the
principle of high value User Story brought in means a same size low value User
Story out of the overall scope.
Example: In our charity example we came to a point where we were doing
some sprint planning together and the team (specifically developers) wanted to
“get some quick wins” by prioritizing the easier and less complex user stories.
The Product Owner (who essentially represents the business) disagreed as he
was concerned that by going for the “quick win” this time, the product
increment delivered at the end of that sprint would not have as much “business
value” as working on one of the more complex stories earlier, and so after some
focused discussion we agreed that business value won out in the end. The
customer went away satisfied and in the end the benefits to their business were
such that they were delighted with the project outcome. Result: happy
customer!
5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.

4. © 2016 Robertson Consulting Ltd
Every project relies on focused and experienced
team members for sure. What Agile stresses is that
the project team culture is different. There is no
“boss”, no PM who makes all the
decisions, the team make the
decisions together. In Agile,
team members are
“empowered” to make decisions
and so their motivation and
sense of personal value is
remarkably improved through
their contributions. Each team
member is encouraged to be
accountable together for the
success of the overall project
deliverables and responsible
individually to deliver their part
supported by the team. One of
the interesting things about
people, as you will testify, is that
they love to feel needed and
valued! This why agile projects
breed happier teams – they feel heard and involved, a great motivator.
Example: It took some mental gymnastics and some hard realities faced to get
‘my head around’ the change in leadership style that Agile demands. I enjoyed
being in control and getting things to work to a plan. I am a project manager
after all! However, my team, might, under close interrogation, have admitted
that they felt many decisions were made without their knowledge and without
their input. I discovered to my delight that as I involved and empowered the
team members (particularly the team leads) to get involved and help with the
project decisions, I found the quality of those decisions improved and often we
avoided embarrassing “technological blockers”. It also meant I could step back
and focus on the customer, trusting my team to do what they do best.
6. The most efficient and effective method of conveying information to and within a team is
face-to-face conversation.
Co-location is by far the best way to run a
team without a doubt. Face to face
communication provides for clarity and
meaning in a way that text alone does not.
However, in today’s world we need to have a
global response to the issue of team
communications. Fortunately for us there are
a number of great ways to connect face-to-
face even though separated by (Continued
over…)

5. © 2016 Robertson Consulting Ltd
distance and even time-zone. Tools such as Skype, Lync, WebEx, GoToMeeting
and such, allow for video as well as voice communications.
Example: I was involved in a review meeting with team members in India. I was
explaining the approach we were taking to the development and testing for
which they were directly responsible. As I spoke I could see from the response
on the video call that there was little if any response from (Continued over…)
the team in India. They were sitting there seemingly OK but providing no actual
visual cue. I did notice some looks exchanged between two members of the
India team – they were saying “OK, sure” verbally but their body language was
saying something else. I stopped and asked the two what was going on and to
explain their concerns. They politely said that they felt that our approach was
different to their tried and tested one and they felt that they had no voice to
discuss this. As a result, I was able to ask them to walk through their approach
with our Dev and Test experts, separately, who ultimately agreed that they were
happy, with some small adjustments, and that the team in India could proceed
with their approach and still deliver accountability to the UK team. Result: we
saved time re-inventing their wheel, and yet got the accountability and control
we needed from the UK perspective.
7. Working software / product (value delivery) is the primary measure of progress.
For Waterfall the project progress is tied to the project
plan and how deliverables are being achieved against the
plan. This covers scope, time and budget effectively. There
are good ways to control this using Earned Value methods,
which, funnily enough, focus on value delivered. Agile has
this written in to its DNA, it is all about delivering value. The
advantage with Agile is that the value is visible because the
customer and Product Owner are seeing progress and value
on a regular basis throughout the project. The use of Burn-
down Charts and Taskboards (based on Kanban thinking)
help with information flow to the team and stakeholders on
progress, The Daily Stand-up meeting helps the team keep
their task dependencies in line with each other.
Example: In Waterfall I have spent hours and hours
developing ways in which to show project progress in a way that is open and
honest yet does not cause the report recipients to get the wrong idea about the
value we are delivering. With Waterfall I could provide real value only once the
end solution or integrated system was starting to come together – interim value
was mainly down to documents delivered on time! With Agile during the Sprint
Review sessions, the value is visibly demonstrated and in-between these
sessions the challenges and decisions the team makes are shared with the
customer so they know what they are getting as they progress. Result: Value is
visible and tangible throughout and the customer feels they are getting a
transparent flow of information they can trust from the team.

6. © 2016 Robertson Consulting Ltd
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
Running any team over a several months at a high performing rate has
casualties. Performance drops, people get sick, life happens! When a team is
working against a plan published many weeks earlier there may be no room for
changes in pace and the plan does not take account of what is possible in the
time frame given changes in the team and availability except at a macro level.
Sure, project plan estimates should take into account all these things – skill
levels, availability, holidays and so on – but life still happens and the team
remains under immense pressure to produce to the plan. This level of stress has
consequences. I have seen two undesirable outcomes, the plan is forgotten and
becomes something irrelevant, or, the team starts to fight back and insists on
changes to the plan reflecting reality which alarms the customer who sees the
plan “slipping”. Agile makes the team talk about the “elephant in the room” and
make adjustments as they go. The
Agile estimation process we go
through allocating story points based
on complexity and size, splitting
where necessary, and prioritizing
before breaking the work down to
tasks, means that the team has to
start to determine their sustainable
“velocity” in terms of Story Points.
Generally I will start with a three
point approach (worst case, best
case, most likely) and try to agree
with the team what a reasonable
sustainable average might be. This is essential to work out the Release plan.
They adjust this from Sprint to Sprint taking into account how they have fared
in reality. After a relatively short time the team is able to say with confidence
what their “story point velocity” per sprint is, using it as a measure of
performance, and stick to it.
Example: Have you been in the situation where you have been asked to provide
estimates to senior staff before you have spoken to the people who are to do the
work? I have been working on a Waterfall project recently where this was part
of their internal process. A senior manager had to sign off the estimates in the
project “business case” based on their experience. As a professional PM I found
this bizarre from a common sense point of view but all too familiar! The result
was every person joining the project had a typical response which usually was
preceded by a sharp intake of breath when I mentioned what effort had been
“signed off”. In the Agile environment we allow the team to be intimately
involved and empowered to do their own estimation from the start and the
project progress revolves around the value delivered - based on realistic
estimates they own rather than the constant updating of the plan the
requirements “churn” that can be typical in waterfall projects.

7. © 2016 Robertson Consulting Ltd
9. Continuous attention to technical excellence and good design enhances agility.
With continuous improvement intrinsic to the
model and the team empowered to make “enhancing”
decisions, this naturally encourages creativity. That
allows the team to ‘bounce off’ each other and share
experience and insights at a faster rate than
otherwise. Some businesses have made the sensible
decision to ensure an Architectural Owner is part of
the core team. This ensures the evolution of the
design and the associated decisions can be made
quickly and taking into account team inputs. A
“Definition of Done” is agreed between team
members which is basically their charter of quality. It will outline the agreement
that the Product Owners’’ decision on acceptance criteria being met is final, but
also that each member of the team will apply specific coding and testing
standards as well as other quality standards and documentation requirements
as part of their method of working. It’s the team statement of what they believe
is the standard to which their work will be done!
Example: Recently the product owner on my project proposed that he would
like to change the approach to the solution design so as to take advantage of
recent changes in underlying infrastructure and architecture made possible
through work being done for other customers. The team discussed this at length
and ultimately agreed it was the best way of ensuring sustainability and
scalability and supported good design principles. The release plan was altered
and the stakeholders informed through a design walkthrough which was well
received.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
Complexity is synonymous with
higher risk of failure. It is also the
fundamental reason for slow and
unresponsive systems. Defects in the
operational world out there also lead
to “technical debt”. The Agile approach
encourages everyone on the team to
look for simple solutions to complex
problems.

8. © 2016 Robertson Consulting Ltd
Example: It was suggested that there could be a considerable saving using a
“product” based approach to a complex sales and marketing system which we
could make if we were able to take advantage of functionality present in the
underlying current product suite. It meant that the Product Owner needed to
accept some minor feature changes but would save
weeks of work by approaching the design that way,
maximizing the amount of work done. The
developers also recognised that doing refactoring
(code reviews removing complexity and
redundancy) would improve the overall quality of
the product so it was written in to the “Definition of
Done”.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Have you ever been to a meeting where no one speaks until the senior guy in
the room speaks? The resultant effect being that there is probably only “one
way” forward? Where this happens people who make have great and different
ideas tend to keep quite (but maybe complain outside the meeting!) and so
what is done is not the best for the customer. Self-organizing teams tend to
encourage natural leaders and experts in their subject to be free to express
themselves. Anyone in the team can challenge anyone else and put their point of
view. Thus team members are not always waiting for the project manager to
approve or come up with the solution to a problem but tackle things based on
who is best placed to do it.
Example: I have found that
a team without a leader
tends to fare better if one
emerges based on mutual
respect and agreement
rather than position (role)
or external appointment.
Agile also encourages cross-
skilling, so the team re-
organizes from time to time
so the person leading today
may be different tomorrow,
depending on the situation
or need.
12. At regular intervals, the team reflects on how to become more effective, then fine tunes
and adjusts its behavior accordingly.
In Waterfall teams this is not a natural event but usually forced upon it! Often
left as the final action as part of the “lessons learnt” report in a post
implementation review. Have you ever tried to find one . (Continued over…)

9. © 2016 Robertson Consulting Ltd
after the project has closed? In Agile it is part of the Agile DNA. Every Sprint has
a retrospective, each Sprint Planning session takes opportunity to learn from
the last Sprint, and each Backlog Grooming session encourages improvement.
Example: In one of the traditional projects I was involved
with before joining Microsoft I found it was down to me to deal
with a developer on the “team” who was used to “doing things his
way” as project manager. Ultimately, it was down to me being
clear and direct about his further involvement in the project
unless he worked with the team! Fortunately we ended up seeing
things through to a good place. However the influence on this guy
was down to our relationship being in the right place to effect the
change. A similar thing happened later once I had moved on to
Microsoft on an Agile project, in effectively the Scrum Master role,
the retrospective at the end of the first Sprint allowed the team to
reflect on things and interestingly the individual’s independence
from the team and lack of accountability was being noticed. This time the whole
team dealt with it. A much better result!
Simon Robertson is an experienced Principal Project Manager and Trainer. He has a
fundamental love of working with and training teams to deliver great projects. Simon is a past
Chair of the PMI South Regional Committee and past Director of Professional Development for
the UK Chapter of the PMI. He continues to remain passionate about developing the discipline
of Project Management at all levels of education. He is recognised as a Project Management
(both Classic and Agile) expert and a Risk Management expert.
Robertson Consulting Ltd is a Global Registered Education Provider (R.E.P.) with the Project
Management Institute (PMI REP ID: 3408), and a Global Registered Education Provider (R.E.P.)
for SCRUMStudy (REP I.D.SS2014226). The company is also a training partner to VMEdu, Inc
and STS (providing Simultrain course capability) and registered Microsoft Partner (ID 2778256).
Qualifications: Over 40 years of project delivery and over 28 years of training experience.
Simon is using tried and tested good practice based on Global Standards such as the PMI
PMBOK
®
Guide Global standard, the PMI Practice Standard for Risk Management, the PMI
Practice Standard for Earned Value Management, and using standard project management
tools, techniques and methods.
Certifications: BSc (Hons), PMI Project Management Professional (PMP)®, Agile Certified
Practitioner (PMI-ACP)®, Scrum Master Certified (SMC), Scrum Product Owner Certified (SPOC),
Agile Expert Certified (AEC), SCRUMstudy Certified Trainer (SCT), ITIL IS PM Cert, ITIL v3
Foundation Cert, Microsoft Certified IT Professional (MCITP)®, Microsoft Certified Technical
Specialist (MCTS)® and Microsoft Certified Trainer (MCT)®.
Memberships: PMI, ILM and APM. Microsoft Partner.
PMI, PMBOK, PMP and REP are registered marks of the Project Management Institute, Inc.