1
Introduction to Agile
BCS Spring School
2nd March 2009
David [email protected]
Tel: 07778 558296www.radtac.co.uk
Introduction : David Hicks, RADTAC
Co-founder and Managing Director of RADTACSpecialist in Agile and Iterative approaches since mid 80sAgile Alliance Founder Member in 2002
Qualifications• Certified Scrum Practitioner and Scrum Master• DSDM Practitioner, Trainer and Examiner• APLN Agile Leader• PRINCE2 Practitioner
Agile Delivery• Esp. in Telecoms and High Tech arenas
Agile Enablement and Transformation• From 5 – 5,000 people• Enterprise Agile roll-outs of Scrum & XP, DSDM, Lean and A/OUP
© Copyright RADTAC 2009 2
2
RADTAC
Services• Delivery• Consulting
T i i• Training
Expertise• Agile Methods• Systems Development• Project Management• Organisational Transformation
RADTAC USPs• All of the leading Agile methods• With wider approaches beyond Agile• And the ability to make them scale and stick
© Copyright RADTAC 2009 3
Typical RADTAC Engagements
Agile Enablementand Transformation
Agile Enablement eGov Programme
Agile SystemsDevelopment
European PortalAgile Development
Global Services NHS Spine & eBordersPM & Delivery Method
and Transformation;IT Change Programmes
eGov ProgrammeAgile Enablement
PLM ProgrammeAgile Enablement
Agile Enablementand Transformation;Project Governance Agile Development
Agile SystemsDevelopment
Project GovernanceChange Programme
Agile Enablementand Transformation
Agile Enablementand Transformation
Agile Training Partner
© Copyright RADTAC 2009 4
3
Late and Over Budget Too!
As designed bythe architect
As specified in therequirements
As envisaged bythe project sponsor
What the customer needsAs releasedAs built bythe engineers
© Copyright RADTAC 2009 5
Empirical vs. Predictive Process
Far fromAgreement
Anarchy
Simple
Complex
Req
uir
emen
ts
Anarchy
SimpleClose to
Agreement
Close toCertainty
Far fromCertaintyTechnology
© Copyright RADTAC 2009 6
4
Waterfall Approach
Each stage completed and signed off before the next commences.Big ‘Up-Front’ Analysis / Design fixes detail in requirements / solutiong p y g qCommunication through documents
Analyse
Design
Potential pitfallsTime over-runCost over-runNot addressing real needsBuild
Test
Deploy
Not addressing real needsInadequate testing
© Copyright RADTAC 2009 7
Project Management Variables
AgileApproach
TraditionalApproach
Quality - A known risk
to be actively
managed Quality of the solution agreed and
fixedfixed
© Copyright RADTAC 2009 8
5
Agile Software Development
Iteration 1 Iteration 2 Iteration …InitialAnalysis, Solution, Plan
Identify,Plan, Do,Review
EEveryIteration Outputs towards
the full SolutionMetrics and
LearningIteration: typically every 2-4 weeks(aka Sprint or Timebox)Deployment: typically every 3-6 months
© Copyright RADTAC 2009 9
Benefits of Agile Development
Value
Agile
Visibility
Agile
Satisfaction
Traditional
Adaptability
Traditional
Risk
Traditional
Agile
Traditional
Agilead t o aAgile
Traditional Agile
Traditionalg e
© Copyright RADTAC 2009 10
6
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiation
The Agile Manifesto
Customer collaboration over contract negotiationResponding to change over following a plan
Pre-defined
Requirements
Process
Just-in-time Fixed at Start
Emprical
Agile Traditional
© Copyright RADTAC 2009 11
Remote and Written
Team
Collaboration
Solution
Self Organising and Empowered Managed and Directed
Evolve Big Design up-Front
Integrated & Verbal
The Leading Agile Methods
Scrum• 5 Values• 3 Roles
DSDM Atern• 8 Principles
• 3 Ceremonies• 3 Work Products
XP• 5 Values• 14 Principles• 12 Primary Practices
• 5 Lifecycle Phases• 12 Roles• 17 Work Products• 5 Key Techniques
Agile / Open Unified Process• 6 Principles
• 11 Corollary Practices
Lean Software Development• 7 Principles• 22 Thinking Tools
• 7 Disciplines• 4 Lifecycle Phases• 14 Roles• 8 Minimum Deliverables• 4 Guidance Pieces
12© Copyright RADTAC 2009
7
Scrum
24hours
Roles• Product Owner• Scrum Master• Scrum Team
Ceremonies• Sprint Planning• Daily Scrum Meetings• Sprint Review
Sprint2-4 Weeks
hours
Sprint Backlog
Backlog tasksexpandedby team
Daily ScrumMeetingArtefacts
• Product Backlog• Sprint Backlog• Burn Down Chart
Product BacklogAnyone can contribute itemsPrioritized by Product Owner
Potentially ShippableProduct Increment
© Copyright RADTAC 2009 13
Inspect and Adapt
Scrum doesn’t provide detailed ‘how to’ guidance
That would be ‘predictive’ not ‘empirical’
It provides a framework to help you decide ’what to do’
Through frequent opportunities to ‘inspect and adapt’
And making problems andimpediments painfully clear
© Copyright RADTAC 2009 14
8
Scrum Product Owner
Single co-ordinated customer inputIs an integral part of the Scrum teamRepresents all stakeholder needsRepresents all stakeholder needsSees vision through to implementationRanks and prioritizes needsProvides explanation of requirementsUltimately determines acceptance of productTo ensure ...• That the end-customer gets what they need when they need it• Alignment of Engineering and Product Management• Alignment of Engineering and Product Management• Consistency with Roadmaps & Product Management priorities
Two perspectives• Overall Vision – Outward looking, voice of the customer• Day to Day – Inward looking, value stream manager
© Copyright RADTAC 2009 15
Scrum Master
Facilitating Team SessionsAnalysis, design, development, etc.Release and Iteration planningDaily Scrum Meetings
Leading a Scrum TeamEmpowered effective team –workingWithout exercising formal authorityEnable close cooperation across allDaily Scrum Meetings
Sprint Demos Retrospectives
Representing the Team
Enable close cooperation across all roles and functions
Making Scrum WorkRepresenting the TeamTo Management and other stakeholdersShield the team from distractions, and remove impediments
Making Scrum WorkPhysical team working environmentInformation radiators, burn down charts and other tools and facilitiesEnsure the success of the process
© Copyright RADTAC 2009 16
9
Objectives of Daily Scrum Meetings
Share commitment - Most important goal• Was I able to fulfil my commitments yesterday? • What am I comfortable to commit to today? • What is obstructing me in fulfilling my commitments?
Communicate daily status, progress, and plans• Team updates each other – not the Scrum Master or Product Owner• Ensures daily reflection – inspect and adapt
Identify obstacles so that team can take steps to remove them • Early identification enables early resolution to maintain momentum• Brings full team resources to bear on impedimentsg p
Set direction and focus• Call attention to backlog priority, constant reminder of direction
Build a team • Regular communication and helping each other builds sense of ‘team’,
© Copyright RADTAC 2009 17
Burn Down Chart and Information Radiators
Tracks work remaining against planNot effort expendedProduced from Sprint BacklogProduced from Sprint BacklogMust be honest and visibleHelps determine probable finish dateSupplemented by other Big Visible Charts (BVC’s)
Iteration : 3 DATES : 1/04/08 – 14/04/08
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
DEFINE BUILD TEST DONE
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
TO DO
Test 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Test 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Test 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Test 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Test 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
Communicate Usage to CarriersTest 1 Can I specify the criteria for targeting a list of carriers?
Test 2: Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
Test 3: Does the system require zero training?
Test 3: Does the system provide the list in time for our daily Service meeting at 0900?
© Copyright RADTAC 2009 18
10
eXtreme Programming Practices
• Practices for extreme code quality• 1996: first XP Project • 1999: "Extreme Programming Explained“
by Kent Beck; 2005: 2nd edition
© Copyright RADTAC 2009 19
eXtreme Programming Practices
PRIMARY PRACTICES
TEAM• One Whole Team: IT & Business together
COROLLARY PRACTICES
TEAM• Maintain Team Continuity over several projects g
• Who all Sit Together …• … in an Informative Workspace• Doing Energetic Work at a sustainable pace
PLANNING• Requirements and plans defined using Stories• Slack tasks that can be dropped if need-be• Develop & deliver in Weekly & Monthly Cycles
DEVELOPMENT
y p j• Shrink Teams to seed others• Real Customer Involvement, not proxy
PLANNING• Negotiated Scope: fixed time, cost & quality• Customer Pays-Per-Use, not per release
DEVELOPMENT• Incremental Design ‘refactoring’ as you build• Create automated Tests First, before the code• Continuous Integration, many times a day• Quick integration & testing: Ten-Minute Build.
• Eliminate defects by Root Cause Analysis• Generate all documentation from Code & Tests• Shared Code: any team member can change it• Maintain just one, official Single Code Base• Daily Deployment of software into production
© Copyright RADTAC 2009 20
11
Example Story Card – Front
Cards used for Team planning
High level
Communicate Usage to Carriers
High level summary
Evolve from ‘Epics’ to small Stories
1-5 days effort for ultimate Stories
As a Freight Manager
I want to communicate with targeted lists of carriers to tell them about their performance, and what they can do to improve their efficiency
Stories
Break into tasks in Iteration Planning
So that we can increase overall customer return by at least 5% next year
© Copyright RADTAC 2009 21
Example Story Card – Back
Used for all work items• Functional reqs• Non-functional
Communicate Usage to Carriers
• Technical
Full Story• Card• Conversation• Confirmation
Use other techniques too if needed
Can I specify the criteria for targeting a list of carriers?
Does the system provide the list of appropriate actions that the carrier can take to improve their usage efficiency?
too if needed• Class Models• Use Case etc.
Acceptance criteria -> full test suite
Does the system require zero training?
Does the system provide the list in time for our daily Service meeting at 0900?
© Copyright RADTAC 2009 22
12
Test Driven Development and Refactoring
First, agree and build an automated testThen build the system code to exercise itThen amend and refactor if necessary
ChangeCode
lThen amend and refactor if necessary
Makes each class stand-alone
WriteTest
Functionality
RunTest
DidTestPass
?
BetterY
Yes
No
Communicate Usage to CarriersAs a Freight Manager
I want to communicate with targeted lists of carriers to tell them about their performance, and what they can do to improve their efficiency
So that we can increase overall customer return by at least 5% next year
Owner: F. Flintstone Complexity:3
Focuses on interfaces and contractLeads to highly cohesive, looselycoupled classes – good design…and promotes refactoring
RefactorCode
BetterPossibleDesign
?
End
Yes
No
© Copyright RADTAC 2009 23
Lean Software Development
Eliminate WasteThe 7 wastes of software development• Incomplete Work; Handoffs; Extra Features;
Delays; Relearning; Defects; Task Switching
Deliver FastQueues are buffers that slow you down• Speed targets cost, quality and customer needs• Optimise Cycle Time not Utilisation
W k i bl l iBuild Quality InDefects indicate a defective process• Define tests not requirements• Automate all tests• Continuous integration
Create KnowledgePlanning is useful. Learning is essential.• Hypothesise; experiment; select best option• Mandate standards but challenge them• Focus on responding not predicting
• Work to your capacity: set a repeatable velocity
Respect PeopleEngaged people are the best advantage• Thrive on pride; commitment; trust & applause• Good leadership brings-out the best in a team• Partnership must not cause conflicts of interest
Optimise the WholeCombine business and technology focus
Defer CommitmentAbandon detailed up-front specification • Architect for any new feature at any time• Code experimentally: change-tolerant• Decide at the last responsible moment
• Focus on the full value stream - concept to cash• Complete products are built by complete teams• Measure the whole; not the parts
© Copyright RADTAC 2009 24
13
Agile / Open Unified Process Phases
ModellingImplementation
(i di )(i.e. coding)Testing
Deployment
Config & Change MgtProject Management
Environment
Inception Elaboration Construction Transition
Inception To gain agreement on the lifecycle objectives for the projectElaboration To create a proven, stable working architectureConstruction To complete the product to optimal quality in the most efficient way
Transition To ensure the product is fully available for all of its end users
© Copyright RADTAC 2009 25
Agile / Open Unified Process Lifecycle
Phases iterate in fixed-length cycles until milestones are achievedNumber and duration of iterations varies by project but 2-4 weeks is idealEvery Phase produces software (with the possible exception of Inception)Software ‘releases’ from each iteration are internal to the project, but …they are as close to ‘complete’ as possible and in a planned, ‘tested’ stateExternal releases are made via the ‘Transition’ phase
Inception Elaboration Construction TransitionIteration
#1Iteration
#2Iteration
#3Iteration
#4Iteration
#5Iteration
#6Iteration
#7Iteration
#8
Engineering ProductionStages
Phases
Iterations
LifecycleObjectivesMilestone Lifecycle
ArchitectureMilestone
InitialOperationalCapabilityMilestone
ProductRelease
Milestone
#1 #2 #3 #4 #5 #6 #7 #8
Software‘Releases’
© Copyright RADTAC 2009 26
14
Stakeholders and Project Team Roles
EstablishProjectVision
Project Team• Analysts
Executive ManagerEstablishProjectScope
Commit toProjectResults
Commit Project
Marketing/User Manager
• Analysts• Developers• Testers• Managers• Production
and Support Roles
resourcesand funds
EvolveRequirement
Detail
System User
© Copyright RADTAC 2009 27
Core A/OUP Artefacts
SoftwareSource Code
Test Suite
© Copyright RADTAC 2009 28
15
DSDM Atern
© DSDM Consortium 2007
© Copyright RADTAC 2009 29
Vision; Objectives; Terms of Reference
Technical andBusiness Feasibility
Solid Foundations forBusiness ImpactTechnical Architecture
DSDM Atern Lifecycle Framework
Technical ArchitectureProject Management
DemonstratingRequired
Functionality
Deploy Systemand Train Users
Review Project andKey Practices
Engineering for Quality and Robustness
Review Project andAssess Benefits
Key Practices• Facilitated Workshops• Modelling• MoSCoW Prioritisation• Timeboxing• Iterative Development
© Copyright RADTAC 2009 30
16
Atern Roles & Responsibilities
© DSDM Consortium 2007
© Copyright RADTAC 2009 31
Terms ofReference
FeasibilityAssessment
PRL
BusinessFoundations
Pre-Project Feasibility Foundations Exploration Engineering Deployment Post-Project
DSDM Atern Products
ManagementFoundations
PRL
Delivery Control Pack
Delivery Plan
TimeboxPlan
TimeboxReviewRecord
ProjectReviewReport
Deployment Plan
BenefitsAssessment
OutlinePlan
SolutionFoundations
DeployedSolution
Evolving Solution
Solution Assurance Pack
Record Report
© DSDM Consortium 2007
© Copyright RADTAC 2009 33
17
Leading Agile Approaches : Comparison
Defined Practices Defined ProcessesDSDM Atern
Agile Unified ProcessScrum
Lean Software DevelopmenteXtreme Programmingg g
Code an
d
Test P
ractic
es
Analysis
and
Design Prac
tices
Teamworki
ng
Practic
es
Mana
gemen
t
Practic
es
Iteratio
n
Proces
s
Projec
t Fea
sibility
/
Initia
tion Proc
ess
Outline
Ana
lysis
/
Design / P
lanning
Dev
elopm
ent
Proces
s
Dep
loymen
t
Proces
s
Defined Roles Defined DeliverablesDSDM Atern
Agile Unified ProcessScrumScrum
Lean Software DevelopmenteXtreme Programming
Agile P
rojec
t
Manage
r Role
Embedd
ed
Customer
Role
Agile D
evelopm
ent
Team R
oles
Other
Manag
emen
t
Projec
t Role
s
Other
Custom
er
Projec
t Role
s
Require
ments
Manage
ment L
ist
Detailed
Iterat
ion Plan
Busines
s Visio
n and
High-lev
el Req
uiremen
ts
System
s
Archite
cture
Projec
t Plan
s and
Busines
s Cas
e
© Copyright RADTAC 2009 35
PragmaticAgileTM - Planning your Approach
Local Practices Traditional Waterfall, RUPPrince2 PMI APM ITIL
CMMI Lean ISO
Other Methods &Wider Environment
AgileManagement
P ti
Agile MethodFramework:
Defined project lifecycle;deliverables; roles etc.
DSDM
DSDMA/OUP
XPLean
XPLean
DSDMA/OUP
Scrum
XPLean
Practices
AgileEngineering
PracticesXP
Lean
ScrumScrumDSDMA/OUP
Agile Practices
Individual Methods Combinations© Copyright RADTAC 2009 36
18
Introduction to Agile
BCS Spring School
2nd March 2009
David [email protected]
Tel: 07778 558296www.radtac.co.uk
Top Related