Running successful agile projects

Hi, I’m Martin Aspeli. You may know me from such Plone Conference talks as …. “Design and Development with Dexterity” “Extending and “Tools and techniques for a successful “Coding for 2.1” customising Plone 3” Plone project” 2005 2006 2007 2008 2009 2010 2011 “Creating content types “Simplifying Plone” “State of the three D’s” the Plone 2.5 way” © 2011 Deloitte MCS Limited. Private and confidential.

Customers “If I'd asked my customers what don’t know they wanted, they'd what they want have said a faster at the start of a horse. ” project Henry Ford © 2011 Deloitte MCS Limited. Private and confidential.

An empirical vs. a defined process Software development is as much an art as a science, with low task repetition and much uncertainty Empirical Process Defined Process V Lean / Agile Waterfall Daily Stand Up Requirements Validation 4 Week Iteration Project Wrap-up & Design 11 © 2011 Deloitte MCS Limited. Private and confidential.

The aims of Agile methods Deliver business value regularly and incrementally Provide visibility to the business throughout the project Reduce delivery risk steadily throughout the project Maintain adaptability to business change as long as possible Linear, ‘waterfall’ methods Agile methods © 2011 Deloitte MCS Limited. Private and confidential.

Your strategic objectives • Will the project make you money? • Will it give you a credential for the future that’s worth taking a risk for? • Will it open up a new client? • Will you learn something new? 15 © 2011 Deloitte MCS Limited. Private and confidential.

Why is it always fixed price? Imagine you are middle management at a medium-to-large size company Problem: • Meet your budget • Deliver on time • Make the business happy Solution: Put all the risk on the supplier 18 © 2011 Deloitte MCS Limited. Private and confidential.

How to deal with fixed price/fixed scope • Estimate well • Put the baseline scope in the contract • Add a risk premium of 10-25% (see ‘Dark Matter’ later) • Establish a fair and efficient change control process • Allow ‘one-in-one-out’ change for free, but track it 20 © 2011 Deloitte MCS Limited. Private and confidential.

Variable scope • The problem with ‘fixed price’ isn’t fixing the price… • … it’s fixing the scope • A better question: How much value can you deliver for how much money? • Fixed price for fixed capacity: “We will work with you to prioritise the scope, and work through it in priority order. You can change priorities on anything we haven’t started yet. Hence, we will give you the best value we can deliver for $xx in total” 21 © 2011 Deloitte MCS Limited. Private and confidential.

Time-and-materials • Theoretically the most efficient contract structure • Good if there is significant trust and a track record • Needs mature risk and change management on both sides • There is always a budget somewhere! 22 © 2011 Deloitte MCS Limited. Private and confidential.

Fixed time box • Combination of the above • “We work in time boxed iterations of 2 weeks. Each iteration costs $xx. We will prioritise the scope and work through it in order. At the end of each iteration, we will deliver ‘shippable’ functionality. You can terminate the project by giving one full iteration’s notice” • Gives you some certainty and control • Gives the client some certainty and control 23 © 2011 Deloitte MCS Limited. Private and confidential.

Our methodology framework … is based on core values, disciplines and activities Evaluate environment Iterative delivery (2-4 weeks) Requirements Post implementation and define process Core activities validation Release planning Iteration review Design Architecture definition Iteration planning Development Deployment Testing Business analysis Acceptance Continuous delivery Core disciplines Planning Requirements management Quality assurance Change management Risk management Core values Focus on Quality in business everything Simplicity Collaboration Feedback Commitment Visibility value we do 25 © 2011 Deloitte MCS Limited. Private and confidential.

Method overview Our most commonly used method is based on Scrum™, with additional elements tailored to a professional services environment Phases Iterative Phase 2-4 Weeks Iteration Zero Design Iteration Review Project Preparation Working Planning wrap up Produce Software Build Produce Initial Backlog Update Project Project Review Business & Backlog & Case Release Plan Test & Training & & Review Agree Iteration & Vision Executable Process Backlog Support Architecture Deploy Daily Artifacts Stand-up Roles Project & Iteration Backlog Product Owner Impediments List Project Manager Project, Release & Iteration burn-down Team Working Software Stakeholders Users 26 © 2011 Deloitte MCS Limited. Private and confidential.

Requirement lifecycle Each user story goes through a defined lifecycle that includes the definition of detailed acceptance criteria, and quality assurance once it has been built. Prioritise Define Sign off Build and Technical and acceptance acceptance Deploy test and BA QA schedule criteria criteria Requirements decision matrix Acceptance criteria Given a login page When I enter my username and password correctly Clarify Implement Then I am logged in Given a login page Priority When I enter an incorrect username and password Then I am shown an error message Park Wait Given a login page .... Clarity 27 © 2011 Deloitte MCS Limited. Private and confidential.

