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

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • ILTA, August 2008

    Debevoise & Plimpton LLP 1

    Agile / LeanEstimating and Planning

    Alina Hsuahsu@debevoise.com

    Manager of Architecture & DevelopmentDebevoise & Plimpton LLP

    ILTA, August 2008

    Debevoise & Plimpton LLP 2

    AGENDA

    Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A

    References Appendix: Estimating

    and Planning in Detail

    Debevoise & Plimpton LLP 3

    Introduction

    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 go

  • ILTA, August 2008

    Debevoise & Plimpton LLP 2

    Debevoise & Plimpton LLP 4

    AGENDA

    Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A

    References Appendix: Estimating

    and Planning in Detail

    Debevoise & Plimpton LLP 5

    Agile & 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 6

    Benefits 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 success

  • ILTA, August 2008

    Debevoise & Plimpton LLP 3

    Debevoise & Plimpton LLP 7

    Lean 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 iteration

    Debevoise & Plimpton LLP 8

    Why is Lean Better?

    Front-load risk via baseline architecture to test these unknowns

    Technology unknowns

    Continuous integrationIntegration testing raises issues late in project, when they are costly

    Closely tracks, confirms user needs via working software & feedback

    Flawed requirements

    Lean SDLCWaterfall SDLC

    Debevoise & Plimpton LLP 9

    AGENDA

    Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A

    References Appendix: Estimating

    and Planning in Detail

  • ILTA, August 2008

    Debevoise & Plimpton LLP 4

    Debevoise & Plimpton LLP 10

    Example: a Lean Project

    Very highRisk Level

    *Must deliver beta in 2 months*Constraint

    Improve the process so that we can do 20 analyses in 2 weeks

    Goal

    Firm ManagementSponsor

    a single analysis takes 2 weeksProblem

    complex financial analysis, a largely manual workflow

    Project

    Debevoise & Plimpton LLP 11

    Project Roadmap

    Debevoise & Plimpton LLP 12

    Our 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 2008

    Debevoise & Plimpton LLP 5

    Debevoise & Plimpton LLP 13

    User 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 14

    User 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 15

    Iteration 1

  • ILTA, August 2008

    Debevoise & Plimpton LLP 6

    Debevoise & Plimpton LLP 16

    Baseline Architecture

    Debevoise & Plimpton LLP 17

    Iteration 1

    Debevoise & Plimpton LLP 18

    Iteration 2

  • ILTA, August 2008

    Debevoise & Plimpton LLP 7

    Debevoise & Plimpton LLP 19

    Iteration 2

    Debevoise & Plimpton LLP 20

    Iteration 3

    Debevoise & Plimpton LLP 21

    Iteration 4

  • ILTA, August 2008

    Debevoise & Plimpton LLP 8

    Debevoise & Plimpton LLP 22

    Iteration 5

    Debevoise & Plimpton LLP 23

    Iterations 2 to n-1

    Debevoise & Plimpton LLP 24

    User story: Workflow

  • ILTA, August 2008

    Debevoise & Plimpton LLP 9

    Debevoise & Plimpton LLP 25

    Final Iteration - Deployment

    Debevoise & Plimpton LLP 26

    Planning 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 27

    AGENDA

    Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A

    References Appendix: Estimating

    and Planning in Detail

  • ILTA, August 2008

    Debevoise & Plimpton LLP 10

    Debevoise & Plimpton LLP 28

    What 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 29

    Lean 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 30

    Short Feedback Cycles

  • ILTA, August 2008

    Debevoise & Plimpton LLP 11

    Debevoise & Plimpton LLP 31

    Lean 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-Time

    Debevoise & Plimpton LLP 32

    ROADMAP - generic

    Debevoise & Plimpton LLP 33

    Lean Principles

    Eliminate waste Partly completed work Work not needed yet Rework Waiting time Multitasking Extra features

  • ILTA, August 2008

    Debevoise & Plimpton LLP 12

    Debevoise & Plimpton LLP 34

    Lean Principles

    Build quality in Error-proofing Design patterns Automation

    Collaboration Continuous improvement

    Debevoise & Plimpton LLP 35

    Essential 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 workshops

    Debevoise & Plimpton LLP 36

    Essential 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 2008

    Debevoise & Plimpton LLP 13

    Debevoise & Plimpton LLP 37

    Less 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 38

    AGENDA

    Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A

    References Appendix: Estimating

    and Planning in Detail

    Debevoise & Plimpton LLP 39

    Conclusion

    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 two

  • ILTA, August 2008

    Debevoise & Plimpton LLP 14

    Debevoise & Plimpton LLP 40

    Conclusion

    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 work

    Debevoise & Plimpton LLP 41

    AGENDA

    Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A

    References Appendix: Estimating

    and Planning in Detail

    Debevoise & Plimpton LLP 42

    References 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 2008

    Debevoise & Plimpton LLP 15

    Debevoise & Plimpton LLP 43

    References 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 44

    References Womack, James P. and Jones, Daniel T., Lean Thinking,

    Simon & Schuster, 1996; Second Edition, Free Press, 2003. (General reference on the Lean approach)

    http://www.lean.org http://www.ambysoft.com/ Scott Amblers family of

    websites gives lots of detail about Agile modeling, architecture, database practices, and documentation.

    http://agilemanifesto.org/ for the history of Agile and the original Agile Manifesto.

    Leandevelopment group @ Yahoo groups

    Debevoise & Plimpton LLP 45

    AGENDA

    Introduction Agile & Lean Lean @ Debevoise Lean Principles Conclusion Q&A

    References Appendix: Estimating

    and Planning in Detail

  • ILTA, August 2008

    Debevoise & Plimpton LLP 16

    Debevoise & Plimpton LLP 46

    Estimation 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 risk

    Debevoise & Plimpton LLP 47

    Estimation 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 value

    Debevoise & Plimpton LLP 48

    Estimation 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, dependencies

  • ILTA, August 2008

    Debevoise & Plimpton LLP 17

    Debevoise & Plimpton LLP 49

    Estimation 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 time

    Debevoise & Plimpton LLP 50

    Estimation - 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 estimates

    Debevoise & Plimpton LLP 51

    ROADMAP - generic

  • ILTA, August 2008

    Debevoise & Plimpton LLP 18

    Debevoise & Plimpton LLP 52

    Planning 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 crude

    Debevoise & Plimpton LLP 53

    Planning 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 accordingly

    Debevoise & Plimpton LLP 54

    Planning 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 2008

    Debevoise & Plimpton LLP 19

    Debevoise & Plimpton LLP 55

    Planning 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 56

    Planning 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 57

    Release 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 2008

    Debevoise & Plimpton LLP 20

    Debevoise & Plimpton LLP 58

    Planning - 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 roadmap

    Debevoise & Plimpton LLP 59

    Planning 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 60

    Iteration n the final iteration

    Finalize documentation Train and hand off to support staff Finaliz...