Applying agile principles a brief paper

© 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. 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…)


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.


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…)


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.


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.


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.


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…)


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.

Applying agile principles a brief paper

Technology

Transcript of Applying agile principles a brief paper