Release process ‘Big Bang’ releases carry too much risk too late into the project. Smaller, incremental releases reduce risk and improve visibility and feedback. One or more sequential iterations in a release Release 1 Iteration 1 Release Release Release Review Iteration Iteration Release 2 n Planning Iteration 2 n Review Implementation Working Planning Software One or more sequential releases in a project 28 © 2011 Deloitte MCS Limited. Private and confidential.

Flow of work (Kanban) The lightweight method defines key events such as iteration meetings and daily stand-ups. Within (or across) the iteration, work flows through a process that will differ between teams. This can be visualised with a kanban board. Work in progress limits enable a pull system of work allocation Project Iteration In Dev (8) QA (4) Done Backlog Backlog (10) Slack capacity is key to The board continuous visualises improveme work and nt bottlenecks / slack Capacity can be based on work item types (e.g. features vs. bugs) 29 © 2011 Deloitte MCS Limited. Private and confidential.

Are we being Agile? Agile Decision Filter (David J Anderson) 1. Are we making progress with imperfect information vs. delaying in order to get more perfect information? 2. Are we encouraging a high trust culture? 3. Do we treat unfinished work (WIP) as a liability and not an asset? It helps to understand the cost of delay: The longer we wait to build something, the longer we have to wait to realise its value. 30 © 2011 Deloitte MCS Limited. Private and confidential.

A typical project plan Ready to build Working software Project complete Mobilisation Iterative Delivery Handover 2-6 weeks 2-4 weeks x N 2-6 weeks Iteration +1 Iteration planning Factory testing Iteration review pre-planning Daily stand-up meetings Daily risk/issue calls 31 © 2011 Deloitte MCS Limited. Private and confidential.

Things to track e.g. in JIRA, Trac, … Item type Description Reporting Developer Defect A bug discovered in testing by the client Defect list or a third party, i.e. after code released Cumulative Flow Diagram from the factory. User story A requirement in scope. Kept in priority Burndown chart (Requirement) order, and fleshed out with detailed Cumulative Flow Diagram acceptance criteria just in time. Epic High level area of scope. Useful for Release plan release planning. Clarification A question outstanding linked to a Dashboard with due dates requirement. Dependency A dependency on the client with a due Dashboard with due dates date, required to complete build. Risk A project risk, including probability and Dashboard in priority order impact. Daily calls Issue A live project issue, e.g. a development Dashboard in priority order Manager impediment. Daily calls Change A discussed or agreed change in project Dashboard in priority order scope. Daily calls 32 © 2011 Deloitte MCS Limited. Private and confidential.

Estimating user stories Estimating the effort involved in a user story is done by the team that will be committing to delivering it, and only that team. Estimates should be based on size and complexity, not duration, and must be shared by the team. Story points Story points are a relative measure of the size (or complexity) of a story. A user story estimated at 10 story points will take twice as long as one estimated at 5. Ideal time Ideal time is the time it would take to complete a task should there be no interruptions. A football match lasts 90 ideal minutes but the elapsed time it takes is more like 120 minutes. Three techniques can be used to derive an estimate: ‒ Expert opinion ‒ Analogy ‒ Divide-and-conquer 34 © 2011 Deloitte MCS Limited. Private and confidential.

Prioritising user stories … is the primary responsibility of the Product Owner. Others can provide guidance and support, but the decision rests with him or her. Factors to consider • The business value of having the story • The cost of developing the story • The amount of knowledge and understanding of the system and future requirements that will be gained from implementing the story • Dependencies • The amount of risk removed by implementing the story 35 © 2011 Deloitte MCS Limited. Private and confidential.

Planning … is an on-going process. Planning far in future is kept general and planning for the near future is detailed. There are three types of planning involved in an agile process: Release Planning • A release is made up of a number of iterations • Can include themes and epics • Buffer for time, features or both Iteration Planning • An iteration last between 2 and 4 weeks • Themes and epics must be broken down • User stories which are selected for the iteration are broken into tasks Daily Planning • Daily 15 minute stand-up • Focused on tasks and impediments 36 © 2011 Deloitte MCS Limited. Private and confidential.

Velocity Measuring the speed of the team “Number of story points delivered by the team in a complete iteration” It is a fallacy to measure ‘individual’ velocity or ‘day’ velocity. It is also dangerous to try to calculate a ‘points-to-days’ multiplier – it will be ~ 20% wrong at least, and so should not be used for individual items. 37 © 2011 Deloitte MCS Limited. Private and confidential.

