Date post: | 21-Jan-2018 |
Category: |
Business |
Upload: | freek-hermkens |
View: | 196 times |
Download: | 1 times |
Introducing Agile Processes into a
Waterfall Organisation
Chris Cooper-Bland, Senior Architect @ Endava Ltd
2
Agenda
What is Agile – Refresher What makes Organisations Waterfall? Introducing Change
Change the process Change the Organisation
What works Summary and Q&A
How many of your organisations are using agile currently?How many are planning to?
3
Delivering business value is hard…
“Of the work executed: “Many (possibly most) organisations lose as much as 45% of their total revenues due to costs associated with low quality”
Six Sigma
“Some 75 percent of most large-scale J2EE projects fail by missing both time and budget projections …”
Mark Driver, Gartner
“64% of features actually delivered are either rarely or never used”
Jim Johnson, Standish Group
4
Brief History of Development Methodologies
WATERFALL (Royce)
Requirements, designimplementation, verification & maintenance
1960 85 91
Methodologies
19801970
V-MODEL (Anon)
Aligns testing toWaterfall development
SPIRAL MODEL (Barry Boehm)
Iterative
RAD(James Martin)
Prototyping, iterative, time-boxed, user driven
RUP (Rational)
Object oriented, iterative, time-boxed, user driven
AGILE e.g. XP(Kent Beck)
Incremental, user driven, low process
98 99
Waterfall V-Model
Spiral Model
RAD
RUP
5
Agile Misconceptions? Agile means: “letting the programming team do whatever they need to
with no project management, and no architecture, allowing a solution to emerge, the programmers will do all the testing necessary with Unit Tests…”
6
What is Agile? http://www.agilemanifesto.org/
Management can tend to value the things on the right over the things on the left
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.
7
Working Software Delivered
RequirementsPrioritised Requirements & Features “Backlog”Requirements
RequirementsRequirements
Requirements
Prioritised Iteration Scope
Daily Scrum Meeting: 15 minutesEach teams member answers 3 questions:1) What did I do since last meeting?2) What obstacles are in my way? 3) What will I do before next meeting?
Team-Level Planning Every 24hrs
Every Iteration4-6 weeks
Applying Agile:Continuous integration; continuously monitored progress
Agile project management - SCRUM
8
Agile - XP explained (1)The Values Communication Simplicity Feedback Courage Respect (added in the latest version)
9
Agile - XP explained (2)1. Test First Programming
Test First without code2. The Planning Game
- Business Stories- Customer decides, Prog. Implements
3. Small, Frequent Releases- Release early and release often
4. Always use the Simplest design that adds business value
5. System Metaphor- Programmers define a handful of classes and patterns that shape the core business problem and solution- Like a primitive Architecture
6. On-site Customer- Customer has authority to define functionality- encourages face-to-face dialogue
7. Refactoring Restructuring code without changing its functionality- Mainly Simplification
8. Pair Programming9. Collective Code Ownership10. Coding Standards
- Everyone should use the same coding styles.
11. Continuous Integration- At least a few times a day- All unit tests must pass prior to integration- All functional tests must pass afterwards
12. Forty Hour Week !- Tired programmers write poor code and make more mistakes
10
Water Fall Organisations
Accounting system – annual accounts, monthly returns
Legal and regulatory controls
Shareholders – 3 year plans, annual plans
Interface with other organisations
SLAs Reward System, annual
event not immediate
11
Random Example
From Northern Constabulary
12
Approach to Change Models to introduce change into
the organisation Incremental approach Step change Thin threads
Scope of change island or wholesale
Prerequisites for change Blockers & enablers - timing
Key influencers Other changes Disasters
13
What to change – Best Practices
Collaborative working Iterative projects Visual Modelling Risk based prioritisation Requirements Management Change Management Configuration Management Tools Traceability
Most Useful
Least Useful
14
Factors for Success
Choose the right project Size Importance visibility
Get buy-in of senior management
Communicate to all Use experienced people Don’t trust blindly
effort = people * environment *size(process)
- Walker Royce
Common sense – no silver bullets
15
Changing the process - Integrating the method
Advantages Single place to look Easy alignment People already understand parts
Disadvantages May lead to confusion External staff don’t know it Overlaps and/or gaps
16
Customising the method
Project defined process documented in some form
Organisational Tailoring of Method
Organisation’s Software Engineering group
Project Assurance(monitoring adherence to process and feedback for Software process improvement)
Industry Standards. (e.g. ISO 12207,SW-CMM)
Industry Methods development (e.g. Iterative, Agile)
Standard Method specification
Industry Level
OrganisationalLevel
ProjectLevel
Macro-level tailoring
Micro-level tailoring
17
Changing the organisation People
Team rewards Celebrate success Leadership – management must ask the right questions Communication, brown bags etc.
Understand perceptions of success, what does finished mean? Quality/stage gates
Senior Management control Estimating and budgeting Real options Portfolio planning
Structure of the organisation
18
Estimating
This will prove problematic Identify an approach early, keep reviewing it Ideal model is to use a model calibrated with the
actuals captured from your organisation, but …. Use model with someone else's metrics Use Industry model
CoComo II Function point analysis
Guess Planning game is usually too late to help
19
The Budgeting Problem
Source McConnell 1998
The Cone of Uncertainty
20
Addressing itConvince management to make a fixed investment to establish costs
Source McConnell 1998
21
Application Project Portfolios
Senior management must give authority and control to IT
Use a portfolio management approach Define portfolio
segments Apportion available
budget Revalidate at stage
gates, for balance and progress
22
Real Options – a way of thinking Based on commodity
options – right but not an obligation to buy at a point in the future
Investment is continued only in favourable conditions, use probability models to predict future likelihood of return
Can hedge different investments
Allows management to be in control
Share holders like it
23
Structure – Skunk Works
Lockhead Martin needed to develop secret projects, outside formal control
Formed in June 1943 – Burbank CA
14 rules to ensure efficiency – similar to XP principles
Now seen as technique for introducing change – but …
24
Structure - Radical Changes
Change the company structure of the organisation Create new spin-off
company Joint venture Acquisition
Change the internal structure New ventures
department New project teams
Existing Structure
Bureaucracy Dynamic
Agility required
Waterfall
XPNo Change
25
Don’t do this – if you want to fail
Use integrated teams Sort out the development environment early Choose tools carefully Enterprise architecture is important for
large/long lived systems One person needs to own the process vision
with support from many Use partners experienced in the method
26
What Works Well
Configuration and change management, continuous integration
Selling the method Books, presentations etc.
Immersion for the project Briefings for the rest of the company
Make them want it too…
27
Summary
The organisation will have to change too More you have to change the harder it is
28
Resources
Craig Larman’s books http://www.bcs-spa.org/ http://www.dsdm.org/ http://www.real-
options.com/