Be agile in Adopting Agile

D id Peters
David P t
Principal
Consultant
2010/08/04
1

What is Agile? It’s Adaptability

 An iterative and incremental (evolutionary) approach performed in a
highly collaborative manner with just the right amount of ceremony to
produce high quality software in a cost effective and timely manner which
meets the changing needs of its stakeholders.

“Must see the Eiffel tower and “Went up the Eiffel tower
spend 4 days in Monaco” 2 days in Monaco was enough”
In charge? Value?
2010/08/04 2

1
 Some Quotations
“Agile is people driven; it’s driven by principles of people leadership not project
management.”

“It’s not something you can change overnight. Tools are a means to achieve it. It
requires lot of un-learning before learning these new agile principles.”

“It requires management commitment and support otherwise it cannot survive.”

“It did not last long………… Project Control took over”

“It's relevant to remember that there are different Agile Methods available, each of
them fitting different purposes”

“Agile assumes that the company wants a long term software development effort
not a short term p
project”
j

“By putting an agile façade on top of traditional strategies, we managed to derail

the productivity improvement potential of actual agile techniques.”

“Most organizations do not realize that agile needs to be highly customized to the
nature of the team and the project.”

2010/08/04 3

Playing to win
Grady Booch – “Software development is a team sport”

Yes, but compare a Relay team to a Rugby team

I will run as fast as I can I will play my role as best I can

I will try
y as smooth a handover as If you are in trouble I will help
possible

It’s a whole new ball game!

2
 Which Statement is true?

 Agile is Dead
or

 Agile is now Mainstream

 Or Both
– Agile is dead because it’s now mainstream

Janusz Gorycki

2010/08/04 5

Agile has gone Mainstream – analyst community

"Thirty-five percent of .…respondents
have projects or pilots underway, and
only 12 percent do not see a fit for Agile Third-party research suggests
even wider
id adoption
d ti
processes in their organizations.

The fact that 88 percent of these Have you adopted

organizations (one-third of which have any Agile techniques?
over 10,000 employees) are using or
evaluating Agile processes proves that “No”
35% “Yes”
Agile processes have truly hit the 65%
mainstream."

- Excerpt from “And the Agile Survey Says…” Source: Ambler ‘Agile Adoption Rate Survey’
Agile Journal of over 4200 Dr. Dobb’s subscribers

6 6

3
Organizational Complexity: What challenges has your organization
encountered while adopting agile approaches?
Waterfall culture 54%

Stakeholder involvement 52%

T&E 33%

Lack of Trust 32%

C&C Culture 32%

Specialization 31%

Other visions 29%

Stakeholder Resistance 15%

Mgmt Resistance 14%

Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/ 7

What reasons does your organization have for not adopting agile
approaches to development? Top 10 of 14
Rigid Culture 59%
No Training 47%
No Mgmt
Mgmt. Support 33%
Geo. Distribution 23%
Org. Distribution 20%
Regulatory 19%
Process Frameworks 14%
Tech. Complexity 14%
No Stkhlder Support 14%
Domain Complexity 13%

Copyright 2009 Scott W. Ambler www.ambysoft.com/surveys/ 8

4
The Agile Manifesto
We
Value: Individuals and Over: Processes and
interactions tools

Working Comprehensive
Software Documentation

Customer Contract
collaboration Negotiation

Responding to
Following a Plan
change

While there is value in the items on the right,

we value the items on the left more.
9

The Agile Manifesto

We
Value: Individuals and
interactions

Working
Software

Customer
collaboration

Responding to
change

10

5
The Agile Manifesto
We
Value: Individuals and Over: Processes and
interactions tools

Working Comprehensive
Software
Agile is not a Documentation
methodology,
it’s a set of
Customer Contract
collaboration
Values and Negotiation
Principles
Responding to
Following a Plan
change

While there is value in the items on the right,

we value the items on the left more.
11

Its Driving Force is:

We
Value: Individuals and Over: processes and
interactions tools

Working Comprehensive
Software Documentation

Customer
VALUE Contract
collaboration Negotiation

Responding to
Following a Plan
change

While there is value in the items on the right,

we value the items on the left more.
12

6
Traditional Practices
 Big Upfront (BUF) Requirements
 InDetail
 Signed off

 Big Upfront Planning


 In Detail
“Fixed” Price
The Plan
 Early

 Command and Control Management

 Silo Team organisation

2010/08/04 13

Requires Cultural Change

PLAN VALUE
We will deliver value to the
 Not Easy business at a good ROI

 Needs Time Another quote:

