ITIL® & Agile

Matthias Gessenaymatthias.gessenay@corporatesoftware.ch

ITIL® is a Registered Trade Mark of the Cabinet Office.

© Crown Copyright Material reproduced under licence fromthe vanilla Material „Agile“ from APMG

Agenda

� Introduction in Agile Philosophy & Principles� Timeboxing & Moscow� Integration with ITIL®®

Agile concerns and issues?

All Agile Slides (c) by DSDM Consortium

What is Agile?

� Generic Description of a style of working� Flexibility� Working closely with customer throughout� Ensuring final solution actually meets business need� Deferring decisions about detail as late as possible

A LG I E

What is Agile?

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value

People and Interactions over Processes and Tools

Working Software over Comprehensive DocumentationWorking 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.(But Agile is not just about delivering software, it applies to all types of project)

Agile Project Management - The Basics

Basics – What is negotiable?

�Principles support the philosophy�Highlight attitude and mindset needed by team�Compromising any principle undermines philosophy

• And introduces risk

Basics – The Principles

�Applying all principles ensures maximum benefit�Collectively principles enable organizations to

collaboratively deliver best value solutions

Basics – Principle 1

�Focus on the business need– Decisions based around project goal

– To deliver what business needs it to deliver, when it needs to be delivered– Requires team to

• Understand true business priorities• Establish sound business case• Seek continuous business sponsorship • Seek continuous business sponsorship

and commitment• Guarantee Minimum Useable Subset

• Supported by– Business roles – Business Products agreed at Foundations stage– Key techniques - MoSCoW prioritization and Timeboxing

�Deliver on time� Requires team to�Timebox the work�Focus on business priorities�Always hit deadlines

Basics - Principle 2

� Supported by� Key techniques : Timeboxing and MoSCoW�To build a reputation for timely and predictable deliveries

Basics - Principle 3�Collaborate

� Requires team to� Involve the right stakeholders at the right time, throughout project�Ensure team members are empowered to make decisions

on behalf of those they represent�Actively involve business representatives�Actively involve business representatives�Build one-team culture

� Supported by� Business roles� Key technique : Facilitated workshops

Basics – Principle 4

�Never compromise quality– Requires team to

• Set level of quality at the outset • Ensure quality does not become a variable• Design, document and test appropriately• Test early and continuously• Build in quality by constant review with the right people• Build in quality by constant review with the right people

• Supported by� Testing products� Early and integrated testing� Regular reviews throughout lifecycle� Key techniques : MoSCoW and Timeboxing

Basics - Principle 5

�Build incrementally from firm foundations�Requires teams to� Strive for early delivery of business benefit where possible� Continually confirm correct solution is being built� Formally re-assess priorities and ongoing project viability with

each delivered incrementeach delivered increment

�Supported by� The lifecycle� Creating a solid base of knowledge (Feasibility and Foundations)

before developing incrementally (through Exploration and Engineering)

Basics - Principle 6�Develop iteratively

– Iterative development allows team to converge on accurate solution– Nothing built perfectly 1st time– Requires team to

• Do enough design up front (EDUF) to create strong foundations• Build products using an iterative approach• Build customer feedback into each iteration• Accept that most detail emerges later rather than sooner• Accept that most detail emerges later rather than sooner• Embrace change – the right solution will not evolve without it• Be creative, experiment, learn, evolve

– Change is inevitable, allow for it and harness its benefits

• Supported by– Iteration and constant review

� Ensures the evolving solution aligns with what business really needs

Basics – Principle 7

�Communicate continuously and clearly– Requires team to

• Run daily stand-up sessions• Use facilitated workshops• Use ‘Rich Communication’ –modelling, prototyping• Present iterations of evolving solution early and often• Keep documentation lean & timely• Keep documentation lean & timely• Manage stakeholder expectations throughout• Encourage informal, face-to-face communication at all levels

• Supported by� User involvement and empowerment� Stand-up and Facilitated workshops� Clearly defined roles and user involvement� Models and prototypes – to make early instances of

