Introduction : David Hicks, RADTAC - BCS Bristol Spring School... · •With wider approaches...

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


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 Training Partner


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


Empirical vs. Predictive Process

Far fromAgreement

Anarchy

Simple

Complex

Req

uir

emen

ts

Anarchy

SimpleClose to

Agreement

Close toCertainty

Far fromCertaintyTechnology


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


Project Management Variables

AgileApproach

TraditionalApproach

Quality - A known risk

to be actively

managed Quality of the solution agreed and

fixedfixed


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


Benefits of Agile Development

Value

Agile

Visibility

Agile

Satisfaction

Traditional

Adaptability

Traditional

Risk

Traditional

Agile

Traditional

Agilead t o aAgile

Traditional Agile

Traditionalg e


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


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


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


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


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


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’,


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?




DEFINE BUILD TEST DONE


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?






































10

eXtreme Programming Practices

• Practices for extreme code quality• 1996: first XP Project • 1999: "Extreme Programming Explained“

by Kent Beck; 2005: 2nd edition


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


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


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?


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


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


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


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’


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


Core A/OUP Artefacts

SoftwareSource Code

Test Suite


15

DSDM Atern

© DSDM Consortium 2007


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


16

Atern Roles & Responsibilities



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



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


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

Introduction : David Hicks, RADTAC - BCS Bristol Spring School... · •With wider approaches...

Documents

Transcript of Introduction : David Hicks, RADTAC - BCS Bristol Spring School... · •With wider approaches...