“I finally figured something out.
 Must be Demonstrated Agile development is a culture,
not a process” – Josh
 Requires:
Belief and You have made the right decision

Perseverance To make the decision right

2010/08/04 14

7
 It’s not Agile Practices, but Agile Adoption
that Fails

In my travels as an agile coach, what I

“In
have found to be the case is that agile
practices don't fail, rather the variations on
agile adoption fail.” – Jean Tabaka

2010/08/04 15

Agile for Agile sake?

 It’s NOT about becoming Agile in your Software
Development – just adopting an Agile methodology

 It’s about becoming more efficient / productive in

your software Development and delivering value to
the business by
 Adopting good practices, many of which (old and new)
have been highlighted by Agile Methodologies

Scaling Ceiling
Agile Adopting Good Practices
Methodology
Current
Way
16

8
Why agile development? Because it works!

18

9
 Traditional Practices
 Big Upfront (BUF) Requirements
 InDetail
 Signed off

 Big Upfront Planning

 In Detail
 “Fixed” Price
 Early

 Command and Control Management

 Silo Team organisation

2010/08/04 19

Face-to-face Discussions
Product

Business
Need

The BA
Requirements

Scrum OpenUP
Product User Stories Use Cases Supplementary
Backlog (place holders) Scenarios Specifications

Scope is not a Requirements

Document, it’s a Continuous Detailed as
appropriate
Negotiation
Discussions

Can discussions replace

documentation?
20

10
Traditional Practices
 Big Upfront (BUF) Requirements
 InDetail
 Signed off

 Big Upfront Planning

 In Detail
 “Fixed” Price
 Early

 Command
C d anddC
Control
t lM Managementt
 Silo Team organisation

2010/08/04 21

A Date is not just a Date

 It has a Probability

Now Future

2010/08/04 22

11
Plan to Learn
Every type of work is governed by an Horizon of Predictability.
Any plan that extends beyond this horizon of predictability is
bound to fail. Agile work uses an explicit learning cycle tied in
with the planning of work to accommodate this inevitable
change.

Project Plan (months)

Iteration
Plan
(weeks)

Predictability?
Level of detail?

23

Dates, Scope, Satisfaction Can Not be

Accurately Pre-determined and Then Fixed

12
 Traditional Practices
 Big Upfront (BUF) Requirements
 InDetail
 Signed off

 Big Upfront Planning

 In Detail
 “Fixed” Price
 Early
 C
Command d anddC
Control
t lM Managementt
 Silo Team organisation

2010/08/04 25

Cost Estimate Fidelity

4X Project End
Erroor in Cost to Complete Estimatee

Over-estimated

Estimate
0 Actual

Under estimated
Under-estimated

X/4

26

13
 What’s Negotiable and What’s Not?
Traditional Agile

Fixed / Functionality Time Cost

Non-negotiable Quality
Value Driven

Plan Driven
Variable /
Negotiable Functionality
Time Cost

“II want it all!

all!” “What’s the best value
“If we run into trouble”
I can get for my time and
But money?”

What percentage of systems / applications

are never or rarely used?

1 - 27

Traditional Practices
 Big Upfront (BUF) Requirements
 InDetail
 Signed off

 Big Upfront Planning

 In Detail
 “Fixed” Price
 Early

 Command and Control Management

 Silo Team organisation

2010/08/04 28

14
 Whole Team Practice
The Whole Team practice describes how a
development team organizes itself to enable it to work
effectively.
 Everyone has a sense of belonging on the team
 Team includes everyone required to build the system
 Everyone contributes any way that they can
 Team is self organizing With Leadership
 Team maintains a sustainable pace
 Everyone works together closely
 Team takes Responsibility for outcome

29

Traditional Practices
 Big Upfront (BUF) Requirements
 InDetail
 Signed off

 Big Upfront Planning

 In Detail
 “Fixed” Price
 Early

 Command and Control Management

 Silo Team organisation

2010/08/04 30

15
Playing to win
Silo Whole Team

I will run as fast as I can I will play my role as best I can

I will try as smooth a handover as If you are in trouble I will help

possible

It’s a whole new ball game!

31

Well how do we Adopt Agile?

 We be Pragmatic

 Yeah
Yeah……OK????
OK????

2010/08/04 32

16
 Practise Agile in Adopting Agile Practices
Big Bang
New Agile New Agile
Current
Boom
Methodology Methodology
Environment
Remember Business
Re-Engineering?
Iterative / Incremental