solution visible

Basics – Principle 8�Demonstrate control

�Requires team, especially Project Manager and Team Leader, to� Use appropriate level of formality for tracking and reporting� Make plans and progress visible to all� Measured progress through delivery of products� Manage proactively� Continuously evaluate project viability based on business objectives

17

� Continuously evaluate project viability based on business objectives

� Supported by� Key technique : Timeboxing� Constant review� Planning products

� Management Foundations and Timebox Plans

Agile Project Management�Different style of management (compared to traditional)

� Enabling constant change during elaboration of the detail � Continuously correcting course � Maintaining aim on target (delivering a usable solution on a fixed date)

�Monitoring progress in a different way� Measured by delivery of products (not by activity)� Measured by delivery of products (not by activity)� Sustaining the high rate of progress throughout

�Targeting and motivating empowered teams (Not directing them)� Collaboration requires a no-blame culture � Building culture of team success/failure

Tightly Managed Teams Self Directed Teams (Agile)

Take directions Take initiative

Seek individual reward Focus on team contributions

Focus on low-level objectives Concentrate on solutions

Agile – Management Style

Focus on low-level objectives Concentrate on solutions

Compete Co-operate

Comply with processes, regardless of outcome

Continuously look for better ways of working

React to emergencies Take steps to prevent emergencies

The Development Framework

20

MoSCoW Prioritization

21

Minimum Useable SubseT

Work arounds difficult/costly

Work arounds easy/cheap

Must Have

Should Have

Could Have

Guaranteed

Expected

Possibly

No more than 60% effort

@ 20% effort

@ 20% effortWork arounds easy/cheap

Out of Scope for this timeframe

Requirements that cannot be de-scoped without causing the project to fail

Requirements that can be de-scoped as a last resort to keep the project on track

Requirements that can be de-scoped without causing significant problems

Could Have

Won’t have this time

Possibly

Maybe next time

@ 20% effort

Delivering the Business Case

22

Timeboxing2-4 (exceptionally 6) weeks

60-80%10-20% 10-20%

Investigation Refinement Consolidation

• Timebox supported by– Daily stand-ups

• Communication and control– Reviews

• On-going acceptance and risk reductions

� Created by the Team� MoSCoW for this Timebox� Milestone dates

� e.g.. Planned Review sessions� Roles and Responsibilities� Deliverables (with acceptance criteria)

Timeboxing - Iterations

Sign-off whathas beendelivered.

Assess impactof what has not

been “done”

Agree TimeboxScope andMoSCoWpriorities 60-80%

effort10-20% effort

10-20% effort

Investigation Refinement Consolidation

Investigate detail of work

to be done

Work on the Solution in

line with agreedMoSCoW priorities

Finish off, ensuringoverall outputof Timebox isfit for purpose

Timeboxing - Iterations

�For each iteration (Investigate, Refine, Consolidate) within a Timebox Identify what has to

be donein this iteration

Agree informalplan for how this will Review the solution withplan for how this willbe achieved in this

iteration

Evolve solution asappropriate with detailed

input from Business Ambassador

Review the solution withBusiness Ambassador

(and others?)

Consolidation ReviewRefinement ReviewInvestigation Review

Timeboxing - Iterations

Review Review Review

Consolidation Review• Share final results of

Timebox with Ambassador, Visionary (probably), and Technical Coordinator

• Confirm deliverables are fit for their intended purpose (i.e.. meet agreed acceptance criteria)

Refinement Review• Team share results

so far with Ambassador, Visionary (possibly)and Technical Coordinator

• Agree and prioritise workto be completed by end ofTimebox

• Team share resultsof their investigation withAmbassador, Visionary (possibly) and Technical Coordinator

• Team validate what they areintending to deliver by end of Timebox

Timeboxing – Provides Control

Deploy Deploy

• Control is applied at the detail level – this Development Timebox• Control is applied at the detail level – this Development Timebox– Delivering on time every time

• If this Timebox is on time, the Increment (and Project) are on time

Integration with ITIL®

Fragen?