Your SlideShare is downloading. ×

Agile Project Management

1,813

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
1,813
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
106
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile Project Management Frank Maurer University of Calgary Computer Science e-Business Engineering Group maurer@cpsc.ucalgary.ca http://ebe.cpsc.ucalgary.ca/Frank.Maurer/ Project Management? • What is it? • Why do we need it? • What is important? • Best experience? • Worst experience? 20-Sep-07 Agile Project Management 2 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 1
  • 2. Why estimate effort? 20-Sep-07 Agile Project Management 3 Copyright © 2006 Frank Maurer. All Rights Reserved. 20-Sep-07 Agile Project Management 4 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 2
  • 3. 20-Sep-07 Agile Project Management 5 Copyright © 2006 Frank Maurer. All Rights Reserved. Common Management Issues • Building teams • Risk management • Project planning • Team coordination • Progress tracking • Quality assurance 20-Sep-07 Agile Project Management 6 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 3
  • 4. Team Formation: Tayloristic Way • role-based (functional, horizontal) • follow detailed plans of entire software development lifecycle • the focus is not on individuals but on the process itself! • teams are tailored to repeatable, manufacturing-like process • tend to lead to isolated islands of knowledge • what is to be done • how it is to be done • the exact time allowed for doing it 20-Sep-07 Agile Project Management 7 Copyright © 2006 Frank Maurer. All Rights Reserved. Team Formation: Agile Way • cross-functional teams (vertical) • require less knowledge transfer (because there is no intermediates who may loose/alter knowledge) • facilitate better knowledge transfer (informally) • rotations from one role to another are common • highly specialized experts can be shared among several teams 20-Sep-07 Agile Project Management 8 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 4
  • 5. Empowerment • Self-determination • Motivation • Leadership • Expertise • Amplify learning by feedback and frequent synchronization 20-Sep-07 Agile Project Management 9 Copyright © 2006 Frank Maurer. All Rights Reserved. Risk Management • Risk identification – E.g. unknown technologies, tools • Risk quantification • Risk resolution – Reserve time for overcoming troubles – Define tasks that reduce risks • Contingency plan http://www.pru.uts.edu.au/images/risk_management_benefits.gif 20-Sep-07 Agile Project Management 10 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 5
  • 6. Typical Risks • Changing scope • Technology is immature or unknown to developers • Wrong effort estimates • Low quality • … 20-Sep-07 Agile Project Management 11 Copyright © 2006 Frank Maurer. All Rights Reserved. 20-Sep-07 Agile Project Management 12 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 6
  • 7. Four Project Variables • Cost – CHAOS Reports, Standish Group, 1994- 2002 • Scope – Feature creep – Requirements churn • Time – “Adding people to a late project just makes it later” Brooks, Mythical Man Month • Quality – Disasters and software bugs http://www.mtholyoke.edu/~rzdalea/cs100/software_disasters/sd.htm http://www.csl.sri.com/users/neumann/illustrative.html 20-Sep-07 Agile Project Management 13 Copyright © 2006 Frank Maurer. All Rights Reserved. Software Project Overruns • Kjetil Moløkken-Østvold, Kristian Marius Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, Proc Agile 2007, IEEE: – About 70-80% of all projects encounter effort (cost) overruns – The average magnitude of effort overruns is 30-40% – Similar results for schedule overruns – No apparent change the past 30-40 years • Moløkken-Østvold and Jørgensen, "A Comparison of Software Project Overruns“, IEEE Transactions on Software Engineering, 2004: – Effort overruns based on development process • Projects using sequential processes: Median= 60% (Mean=55%) • Projects using flexible processes: Median=1% (Mean=24%) • Interviews found that flexible development processes fostered good collaboration with the customer 20-Sep-07 Agile Project Management 14 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 7
  • 8. Project Management • Project management = planning, organizing, controlling of tasks & resources to accomplish a defined objective • What, who, when, how much (i.e. costs) • Command and control 20-Sep-07 Agile Project Management 15 Copyright © 2006 Frank Maurer. All Rights Reserved. Project Management Tasks • Planning the project – Define tasks, task dependencies and milestones • Estimate effort – How long will it take to do something • Scheduling the tasks – Define start and finish dates • Assign tasks – Who will work on it – Resource leveling – Myth: “if we fall behind the schedule, we can always add more programmers and catch up later in the project” • Tracking progress – Conducting periodic project status meetings – Determine whether formal project milestones have been accomplished – Compare planned and actual end dates 20-Sep-07 Agile Project Management 16 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 8
  • 9. Gantt Chart 20-Sep-07 Agile Project Management 17 Copyright © 2006 Frank Maurer. All Rights Reserved. Managers and Leaders • Managers: command and control – Define and assign tasks – Gather status reports and track progress • Leaders: convince and steer – Help team to plan project – Coach team members – Remove obstacles 20-Sep-07 Agile Project Management 18 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 9
  • 10. Agile Management Strategy • Team members accept responsibility – Tasks are not assigned but team members sign up for them • Committed to do quality work • Not much management overhead • Coaching & mentoring (software apprentice) 20-Sep-07 Agile Project Management 19 Copyright © 2006 Frank Maurer. All Rights Reserved. Four Values • Communication – “problems with projects can invariably be traced to somebody not talking to somebody else about something important” XP p. 29 • Simplicity – “what is the simplest thing that could possibly work?” – YAGNI – you ain‟t gone need it • Feedback – Put system in production ASAP – “Have you written a test case for that yet?” • Courage – Hill climbing (simple, complex, simpler,..) – Big jumps take courage 20-Sep-07 Agile Project Management 20 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 10
  • 11. 20-Sep-07 Agile Project Management 21 Copyright © 2006 Frank Maurer. All Rights Reserved. Project Vision • Vision = Statement of what the business will look like once the new system is implemented. • Used to establish a project budget • Established by product owner – Provides/finds funding for projects • Vision includes – Anticipated benefits for business – Assessment criteria for management to evaluate progress and conformance to vision  Management oversight needed 20-Sep-07 Agile Project Management 22 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 11
  • 12. Product Owner • Defines project vision  big picture • Provides/finds funding for projects • Checks ROI • Prioritizes backlog • One person – must represent all stakeholders 20-Sep-07 Agile Project Management 23 Copyright © 2006 Frank Maurer. All Rights Reserved. DSDM Process Feasibility Feasibility Agree schedule Implement Create Identify Functional Functional Model Functional Review Implementation Train Prototype Prototype busines business users s User approval and Review Prototype user guidelines Identify Design prototype Agree Review Design and Build Schedule Design Iteration Prototype Create Design Prototype 20-Sep-07 Agile Project Management 24 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 12
  • 13. Return on Investment (ROI) • Payback time Software by Numbers, p. 16 • Net present value, internal rate of return  SE Economics • Monetary versus non-monetary payback 20-Sep-07 Agile Project Management 25 Copyright © 2006 Frank Maurer. All Rights Reserved. A Matter of Trust: Business Contracts • Fixed scope/fixed price contracts – Trust by contract – Attempts to move technical risk to development side Cost of – Contract requires documentation change requests  imposes process – Opposing sides of table • How are fixed prices derived by development organization? How urgently do I need the contract? • Time and expenses contracts: Fixed budget/ variable scope/early termination – Trust by feedback and involvement Risk multiplier – Collaborative environment (Insurance premium) – Changes easy – Issues: • No time limit on project Honest effort estimate • No guaranteed functionality 20-Sep-07 Agile Project Management 26 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 13
  • 14. The Relationship between Customer Collaboration and Software Project Overruns • Good collaboration is subjective, and not precisely defined • This paper (and presentation) highlights these collaboration issues – Communication – Contracts – Customer capability • In-depth analysis of 18 projects conducted by a contractor – Follow up of the large-scale study in 18 different organizations – Personal interviews (actual  estimate ) • Overrun measure = BREbias  min( actual , estimate ) Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission 20-Sep-07 Agile Project Management 27 Copyright © 2006 Frank Maurer. All Rights Reserved. Contracts • Contracts are important since they often regulate collaboration (directly or indirectly) • Common contract types Target Pricing A pricing method that involves (1) identifying – Time and material the price at which a product will be – Fixed price competitive in the marketplace, (2) defining the desired profit to be made on the product, – Target price (better: Flexible pricing) and (3) computing the target cost for the product by subtracting the desired profit from • Mutual sharing of cost overruns (and the competitive market price. The formula vice versa) • Floors and ceilings for cost sharing Target Price - Desired Profit = Target Cost Target cost is then given to the engineers and product designers, who use it as the maximum cost to be incurred for the materials and other resources needed to design and manufacture the product. It is their responsibility to create the product at or below its target cost. http://www.answers.com/topic/target-pricing?cat=biz-fin Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission 20-Sep-07 Agile Project Management 28 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 14
  • 15. Contract form and overruns Boxplot of BREBias vs Contract form 1,5 1,0 BREBias 0,5 0,0 -0,5 1 - By the hour 2 - Fixed price 3 - Target price 4 - Other Contract form N Mean Median By the hour 4 0.55 0.37 Fixed price 5 0.33 0.19 Target price 7 0.10 0.21 Other 2 0.13 0.13 Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission 20-Sep-07 Agile Project Management 29 Copyright © 2006 Frank Maurer. All Rights Reserved. Contact frequency and overruns Boxplot of BREBias by Communication frequency 2,0 Level Mean Median 1,5 Daily 0.09 0.19 1,0 Not Daily 0.58 0.35 BREBias 0,5 0,0 Daily Not daily Communication frequency • A Kruskal-Wallis test for difference results in p=0.023 • The corresponding size of effect is d=1.25, indicating a large size of effect Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission 20-Sep-07 Agile Project Management 30 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 15
  • 16. 20-Sep-07 Agile Project Management 31 Copyright © 2006 Frank Maurer. All Rights Reserved. Mike Cohn: Agile Estimating & Planning Why we plan “Planning is everything. Plans are nothing.” Field Marshal Helmuth Graf von Moltke • Reduce risk • Reduce uncertainty • Support better decision making • Establishing trust • Conveying information 20-Sep-07 Agile Project Management 32 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 16
  • 17. Barry Boehm’s Cone of Uncertainty Mike Cohn: Agile Estimating & Planning, p. 4 Upfront Planning and the Cost of Change Standard SE Cost of change Agile assumption time 20-Sep-07 Agile Project Management 34 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 17
  • 18. Mike Cohn: Agile Estimating & Planning Why plans fail • Completion of activity vs feature delivery – Activities don‟t finish early Parkinson‟s Law: Work expands so as to fill the time available for its completion – Lateness is passed down the schedule: One thing that goes wrong is passed on (while all things must go right for early start) – Activities are not independent • Multitasking causes further delays Ibid. p 15 20-Sep-07 Agile Project Management 35 Copyright © 2006 Frank Maurer. All Rights Reserved. 20-Sep-07 Agile Project Management 36 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 18
  • 19. Some Terminology • Project planning, iteration planning, planning game (XP), sprint planning (Scrum) • Story card/index card (XP), backlog entry (Scrum), feature/feature set (FDD) • Customer, goal donor/user, gold owner/client, product owner, scrum master • Spike 20-Sep-07 Agile Project Management 37 Copyright © 2006 Frank Maurer. All Rights Reserved. Architectural Spike • Throw-away prototype • Answers technical issue • Reduce technical risk or improve reliability • Usually: Pair for 1-2 weeks 20-Sep-07 Agile Project Management 38 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 19
  • 20. Project Planning: Agile Way • Business value focused – User stories, features • Project scope not fixed at beginning  reactive to changing business needs • Short timeframes – 1 week – 3 months • Planning and coordination are team efforts – Planning game – Product backlog – Daily standup meeting (scrum) – Estimates done by developers 20-Sep-07 Agile Project Management 39 Copyright © 2006 Frank Maurer. All Rights Reserved. Time Boxes • Never slip a date  change scope • Sometimes external deadlines are HARD • Advantages – Increased motivation • Successful delivery keeps developers and customers happy – Faster feedback – Creates a constant project heartbeat – Deadlines create pressure (counters: work fills time available) • Advantages of flexible dates – Release only when required scope is completed – Overly optimistic deadlines are made more realistic 20-Sep-07 Agile Project Management 40 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 20
  • 21. Feature-Driven Development (Coad, Lefevbre, De Luca) • Deliver frequent, tangible, working results that are “useful in the eyes of the client” • A feature defines a task • Group features into business-related sets • Focus on delivering results every two weeks • Track and report progress by feature progress 20-Sep-07 Agile Project Management 41 Copyright © 2006 Frank Maurer. All Rights Reserved. The Five FDD Processes Peter Coad et al: Java Modeling Color with UML, Prentice Hall 1999, p.190 20-Sep-07 Agile Project Management 42 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 21
  • 22. FDD Process Peter Coad et al: Java Modeling Color with UML, Prentice Hall 1999, p.198 20-Sep-07 Agile Project Management 43 Copyright © 2006 Frank Maurer. All Rights Reserved. Agile Project Planning • Project vision  the really big picture • Release planning  strategic picture – Chooses a few months worth of user stories/features – Date and scope – Can be changed – Creates product backlog • Iteration planning  tactical picture – Few weeks – Set of stories prioritized by customer – Creates sprint backlog – Define set of tasks for each story – Task granularity: 1-3 work days  estimation accuracy 20-Sep-07 Agile Project Management 44 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 22
  • 23. 20-Sep-07 Agile Project Management 45 Copyright © 2006 Frank Maurer. All Rights Reserved. Agile Requirements Definition • User stories/Backlog Entries Feature requests – On index cards – Short descriptions of a feature – In customer language, no techno babble – Provide value to customer – Independent of each other – Testable – Small  decompose large stories • Estimated by developers: best case, most likely, worst case • Collect story cards and prioritize them 20-Sep-07 Agile Project Management 46 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 23
  • 24. When is a User Story Done? • All unit tests pass • All acceptance test pass • The customer accepts it • All refactorings are done 20-Sep-07 Agile Project Management 47 Copyright © 2006 Frank Maurer. All Rights Reserved. Who Decides ? • Business decisions – Scope: which “user stories” should be developed – Priority of stories – Composition of releases – Release dates • Technical decisions – Time estimates for features/stories – Elaborate consequences of business decisions – Team organization and process – Scheduling 20-Sep-07 Agile Project Management 48 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 24
  • 25. Mike Cohn: Agile Estimating & Planning, p 135 20-Sep-07 Agile Project Management 49 Copyright © 2006 Frank Maurer. All Rights Reserved. Managing a Release • Value Driven Releases • Business value = f(cost, time, functionality, quality) • 80% of the business value can be derived from 20% of the functionality • Linear development: Christmas wish lists • Iterative development: prioritized wish list 20-Sep-07 Agile Project Management 50 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 25
  • 26. M. Denne, J. Cleland-Huang: Software by Numbers, Prentise-Hall, 2004 Minimum Marketable Features • Components with intrinsic marketable value • Creates business value by – Competitive differentiation – Revenue generation – Cost Saving – Brand projection – Enhanced loyalty 20-Sep-07 Agile Project Management 51 Copyright © 2006 Frank Maurer. All Rights Reserved. Mike Cohn: Agile Estimating & Planning, p 83+85 Prioritization of features • Financial value • Amount of risk removal • Development cost High High risk High risk Low Value High Value • Amount of learning Avoid Do first Risk Low risk Low risk Low Value High Value Low Do last Do second Low Value High 20-Sep-07 Agile Project Management 52 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 26
  • 27. 20-Sep-07 Agile Project Management 53 Copyright © 2006 Frank Maurer. All Rights Reserved. Low fi prototypes describing product vision • Sketches • Storyboards • Pictive • Wizard of Oz 20-Sep-07 Agile Project Management 54 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 27
  • 28. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Sketching and Prototyping Early design Brainstorm different representations Sketches & low fidelity paper Choose a representation prototypes (LO-FI) Rough out interface style Task centered walkthrough and redesign Medium fidelity prototypes Fine tune interface, screen design Heuristic evaluation and redesign Usability testing and redesign High fidelity prototypes Limited field testing Alpha/Beta tests Working systems Late design Courtesy of Dr Sharlin/Greenberg (CPSC 481) Sketches & Low Fidelity Prototypes • Paper mock-up of the interface look, feel, functionality – quick and cheap to prepare and modify • Purpose – brainstorm competing representations – bring out user reactions – bring out user modifications / suggestions Desktop Technology Program 28
  • 29. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Sketches – drawing of the outward appearance of the intended system – crudity means people concentrate on high level concepts – but hard to envision a dialog‟s progression Computer Telephone Last Name: First Name: Phone: Place Call Help Courtesy of Dr Sharlin/Greenberg (CPSC 481) The attributes of sketches • Quick • Constrained resolution – to make – doesn‟t restrain concept • Timely exploration – provided when needed • Consistency with state • Disposable – refinement of rendering matches the actual state of – investment in the concept, development of the not the execution concept • Plentiful • Suggest & explore – they make sense in a rather than confirm collection or series of ideas – value lies in suggesting • Clear vocabulary and provoking what could – rendering & style indicates be it‟s a sketch, not an – sketches are the medium implementation to conversation and interaction Desktop Technology Program 29
  • 30. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Storyboarding – a series of key frames as sketches • originally from film; used to get the idea of a scene • snapshots of the interface at particular points in the interaction – users can evaluate quickly the direction the interface is heading Excerpts from Disney’s Robin Hood storyboard Courtesy of Dr Sharlin/Greenberg (CPSC 481) note how each scene in this storyboard is annotated Desktop Technology Program 30
  • 31. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Initial Scan the screen stroller -> Change the Place the color -> order -> Courtesy of Dr Sharlin/Greenberg (CPSC 481) Alternate Scan the path… shirt -> Touch Delete previous that item-> item -> Desktop Technology Program 31
  • 32. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Pictive plastic interface for collaborative technology initiatives through video exploration Muller, CHI 1991 • Designing with office supplies – multiple layers of sticky notes and plastic overlays – different sized stickies represent icons, menus, windows etc. • interaction demonstrated by manipulating notes – new interfaces built on the fly • session videotaped for later analysis – usually end up with mess of paper and plastic! Courtesy of Dr Sharlin/Greenberg (CPSC 481) Pictive • Can pre-make paper interface components buttons menu alert box combo box tabs list box entries Desktop Technology Program 32
  • 33. Desktop Technology Program 33
  • 34. Desktop Technology Program 34
  • 35. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Medium Fidelity Prototypes • “With a computer” • Many different types – from simple computer drawn images to partially working systems • May take longer to generate and change than low-fi • Benefits – Seems more like the completed detailed system, provides a clearer idea of how it works – May allow user testing (not true for all medium fidelity prototypes). • Pitfalls – User‟s reactions are usually “in the small” • Blinds people to major representational flaws because of a tendency to focus on more minor details – Users more reluctant to challenge/change the design itself • Designs are too “pretty”, developers‟ egos… – Management may think its real! Courtesy of Dr Sharlin/Greenberg (CPSC 481) Medium Fidelity Painting/drawing packages • draw each storyboard scene on computer – very thin horizontal prototype (across features, no functionality) – does not capture the interaction “feel” Control panel for pump 2 Control panel for pump 2 DANGER! coolant flow 45 % next coolant flow 0 % drawing retardant 20% retardant 20% (for shut speed 100% down speed 100% condition) Shut Down Shut Down Desktop Technology Program 35
  • 36. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Medium Fidelity Scripted simulations • create storyboard with media tools on a computer – scene transition activated by simple user inputs – a simple vertical prototype – Can use PowerPoint… • user given a very tight script/task to follow – appears to behave as a real system – script deviations blow the Control panel for pump 2 DANGER! simulation coolant flow 45 % coolant flow 0 % retardant 20% speed 100% Shut Down Shut Down Courtesy of Dr Sharlin/Greenberg (CPSC 481) Medium Fidelity Interface builders –Tools for letting a designer layout the common widgets –Construct mode • Change attributes of objects –Test mode: • Objects behave as they would under real situations –Excellent for showing look and feel • A broader horizontal prototype • But constrained to widget library –Vertical functionality added selectively • Through programming Desktop Technology Program 36
  • 37. Courtesy of Dr Sharlin/Greenberg (CPSC 481) • “pay no attention to the man behind the curtain!” Courtesy of Dr Sharlin/Greenberg (CPSC 481) Wizard of Oz • A method of testing a system that does not exist – the listening typewriter, IBM 1984 Dear Henry Speech Computer What the user sees From Gould, Conti & Hovanvecz, Comm ACM 26(4) 1983. Desktop Technology Program 37
  • 38. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Wizard of Oz • A method of testing a system that does not exist – the listening typewriter, IBM 1984 Dear Henry Dear Henry Speech Computer What the user sees The wizard From Gould, Conti & Hovanvecz, Comm ACM 26(4) 1983. Courtesy of Dr Sharlin/Greenberg (CPSC 481) Wizard of Oz • Human „wizard‟ simulates system response – interprets user input according to an algorithm – controls computer to simulate appropriate output – uses real or mock interface – wizard sometimes visible, sometimes hidden • “pay no attention to the man behind the curtain!” • good for: – adding simulated and complex vertical functionality – testing futuristic ideas Desktop Technology Program 38
  • 39. 20-Sep-07 Agile Project Management 77 Copyright © 2006 Frank Maurer. All Rights Reserved. Scrum Flow (Sutherland, Schwaber and Beedle) Scrum: 15 min daily meetings Team members respond to basics: -What did you do since last Scrum? -Do you have any obstacles? Ken Schwaber, Agile Project Management with Scrum, -What will you do before next meeting? Microsoft Press: 2004. Sprint: 30 days Features assigned to Sprint Potentially Shippable Functionality Desktop Technology Program 39
  • 40. Cohn‟s Iteration Planning (p 145ff) • Tasks are not allocated during iteration planning  devs pick 1-2 at start of iteration and then the next when these are done  built “we‟re all in this together” attitude • Iteration vs Release Planning (p. 149 Release Plan Iteration Plan Planning horizon 3-9 months 1-4 weeks Items in plan User stories Tasks Estimated in Story points or Ideal hours ideal days 20-Sep-07 Agile Project Management 79 Copyright © 2006 Frank Maurer. All Rights Reserved. Agile estimation process 20-Sep-07 Agile Project Management 80 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 40
  • 41. Size estimation • Story points or Ideal Days (Gummy Bears, Effort, …) – “Complexity” or “size” of task – Relative to other tasks • Based on experiences from the past Estimates • Team effort are not – Optimism wins commitments – Team usually does not overrule the estimate of programmers responsible for a task • Presumed Issue: Effort estimates done by developers might lead to slack 20-Sep-07 Agile Project Management 81 Copyright © 2006 Frank Maurer. All Rights Reserved. Ideal days • How long is an American football game: – 4 x 15min = 60min (ideal time – Approx. 3h (elapsed time) • Elapsed time is influenced by – amount of none-development tasks – estimation accuracy – available developer time – experience – number of concurrent projects – … 20-Sep-07 Agile Project Management 82 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 41
  • 42. Mike Cohn: Agile Estimating & Planning, p 69ff Story points vs ideal days • Story points – Help drive cross-functional behavior – Estimates do not decay – Pure size measure – Often faster – My ideal days are not your ideal days • Ideal days – Easier to explain to outsiders – Easier at first 20-Sep-07 Agile Project Management 83 Copyright © 2006 Frank Maurer. All Rights Reserved. Mike Cohn: Agile Estimating & Planning, p 49ff Techniques for estimating “Prediction is very difficult, especially about the future” Niels Bohr • You will NOT be 100% accurate • Diminishing return of more estimation effort • Estimation scale: stay within one order of magnitude – User stories, epics, themes • Deriving an estimate – Expert opinion – Analogy – Disaggregation – Planning poker 20-Sep-07 Agile Project Management 84 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 42
  • 43. Mike Cohn: Agile Estimating & Planning, p 121ff Splitting user stories • Split along the boundaries of the data supported by the story – E.g. Loan summary  List of individual loans  List of loans with error handling • Split based on operations performed within a story – E.g. separate CRUD operations • Remove cross-cutting concerns – E.g. story without and with security • Separate functional from non-functional requirements – Make it work, then make it fast • Tracer bullet through all layers with partial story functionality 20-Sep-07 Agile Project Management 85 Copyright © 2006 Frank Maurer. All Rights Reserved. Reflecting plan uncertainty • (Best case), most likely case, worst case • Project buffer: – Max 70% of must have features – MoSCoW rule (must have, should have, could have, won‟t have) in DSDM – Alternative: calculate • Slack needed for learning standard deviation  Tom DeMarco: Slack n  (wce mlce ) 2 i i i 1 20-Sep-07 Agile Project Management 86 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 43
  • 44. Velocity • Measures rate of progress of a team • Amount of story points completed in the last iteration • Best guess: next iteration = same as last iteration (“yesterday’s weather”) • Story points (or ideal days) + velocity  duration – Velocity corrects estimation error – Accommodates developer optimism – overcomes the issue of if story points are measured based on pairs or individuals 20-Sep-07 Agile Project Management 87 Copyright © 2006 Frank Maurer. All Rights Reserved. Comments on story points and velocity • Task effort depends on the current development context – developer experience with technology – “likeness” of task to others – availability of reusable code • Story points is not well defined  what does 1 story point really mean? – Changing velocities over time  can‟t use “old” numbers • Customers sometimes prefer estimates in hours • Velocity maps story points to person-hours available in iteration – blurs development effort for customers  open & honest communication? 20-Sep-07 Agile Project Management 88 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 44
  • 45. Observations from Past Planning Exercises • Effort: 2-4h for one week of work – Brainstorming user stories usually not done – Assignment of responsibilities missing • Language for specifying requirements – Often too much IT oriented • useful for communicating with customer? – Often to fine grained • user stories need to have business value – Testing tasks are not user stories • Required to be done – no choice for customer • Business value? • Interaction with customer is NOT finished 20-Sep-07 Agile Project Management 89 Copyright © 2006 Frank Maurer. All Rights Reserved. Sprint Review Meeting Rules • 2-3 hours • Maximum 1 hour preparation • No PowerPoint presentations • Done on equipment where software was developed and tested • Presented by team to Product Owner and customers/users • Basis for planning next Sprint • Must represent potentially shippable increment of product functionality 20-Sep-07 Agile Project Management 90 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 45
  • 46. Scrum Study (Mann/Maurer) • 2 year longitudinal case study • Researcher embedded in development team • Overall results: Average Percent Overtime Worked By Team Windows App 1 support and Scrum Introduced 100.00 Windows App 2 – Reduced 80.00 Development New Windows App Release % Hours Overtime overtime 60.00 Website Release – Increased 40.00 20.00 customer 0.00 satisfaction -20.00 01-05-2003 02-09-2003 03-16-2003 04-20-2003 05-25-2003 06-29-2003 08-03-2003 09-07-2003 10-12-2003 11-16-2003 12-21-2003 01-25-2004 02-29-2004 04-04-2004 05-09-2004 06-13-2004 07-18-2004 08-22-2004 09-26-2004 10-31-2004 12-05-2004 01-09-2005 02-13-2005 Week 20-Sep-07 Agile Project Management 91 Copyright © 2006 Frank Maurer. All Rights Reserved. 20-Sep-07 Agile Project Management 92 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 46
  • 47. Daily Scrums (Stand-up Meetings) • Daily 15 minute status meeting • Same place and time every day • Meeting room • Chickens and pigs • Three questions; – What have you done since last meeting? – What will you do before next meeting? – What is in your way? • Impediments and • Decisions Based on Ken Schwaber‟s Certified Scrum Master course 20-Sep-07 Agile Project Management 93 Copyright © 2006 Frank Maurer. All Rights Reserved. Based on Ken Schwaber’s Certified Scrum Master course Chickens and Pigs • A chicken and a pig are together when the chicken says, "Let's start a restaurant!“ • The pig thinks it over and says, "What would we call this restaurant?“ • The chicken says, "Ham n' Eggs!" • The pig says, "No thanks. I'd be committed, but you'd only be involved!" 20-Sep-07 Agile Project Management 94 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 47
  • 48. Benefits of the Daily Meeting • Focuses people to think about what has to be done in the short term • Puts peer pressure to see who is working to accomplish goals • Surfaces roadblocks quickly • Forces managers to not interfere with the project team From: http://www.controlchaos.com/old-site/meeting.htm 20-Sep-07 Agile Project Management 95 Copyright © 2006 Frank Maurer. All Rights Reserved. End-of-Sprint Review Proceed or terminate? Proceed: define next iteration Based on Ken Schwaber‟s Certified Scrum Master course 20-Sep-07 Agile Project Management 96 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 48
  • 49. Sprint Review Meeting Rules • 2-3 hours • Maximum 1 hour preparation • No PowerPoint presentations • Done on equipment where software was developed and tested • Presented by team to Product Owner and customers/users • Basis for planning next Sprint • Must represent potentially shippable increment of product functionality 20-Sep-07 Agile Project Management 97 Copyright © 2006 Frank Maurer. All Rights Reserved. Reporting: Tracking Progress & Metrics • Two questions – How many hours/days have you worked? – How many more does it take? } Which one is more important • Project metrics – Actual time worked on a task – Work burndown graph • Per iteration • #Backlog  project – #Bugs – #Stories completed – #Acceptance tests defined and passing – #Unit tests – Test coverage – … 20-Sep-07 Agile Project Management 98 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 49
  • 50. Iteration tracking Ibid 228 20-Sep-07 Agile Project Management 99 Copyright © 2006 Frank Maurer. All Rights Reserved. Based on Ken Schwaber’s Certified Scrum Master course Project Tracking: Work Burndown Charts No one home 2500 2000 1500 No one home 1000 500 0 11 13 15 17 19 21 23 25 27 29 31 1 3 5 7 9 Underestimating Overestimating 3000 1800 1600 2500 1400 2000 1200 1000 1500 Underestimating Overestimating 800 1000 600 400 500 200 0 0 11 13 15 17 19 21 23 25 27 29 31 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 1 3 5 7 9 20-Sep-07 Agile Project Management 100 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 50
  • 51. Progress Tracking with FDD http://www.togethercommunity.com/coad-letter/Coad-Letter-0070.html 20-Sep-07 Agile Project Management 101 Copyright © 2006 Frank Maurer. All Rights Reserved. Parking Lot Diagram Pg. 201, Java Modeling in Color with UML 20-Sep-07 Agile Project Management 102 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 51
  • 52. Agile Practices • Agile methods lay out a vision and then nurtures project resources to do the best possible to achieve the plan. • Agile is the “art of the possible.” • “better to beg forgiveness than ask permission.” • Agile employs the following practices: – Frequent inspection and adaptation – Emergence of requirements, technology, and team capabilities – Self-organization and adaptation in response to what emerges • Creativity • Let the team figure out what to do and then do it – Incremental emergence – Dealing with reality, not artifacts – Collaboration Based on Ken Schwaber‟s Certified Scrum Master course 20-Sep-07 Agile Project Management 103 Copyright © 2006 Frank Maurer. All Rights Reserved. Scrum – Tips, Tricks, Observations • Pay $1 for being late for a Scrum meeting • Always deliver a vertical slice of user functionality • Scrum backlog entries tend to be coarser grained than XP user stories • Keep things visible in customer terms • In Scrum meetings NO information is passed that is not potentially of interest for everybody • Best case plan versus minimum promised to customer • Sprint review & planning meeting: – 1.5days initially – Later 1day • Planning horizon: do not overlook the big picture • Process improvement entries in backlog • Inter-team learning: informal meeting of Scrum masters • Scrum is scalable – Scrum of Scrums – Multiple teams working together: 20% overhead – Infrastructure teams (often: virtual teams): other teams are customers • Architecture diagram for reporting progress visually 20-Sep-07 Agile Project Management 104 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 52
  • 53. Common Impediments • Workstation, network, and/or server are down; • Network or server are slow; • Required to attend human resource training session; • Required to attend status meeting with management; • Asked by management to do something else; • Asked to do something other than what this team member committed to for this Sprint; • Unsure about how to proceed; • Unsure of design decision; and • Unsure how to use technology. Based on Ken Schwaber‟s Certified Scrum Master course 20-Sep-07 Agile Project Management 105 Copyright © 2006 Frank Maurer. All Rights Reserved. Ibid p 249ff Why does it work? • Replanning occurs frequently • Separation of size and duration • Plans at different levels • Small cycle time (i.e small stores) keeps work flowing • Fuzzy states (e.g. 70% done) are elimnated • Tracking at the team level • Uncertainty is planned for 20-Sep-07 Agile Project Management 106 Copyright © 2006 Frank Maurer. All Rights Reserved. Desktop Technology Program 53
  • 54. Summary • Vision, release, iteration • Short horizon for detailed planning • Reporting needs to tie in with vision and business value • Adaptive and flexible • Team effort 20-Sep-07 Agile Project Management 107 Copyright © 2006 Frank Maurer. All Rights Reserved. Discussion maurer@cpsc.ucalgary.ca http://ebe.cpsc.ucalgary.ca/Frank.Maurer Desktop Technology Program 54

×