New Agile
Practice New Agile
Practice
Current
Environment
New Agile
Practice New Agile
Practice
Transparency
Collaboration
Is appropriate, of value to us Business Process
Improvement (BPI)

2010/08/04 33

XP Practices (1)
 Planning
 User Stories are written
 Release planning creates the release schedule
 Make frequent small releases
 The project is divided into iterations
 Iteration planning starts each iteration
 Managing
 Give the team a dedicated open work space
 Set a sustainable pace
 A stand up meeting starts each day
 The project velocity is measured
 Move people around
 Fix XP when it breaks

34

17
 XP Practices (2)
 Designing  Testing
 Simplicity  All code must have unit
 Choose a system metaphor tests
 Use CRC cards for design sessions  All code must pass all unit
 Create spike solutions to reduce risk
t t before
tests b f it can be
b
released
 Non functionality is added early
 When a bug is found tests
 Refactor whenever and where ever possible
are created
 Coding  Acceptance tests are run
 The customer is always available often and the score is
 Code must be written to agreed standards published
 Code the unit test first
 All production code is pair programmed
 Only one pair integrates code at a time
 Integrate often
 Set up a dedicated integration computer
 Use collective ownership

35

Scrum Practices
 Continuous Improvement
 Do retrospectives at the end of each
sprint
 Find impediments to the team and fix
them
 Have the team figure out how to
improve the team’s process
 Planning
 Do planning at beginning of iteration
 Do release planning at the start of the
project
 Build in iterations (1 -6
6 weeks
weeks, but
time-boxed regardless of length)
 Have some daily method of finding out
what people are doing and seeing
their impediments
 Organisation
 Have teams be organized as
cross-functional teams
 Management
 Have a manager / project
manager / scrum master
facilitate improving the team’s
process
 Development
 Finish building what was
started coding in an iteration
 Get feedback from customers
at least at the end of the
iteration

36

18
OpenUP Practices
 Management Practices
 Iterative Development
 Risk-Value Lifecycle
 Release Planning
 Whole Team
 Team Change Management
 Technical Practices
 Concurrent Testing
 Continuous Integration
 Evolutionaryy Architecture
 Evolutionary Design
 Shared Vision
 Test Driven Development
 Use Case Driven Development

37

Which Practices? Our “Work Item List”

 We need to examine the various practices that we could
adopt and decide which of them will be appropriate in
our organisation.
 We need to carefully consider the uniqueness of our
organisation and the projects we undertake to decide
which practices will fit in, and will help us in achieving
the goals we have identified.
 The major areas that we must consider are:
 Our organization’s culture
 Our customers and how they prefer to interact with us
 The types of projects we do
 The tools and processes that we currently use
 The strengths and weaknesses of our software-related staff

2010/08/04 38

19
 Agility is a Spectrum

Agile
Traditional
Some
Methodologies:

Waterfall

RUP

OpenUP

Scrum

XP
Need a
combination

MCIF
Measured Capability
Improvement Framework

39

Agility is Relative
Waterfall

Organizational Drivers
Team Size
Geographical Distribution  Mature or existing projects
Organization Distribution  50+ developers
Entrenched process,
process people,
people policy  C
Complex,
l multi-platform
lti l tf applications
li ti
 Distributed teams
 Need for scalability, reproducibility,
and traceability

 Maturing projects
 Multi-platform
 Growing in complexity
 Remote or offshore work MCIF
 Greater need for
coordination and handoffs

 Small team
 New projects Technical and Regulatory
 Simple application
Drivers
 Co-located Compliance
 Minimal need for documentation Governance
Application complexity

40

20
 Agile Scaling Factors
Compliance requirement Enterprise discipline
Low risk Critical, Project Enterprise
Audited focus focus

Geographical distribution Entrenched process,

people, and policy
Co-located Global
Minimal Significant

Agile
Development
Application complexity Organization distribution
Simple,
(outsourcing, partnerships)
Complex,
single In-house Third party
multi-platform
platform

Team size Degree of Governance

Under 10 100’s of
Informal Formal
developers developers

41

Top 10 Most Effective Practices (out of 30)

Continuous Integration 65%

Daily Stand Up Meeting 47%

Developer TDD 47%

Iteration Planning 44%

Code Refactoring 43%

Retrospectives 39%

Pair Programming 36%

Active Stakeholder Participation 35%

Potentially Shippable Software 28%

Burndown Tracking 26%

www.ambysoft.com/surveys/

21
 Agile Islands

Organisation
(Business) Non-agile

