ITIL® & Agile
ITIL® & Agile
Matthias [email protected]
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?