Burn-down Measuring progress against the backlog over time A Burn Down Chart is used to show work done against time. It lets all those involved in the project quickly see the progress of the team and allows a trend (velocity) to be identified so completion date can be estimated. Example burn-down chart Project Burndow n Chart 700 600 Effort Points 500 400 Original + Replanning + Change 300 Original + Replanning 200 100 0 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 4/ 4/ 4/ 5/ 5/ 6/ 6/ 7/ 7/ 8/ 8/ 9/ 9/ 0/ 0/ 0/ 1/ /0 /0 /0 /0 /0 /0 /0 /0 /0 /0 /0 /0 /0 /1 /1 /1 /1 02 16 30 14 28 11 25 09 23 06 20 03 17 01 15 29 12 Date 38 © 2011 Deloitte MCS Limited. Private and confidential.

Cumulative Flow Identifying bottlenecks and reviewing work-in-progress When using Kanban to track flow, we 100 can analyse how the distribution of 90 work-in-progress across different states 80 Number of stories change over time using a Cumulative 70 WIP Flow diagram. This plots the number of 60 items in each state as a stacked area 50 chart, either for the duration of the 40 Mean cycle time project, or for one iteration. 30 20 10 0 Where there are sudden significant 1 2 3 4 5 6 7 8 9 10 changes in the number of items in one Week state, a bottleneck may be developing. Done In progress To do We can identify the mean cycle time by measuring horizontal lines from the start state to the end state 39 © 2011 Deloitte MCS Limited. Private and confidential.

Throughput forecast In complex projects, activity-level planning is too difficult and often counter- productive. Throughput forecasting is more accurate and much easier. • Break work down into similarly- 100 sized, independently schedulable 90 80 chunks (e.g. user stories) Number of stories 70 • Track moving average rate of 60 completion (e.g. from detailed 50 analysis/design to completed work) 40 30 • Use this to forecast future 20 performance 10 • Estimation is waste! Historical data 0 1 2 3 4 5 6 7 8 9 10 is more accurate and takes less Week time away from value-adding work. Done In progress To do • Ideally, only estimate for items that Moving average throughput have a true fixed delivery date to know when they must be started. 40 © 2011 Deloitte MCS Limited. Private and confidential.

Little’s Law We can discover how much parallelisation (WIP) we need by using Little’s Law How many things we need to do in parallel. For efficiency, we want this to be small relative to number of people, hence this is relative to team size Work-in-Progress (WIP) Average Throughput = Average lead time Target to achieve the plan Observed capability: treat as a constant. Can be improved only over time, or by changing the process/system. 41 © 2011 Deloitte MCS Limited. Private and confidential.

S-curve Throughput is normally lower at the beginning and end of a project. We can simulate the “S”-curve effect with a “Z” for estimation purposes. 100 90 Last 20% 80 70 60 50 Middle 60%: 3.5 – 5x throughput 40 30 20 First 20% 10 0 1 2 3 4 5 6 7 8 9 10 Done In progress To do 42 © 2011 Deloitte MCS Limited. Private and confidential.

Dark matter Scope is never fully understood up front. We have a “known unknown” quantity of additional scope that will come in during the project. Dark matter (20-50%): Stories were Original scope reduced (e.g. over- Scope creep: Agreed new scope, underestimated, or are now recognised as estimated) subject to change request. epics. Client does not consider this to be new scope. 140 120 100 Number of stories 80 60 40 20 0 1 2 3 4 5 6 7 8 9 10 Week Original scope Dark matter Scope creep 43 © 2011 Deloitte MCS Limited. Private and confidential.

Comparing project profitability • How many hours did the team put in vs. what you could you charge (invoice schedule, agreed rate card, day rate vs. hourly rate…) • Compare actual rate to theoretical maximum, i.e. if full rates were charged for all hours worked • Absolute number doesn’t matter (much), but comparison among projects do! 45 © 2011 Deloitte MCS Limited. Private and confidential.

Some interesting things to read • Various books on Scrum • User Stories Applied (Mike Cohn) • Agile Estimating and Planning (Mike Cohn) • Kanban (David J Anderson) • Lean Startup (Eric Ries) 47 © 2011 Deloitte MCS Limited. Private and confidential.

This is an internal document which provides confidential advice and guidance to partners and staff of Deloitte MCS Limited. It is not to be copied or made available to any other party. © 2011 Deloitte MCS Limited. All rights reserved. Member of Deloitte Touche Tohmatsu Limited © 2011 Deloitte MCS Limited. Private and confidential.

Running successful agile projects

In this document

More Related Content

What's hot

Viewers also liked

Similar to Running successful agile projects

Recently uploaded

Running successful agile projects