Running successful agile projects

5,302 views
2,756 views

Published on

Talk from Plone Conference 2012 in Arnhem, the Netherlands

Published in: Business
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,302
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
0
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Running successful agile projects

  1. Running successful Agile projects © 2011 Deloitte MCS Limited. Private and confidential.
  2. Hi, I’m Martin Aspeli. You may know me from such PloneConference 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.
  3. Software development is hard3 © 2010 Deloitte MCS Limited. Private and confidential
  4. Customers “If Id asked my customers whatdon’t know they wanted, theydwhat they want have said a fasterat the start of a horse. ”project Henry Ford © 2011 Deloitte MCS Limited. Private and confidential.
  5. Developers don’t knowhow to build it at thestart © 2011 Deloitte MCS Limited. Private and confidential.
  6. ThingsChange © 2011 Deloitte MCS Limited. Private and confidential.
  7. It’s hardwork © 2011 Deloitte MCS Limited. Private and confidential.
  8. People donot like badnews © 2011 Deloitte MCS Limited. Private and confidential.
  9. Agile methods address these challenges9 © 2010 Deloitte MCS Limited. Private and confidential
  10. © 2011 Deloitte MCS Limited. Private and confidential.
  11. An empirical vs. a defined processSoftware development is as much an art as a science, with low taskrepetition and much uncertainty Empirical Process Defined Process V Lean / Agile Waterfall Daily Stand Up Requirements Validation 4 Week Iteration Project Wrap-up & Design11 © 2011 Deloitte MCS Limited. Private and confidential.
  12. 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.
  13. 1. The right project13 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.
  14. Your core strengths• Is this something you are good at?• What is your ‘sell’ to the client?14 © 2011 Deloitte MCS Limited. Private and confidential.
  15. 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.
  16. The right size clientIf: • Size of client > 10 x size of supplier? • Size of supplier > 10 x size of client?Think twice!16 © 2011 Deloitte MCS Limited. Private and confidential.
  17. 2. The right contract17 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.
  18. Why is it always fixed price?Imagine you are middle management ata medium-to-large size companyProblem: • Meet your budget • Deliver on time • Make the business happySolution: Put all the risk on the supplier18 © 2011 Deloitte MCS Limited. Private and confidential.
  19. The iron quadranglePick any three… Scope Time Cost Quality19 © 2011 Deloitte MCS Limited. Private and confidential.
  20. 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 it20 © 2011 Deloitte MCS Limited. Private and confidential.
  21. 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.
  22. 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.
  23. 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 control23 © 2011 Deloitte MCS Limited. Private and confidential.
  24. 3. The right method24 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.
  25. 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 do25 © 2011 Deloitte MCS Limited. Private and confidential.
  26. Method overviewOur most commonly used method is based on Scrum™, with additionalelements 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 Users26 © 2011 Deloitte MCS Limited. Private and confidential.
  27. 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 pagePriority 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.
  28. 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 releaseRelease 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 project28 © 2011 Deloitte MCS Limited. Private and confidential.
  29. 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 ntbottlenecks / slack Capacity can be based on work item types (e.g. features vs. bugs) 29 © 2011 Deloitte MCS Limited. Private and confidential.
  30. 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, thelonger we have to wait to realise its value.30 © 2011 Deloitte MCS Limited. Private and confidential.
  31. 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 calls31 © 2011 Deloitte MCS Limited. Private and confidential.
  32. Things to track e.g. in JIRA, Trac, … Item type Description ReportingDeveloper 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 orderManager 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.
  33. 5. The right metrics33 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.
  34. Estimating user storiesEstimating the effort involved in a user story is done by the team that willbe committing to delivering it, and only that team. Estimates should bebased on size and complexity, not duration, and must be shared by theteam. 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-conquer34 © 2011 Deloitte MCS Limited. Private and confidential.
  35. Prioritising user stories… is the primary responsibility of the Product Owner. Others can provideguidance 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 story35 © 2011 Deloitte MCS Limited. Private and confidential.
  36. Planning… is an on-going process. Planning far in future is kept general andplanning for the near future is detailed. There are three types of planninginvolved 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 impediments36 © 2011 Deloitte MCS Limited. Private and confidential.
  37. VelocityMeasuring 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 totry to calculate a ‘points-to-days’ multiplier – it will be ~ 20% wrong at least, and soshould not be used for individual items.37 © 2011 Deloitte MCS Limited. Private and confidential.
  38. Burn-downMeasuring progress against the backlog over timeA Burn Down Chart is used to show work done against time. It lets all thoseinvolved 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 Date38 © 2011 Deloitte MCS Limited. Private and confidential.
  39. Cumulative FlowIdentifying bottlenecks and reviewing work-in-progressWhen using Kanban to track flow, we 100can analyse how the distribution of 90work-in-progress across different states 80 Number of storieschange over time using a Cumulative 70 WIPFlow diagram. This plots the number of 60items in each state as a stacked area 50chart, either for the duration of the 40 Mean cycle timeproject, or for one iteration. 30 20 10 0Where there are sudden significant 1 2 3 4 5 6 7 8 9 10changes in the number of items in one Weekstate, a bottleneck may be developing. Done In progress To doWe can identify the mean cycle time bymeasuring horizontal lines from thestart state to the end state39 © 2011 Deloitte MCS Limited. Private and confidential.
  40. Throughput forecastIn 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.
  41. Little’s LawWe can discover how much parallelisation (WIP) we need by using Little’sLaw 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 timeTarget 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.
  42. S-curveThroughput is normally lower at the beginning and end of a project. Wecan 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 do42 © 2011 Deloitte MCS Limited. Private and confidential.
  43. Dark matterScope 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 creep43 © 2011 Deloitte MCS Limited. Private and confidential.
  44. Reporting true progressPassing tests that meet client’s acceptance criteria = true progress http://corejet.org44 © 2011 Deloitte MCS Limited. Private and confidential.
  45. 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.
  46. Further reading46 Presentation title © 2011 Deloitte MCS Limited. Private and confidential.
  47. 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.
  48. 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 madeavailable to any other party.© 2011 Deloitte MCS Limited. All rights reserved.Member of Deloitte Touche Tohmatsu Limited © 2011 Deloitte MCS Limited. Private and confidential.

×