Agile Area
agile

“Agile
Agile software teams are not sustainable for very long if they are
islands in a sea of waterfall projects. The presence of Agile teams
creates a new and incompatible dynamic within a waterfall company.
Agile adoption programmes conducted without a thorough
understanding of this dynamic will continue to have a very high
mortality rate, especially in larger organisations. – Adam Finden

2010/08/04 43

So, When are we Agile? Important aspects of

these criteria:
1. Working software Flexibility
 Agile teams produce working software on a regular basis, Adaptability
 typically in the context of short, stable, time-boxed iterations.
2. Active stakeholder participation
 Agile teams work closely with their stakeholders, ideally on a daily basis.
3. Regression testing
 Agile teams do, at a minimum, continuous developer regression testing.
 Disciplined agile teams take a Test-Driven Development (TDD) approach.
4. Organization
 Agile teams are self-organizing, and disciplined agile teams work within an
appropriate governance framework at a sustainable pace.
 Agile teams are also cross
cross-functional
functional “whole teams
teams,”” with enough people with the
appropriate skills to address the goals of the team.
5. Improvement
 Agile teams regularly reflect on, and
 disciplined teams also measure, how they work together and then act to improve on
their findings in a timely manner.
2010 Rational Whitepaper “Scaling Agile
An Executive Guide” by Scott Ambler 44

22
 In Summary
 Adopting Agile is not easy
 Should be implemented as an Initiative in its own
right
i ht – is
i also
l a jjourney
 Should be done iteratively/incrementally
 Is not just an island – it has impact on and is
impacted by other parts of the business
 Requires cultural change
 Each environment has its own set of challenges
 Is worthwhile undertaking

2010/08/04 45

Questions?

2010/08/04 46

23
Today’s message

Agile
Traditional

K
Knowledge
l d
Methodiologies
Traditional RUP OpenUP SCRUM XP

Skill
Appropriate Agile Practices

TRUST
Transparent Collaborative
Behaviour
2010/08/04 47

Some Reasons for Failure

 Ineffective use of the retrospective
 Inability to get everyone in the planning meetings
 Failure to ppay
y attention to the infrastructure required
q
 Bad ScrumMasters
 Product Owner is Consistently Unavailable or There are
Too Many Owners Who Disagree
 Reverting to Form
 Teams Lacking Authority and Decision-Making Ability
 Not Having an Onsite Evangelist for Remote Locations
 A Culture that Does Not Support Learning
 Denial is Embraced Instead of the Brutal Truth

2010/08/04 48

24
 Which Statement is true?
 Agile is Dead

 Agile is now Mainstream

2010/08/04 49

Improvements do not come without

change “There is nothing more difficult to carry out nor more doubtful of success
nor more dangerous to handle than to initiate a new order of things;
for the reformer has enemies in all those who profit by the old order,
and only lukewarm defenders in all those who would profit by the new
order;; this arising
g partly
p y from the incredulity y of mankind who does not
truly believe in anything new until they actually have experience of it."

Niccolo Machiavelli 1469-1527

 Adopting new process and tools requires well-
designed strategy and plan
 Changes how people collaborate in software
development teams
 Behavioral and organizational change must be
introduced in a planned fashion
 Without appropriate guidance and the right
people and the right strategy teams and
organizations often fail to adopt the process and
tools effectively
 Must be attacked more like organizational change,
less like a technology upgrade
 The Kotter Framework - a well-known framework
for introducing change to an organization
 The eight-stage process
1. Establishing a sense of urgency
2 Creating the guiding coalition
2.
3. Developing a vision and strategy
4. Communicate the change vision
5. Empowering broad-based action
6. Generating short-term wins
7. Consolidating gains and producing more change
8. Anchoring new approaches in the culture

25
 Summary
 The primary metric for demonstrating that an
organization or project has transitioned to
effective agile delivery is the trend in the cost
of change. This measure of the adaptability
inherent in software releases is a key indicator of
the flexibility
y required
q to continuously
y navigate
g
uncertainties and steer projects toward success.
 The honest treatment of uncertainty is the
foundation of today’s best practices

When are we Agile?

Agilist: “Agile is more about doing development in iterations,
working code, customer feedback, adapting to changes rather than
picking and choosing few practices and calling yourself agile.”

Beware Trojan Rigidity

 Traditional methodologies incorporate rigidity
 Do “this” because the process says we must

 But what about Agile Rigidity

 “We do not do use cases in agile projects”

Sander Hoogendoorn

2010/08/04 52

26