Agile / Lean Estimating and / Lean Estimating and Planning ... Lean Principles ... (This is the best reference for Lean software development.) ILTA, ...

Download Agile / Lean Estimating and   / Lean Estimating and Planning ... Lean Principles ... (This is the best reference for Lean software development.) ILTA, ...

Post on 17-May-2018




0 download


ILTA, August 2008Debevoise & Plimpton LLP 1Agile / LeanEstimating and PlanningAlina Hsuahsu@debevoise.comManager of Architecture & DevelopmentDebevoise & Plimpton LLPILTA, August 2008Debevoise & Plimpton LLP 2AGENDA Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A References Appendix: Estimating and Planning in DetailDebevoise & Plimpton LLP 3Introduction Familiarity with Agile? Details in this presentation do not correspond to any specific flavor of Agile Closest to Lean, but reflects Debevoise firm culture and constraints, and what we found to be workable Feel free to ask questions as we goILTA, August 2008Debevoise & Plimpton LLP 2Debevoise & Plimpton LLP 4AGENDA Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A References Appendix: Estimating and Planning in DetailDebevoise & Plimpton LLP 5Agile & Lean Agile, Scrum, XP: sets of practices for software development, based on Lean principles. Lean: general principles, which provide a basis for judging what is appropriate for a given situation, and for designing and improving your own practices. Not just for software development can be applied to any kind of project. Debevoise & Plimpton LLP 6Benefits of Lean Approach Reduced risk Improved quality, reduced cost and/or time Greater value delivered, and more predictably Higher client satisfaction: short feedback cycles build trust, collaborative spirit Iterative delivery and explicit risk management lead to project successILTA, August 2008Debevoise & Plimpton LLP 3Debevoise & Plimpton LLP 7Lean Software Development Controls risk by breaking a project into small chunks of business value giving users working software early and often continuous integration & testing Focuses on exactly the work needed to deliver the chunks in scope for a given iterationDebevoise & Plimpton LLP 8Why is Lean Better?Front-load risk via baseline architecture to test these unknownsTechnology unknownsContinuous integrationIntegration testing raises issues late in project, when they are costlyClosely tracks, confirms user needs via working software & feedbackFlawed requirementsLean SDLCWaterfall SDLCDebevoise & Plimpton LLP 9AGENDA Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A References Appendix: Estimating and Planning in DetailILTA, August 2008Debevoise & Plimpton LLP 4Debevoise & Plimpton LLP 10Example: a Lean ProjectVery highRisk Level*Must deliver beta in 2 months*ConstraintImprove the process so that we can do 20 analyses in 2 weeksGoalFirm ManagementSponsora single analysis takes 2 weeksProblemcomplex financial analysis, a largely manual workflowProjectDebevoise & Plimpton LLP 11Project RoadmapDebevoise & Plimpton LLP 12Our Lean Approach Deliver the maximal business value as quickly as possible. Repeat for each iteration. For this financial analysis workflow, we decided to use BizTalk to build a shell workflow, then iteratively add content. At some future point, we will implement a data warehouse to support this business process, but we could not do that in two months. Throughout the project, Accounting analysts were defining the calculations on a just-in-time basis. ILTA, August 2008Debevoise & Plimpton LLP 5Debevoise & Plimpton LLP 13User Stories User stories are the basis of Agile or Lean estimating and planning. User stories are small chunks of work of the form: As a [business role] I can [do something] so that [goal]. They inherently deliver some business value, because the actor - [business role] - accomplishes something. We used a looser syntax. Debevoise & Plimpton LLP 14User Stories We used other small chunks of infrastructure work. We could have translated these into user stories, but found we did not need to. In this project, our user stories focus on the process steps which are time-consuming and labor-intensive for the Accounting personnel who produce this analysis.Debevoise & Plimpton LLP 15Iteration 1ILTA, August 2008Debevoise & Plimpton LLP 6Debevoise & Plimpton LLP 16Baseline ArchitectureDebevoise & Plimpton LLP 17Iteration 1Debevoise & Plimpton LLP 18Iteration 2ILTA, August 2008Debevoise & Plimpton LLP 7Debevoise & Plimpton LLP 19Iteration 2Debevoise & Plimpton LLP 20Iteration 3Debevoise & Plimpton LLP 21Iteration 4ILTA, August 2008Debevoise & Plimpton LLP 8Debevoise & Plimpton LLP 22Iteration 5Debevoise & Plimpton LLP 23Iterations 2 to n-1Debevoise & Plimpton LLP 24User story: WorkflowILTA, August 2008Debevoise & Plimpton LLP 9Debevoise & Plimpton LLP 25Final Iteration - DeploymentDebevoise & Plimpton LLP 26Planning Overview Project envisioning Business value, goals, budget, critical use cases or epics Project roadmap very high level Release planning high level Iteration planning detailed Weekly planning (if iterations are longer than 2 weeks) Daily stand-up (or every other day)Debevoise & Plimpton LLP 27AGENDA Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A References Appendix: Estimating and Planning in DetailILTA, August 2008Debevoise & Plimpton LLP 10Debevoise & Plimpton LLP 28What is Lean? Originally, the Toyota Production System (manufacturing) Later generalized to product design, supply chain, call center, back office processes Basic idea is to deliver maximal value every [time unit], build quality in, and eliminate waste.Debevoise & Plimpton LLP 29Lean Principles Optimize the whole: value delivered Practically everything else can be derived from this Only 20% of features are used always or frequently try to identify these and deploy them first. Front-load risk Baseline Architecture, specifically designed to test risky aspects of technology People risks: executive decisions needed, communication issues, resource conflicts Short feedback cycles Debevoise & Plimpton LLP 30Short Feedback CyclesILTA, August 2008Debevoise & Plimpton LLP 11Debevoise & Plimpton LLP 31Lean Principles Big Picture Up Front Baseline architecture Project roadmap Epics, Use cases, big chunks for scoping Also applies recursively at more granular levels Detail Just-In-TimeDebevoise & Plimpton LLP 32ROADMAP - genericDebevoise & Plimpton LLP 33Lean Principles Eliminate waste Partly completed work Work not needed yet Rework Waiting time Multitasking Extra featuresILTA, August 2008Debevoise & Plimpton LLP 12Debevoise & Plimpton LLP 34Lean Principles Build quality in Error-proofing Design patterns Automation Collaboration Continuous improvementDebevoise & Plimpton LLP 35Essential Elements Timebox everything Commitment to honor timeboxes Iterative delivery; small chunks of work within an iteration Real-time issue management; frequent stand-up meetings Collaborative workshopsDebevoise & Plimpton LLP 36Essential Elements Front-load risk Big Picture Up Front, Detail Just-In-Time: just-enough, just-in-time work Modular, layered architecture Unit testing, Continuous integration Dedicated team (at least 50%)ILTA, August 2008Debevoise & Plimpton LLP 13Debevoise & Plimpton LLP 37Less Formal, More Rigorous Lean is less formal, in that substance matters more than form Lean is more rigorous, in that all work is focused on delivering business value early and often. Productivity is consistently but sustainably high. Debevoise & Plimpton LLP 38AGENDA Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A References Appendix: Estimating and Planning in DetailDebevoise & Plimpton LLP 39Conclusion Both Agile and Lean approaches have a good track record, widespread adoption Obstacles to adoption are Changes in roles and ways of working Perceived risk though the waterfall SDLC is known to be prone to failure, and Lean actually reduces risk Need to adopt a coherent set of practices, hard to adopt just one or twoILTA, August 2008Debevoise & Plimpton LLP 14Debevoise & Plimpton LLP 40Conclusion Bare bones introduction see References and Appendix for more detail Could Debevoise be more Lean? Yes, we are just beginning. We will use continuous improvement tools & techniques to guide our evolution. We are also beginning to apply Lean principles to IT services other than project workDebevoise & Plimpton LLP 41AGENDA Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A References Appendix: Estimating and Planning in DetailDebevoise & Plimpton LLP 42References Beck, Kent (with Cynthia Andres), Extreme Programming Explained, Second Edition, Addison-Wesley, 2005. Cohn, Mike, Agile Estimating and Planning, Prentice Hall, 2006. Cohn, Mike, User Stories Applied, Addison-Wesley, 2004. Poppendieck, Mary and Poppendieck, Tom, Implementing Lean Software Development: from Concept to Cash, Addison-Wesley, 2006. (This is the best reference for Lean software development.)ILTA, August 2008Debevoise & Plimpton LLP 15Debevoise & Plimpton LLP 43References Schwaber, Ken and Beedle, Mike, Agile Software Development with Scrum, Prentice-Hall, 2001. Smits, Hubert, 5 Levels of Agile Planning: From Enterprise Product vision to Team Stand-up, Rally software Development Corp., 2006 Tabaka, Jean, Collaboration Explained: Facilitation Skills for Software Project Leaders, Addison-Wesley, 2006. (Excellent guide to running collaborative workshops. Highly recommended. Workshops are a good tool regardless of whether you adopt any form of Agile or Lean.)Debevoise & Plimpton LLP 44References Womack, James P. and Jones, Daniel T., Lean Thinking, Simon & Schuster, 1996; Second Edition, Free Press, 2003. (General reference on the Lean approach) Scott Amblers family of websites gives lots of detail about Agile modeling, architecture, database practices, and documentation. for the history of Agile and the original Agile Manifesto. Leandevelopment group @ Yahoo groupsDebevoise & Plimpton LLP 45AGENDA Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A References Appendix: Estimating and Planning in DetailILTA, August 2008Debevoise & Plimpton LLP 16Debevoise & Plimpton LLP 46Estimation Small Chunks The most critical factor here is defining small chunks of work that are rich in the value they deliver Examples: user stories, features, decisions ideally 2 to 4 effort-days Small chunks of work are easier to estimate, permit self-organization of team, reduce complexity and riskDebevoise & Plimpton LLP 47Estimation Small Chunks Analysis, design, coding, testing all happen concurrently for a single user story User stories by definition enable users to do something useful this is the basis of business valueDebevoise & Plimpton LLP 48Estimation Process Assign crude effort estimates to user stories T-shirt sizes Planning poker Story points Have business stakeholders prioritize chunks based on business value Estimate effort for top 5 or 6 chunks, taking into account business value, risk, dependenciesILTA, August 2008Debevoise & Plimpton LLP 17Debevoise & Plimpton LLP 49Estimation Process Effort Duration Convert estimates to timeboxes with very little slack dedicated team members will not have competing demands on their time Adjust timeboxes if needed so that all team members can confirm that they are 90% certain of being able to deliver on timeDebevoise & Plimpton LLP 50Estimation - Comments Recommend estimating in ideal days Ensure estimates are appropriate relative to existing estimates If scale of estimation is off, can use a multiplier to adjust remaining estimatesDebevoise & Plimpton LLP 51ROADMAP - genericILTA, August 2008Debevoise & Plimpton LLP 18Debevoise & Plimpton LLP 52Planning Charter Starting with project vision, have business owner define budget We budget in terms of iterations and standard resource units. One standard resource for a software development project = .5 fte PM, .8 fte BA, .6 fte Developer, and a mix of other resources based on historical data for this kind of project. At charter, effort estimate is crudeDebevoise & Plimpton LLP 53Planning Initiation The budget will serve as a timebox for the overall project. Identify project risks: new or unproven software, middleware or server technologies; executive policy decisions needed; communication issues; resource conflicts; Design architecture to eliminate dependencies; identify any dependencies remaining; plan accordinglyDebevoise & Plimpton LLP 54Planning High Level Iteration 1 addresses and resolves the highest risks, because these can be very costly to deal with later in the project Then we consider the highest-business-value use case or epic, and figure out what working software we could deliver after 4 weeks (Iteration 2).ILTA, August 2008Debevoise & Plimpton LLP 19Debevoise & Plimpton LLP 55Planning High Level We rough out how many more iterations it would take to deliver that use case, and repeat for the remaining critical use cases. Working backwards from the endpoint, we have to allow for deployment to production: finalizing all documentation, training and handing off to support staff, completion of the production environment, and the actual deployment.Debevoise & Plimpton LLP 56Planning High Level Prior to that, we need to allow for a final deployment to staging and final UAT. Checkpoint: does the work needed exceed the number of iterations that were budgeted? If so, negotiate with business: add more iterations, cut scope, or kill project. Debevoise & Plimpton LLP 57Release Planning The business owners identify the user stories that constitute the chosen epic or use case. The business owners prioritize the user stories in terms of business value After estimating effort and timeboxing the most valuable user stories, calculate how many fit into each iteration and how many iterations will be needed. ILTA, August 2008Debevoise & Plimpton LLP 20Debevoise & Plimpton LLP 58Planning - Iteration 1 - Baseline Iteration 1: High-level design alternatives Baseline architecture: experiment with, prove technology, architecture, high-level design Mitigate people risks Build spanning application: a shell or skeleton which permits continuous integration Perhaps 1 or 2 user stories Confirm or renegotiate project roadmapDebevoise & Plimpton LLP 59Planning Iterations 2 to n-1 At delivery of prior iterations work product, identify next set of user stories Estimate effort, set timeboxes Decide which user stories will be included NOTE: if the project is not new software development, if it consists of enhancements to existing software, the work of Iteration 1 can usually be collapsed to a day or two in Iteration 2. Debevoise & Plimpton LLP 60Iteration n the final iteration Finalize documentation Train and hand off to support staff Finalize production environment Submit change control documentation, get approval Deploy to production User acceptance


View more >