agile / lean estimating and planningilta.personifycloud.com/webfiles/productfiles/232/misc6.pdfagile...

ILTA, August 2008

Debevoise & Plimpton LLP 1

Agile / LeanEstimating and Planning

Alina [email protected]

Manager of Architecture & DevelopmentDebevoise & Plimpton LLP

ILTA, August 2008


AGENDA

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

• References• Appendix: Estimating

and Planning in Detail


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



AGENDA





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.


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



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


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


AGENDA




ILTA, August 2008



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


Project Roadmap


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



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.


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.


Iteration 1

ILTA, August 2008



Baseline Architecture


Iteration 1


Iteration 2

ILTA, August 2008



Iteration 2


Iteration 3


Iteration 4

ILTA, August 2008



Iteration 5


Iterations 2 to n-1


User story: Workflow

ILTA, August 2008



Final Iteration - Deployment


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)


AGENDA




ILTA, August 2008



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.


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


Short Feedback Cycles

ILTA, August 2008



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


ROADMAP - generic


Lean Principles

• Eliminate waste– Partly completed work– Work not needed yet– Rework– Waiting time– Multitasking– “Extra” features

ILTA, August 2008



Lean Principles

• Build quality in– Error-proofing– Design patterns– Automation

• Collaboration• Continuous improvement


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


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



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.


AGENDA





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



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


AGENDA





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



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.)


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 Ambler’s 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


AGENDA




ILTA, August 2008



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


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


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



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


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


ROADMAP - generic

ILTA, August 2008



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


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


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




• 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.



• 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.


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



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


Planning – Iterations 2 to n-1

• At delivery of prior iteration’s 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.


Iteration 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

agile / lean estimating and planningilta.personifycloud.com/webfiles/productfiles/232/misc6.pdfagile...

Documents