Your SlideShare is downloading. ×
Scrum In the Waterfall
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum In the Waterfall

249
views

Published on

A case study of a project in which a Scrum Team was set up and run successfully within an organization that was entirely Agile.

A case study of a project in which a Scrum Team was set up and run successfully within an organization that was entirely Agile.

Published in: Technology, Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
249
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
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. Scrum in the Waterfall Dave Prior, PMP, CST, MBA© David Prior, 2010
  • 2. Once upon a time in the far off land of Oklahoma...© Dave Prior, 2009
  • 3. There was a really big little company that had some very old software...© Dave Prior, 2009
  • 4. That took two years in requirements, and four years to build... ten years ago© Dave Prior, 2009
  • 5. that they needed rebuilt in eight months, using .Net...© Dave Prior, 2009
  • 6. and they had no documented requirements...© Dave Prior, 2009
  • 7. and they wanted to switch to Scrum... at least, some of them did.© Dave Prior, 2009
  • 8. You can use scum or whatever you want. Just give me a Gantt chart, tell me what day you will be done all the work and how much it will cost.© David Prior, 2010
  • 9. Here s the rub... !   Dir. of IT/Product Owner wants a fresh start, embracing change and believes deeply in the benefits of Scrum !   Senior Mgmt./Project Sponsor wants results, but is not interested in changing how the company looks at work !   We needed to find a way to keep both sides happy so we could get the work done.© David Prior, 2010
  • 10. the not helping part... Sr. Sponsor: When will it be done? Product Owner: When you stop asking for more stuff. Sr. Sponsor: What will you have ready for me on Date X? Product Owner - Whatever we ve got completed at that time© David Prior, 2010
  • 11. How we solved it... !   Both the Tech Lead and PM assigned were CSMs !   1 CSM to lead development !   1 CSM to manage communication and relationship with senior management !   Tailoring of the output of the Scrum Process for an audience looking for more traditional PM reporting© Dave Prior, 2009
  • 12. Project Leadership !   Product Owner - storehouse of knowledge of what the application is supposed to do and how it was done before !   Scrum Master - traditional CSM role...leads scrum efforts, manages technical team s efforts !   PM/Scrum Master - acts as the anti-corruption layer between senior sponsor and product owner, translates sprint reporting into something palatable by senior management© David Prior, 2010
  • 13. Why do they want what they want? !   There is the thing being demanded !   There is the reason it is being demanded !   If you can t meet the demand, meet the motivation !   Uncovering why they need what they are asking for can create options for meeting their true need instead of their demand© David Prior, 2010
  • 14. Want - Need !   They want a Gantt chart with milestones, cost estimates, staffing requirements !   They need to be able to demonstrate to the organization that the project is on track and moving in a positive manner towards completion !   A lack of visibility can appear as chaos to those who are already worried. This drives fear, which drives stress !   Stress is way bad !   Scrum offered a level of transparency that was ideally suited to this situation... except for one thing© David Prior, 2010
  • 15. The one thing... !   Senior Management did not have the bandwidth to attend the daily stand-ups or visit the war room or get involved with the project at a participant level !   Senior Management just needed information that they could trust and they needed it provided with minimal effort required of them© David Prior, 2010
  • 16. Care and feeding... !   While Senior Management was asking for traditional reporting, what they really wanted was a clear picture, week to week, of how the work was progressing and some reassurance that we could meet the deadline !   Option 1: Develop a best guess Gantt Chart that would be based only on the initial estimates provided by the Product Owner and hope we d be able to keep pace with it. !   Option 2: Use the output of the Scrum process to build a story, sprint by sprint, that earned trust repeatedly by showing concrete examples of output and progress© David Prior, 2010
  • 17. Getting Started with Option 2 !   We began the project with a backlog of all functionality to be provided in the deliverable. !   The product owner provided the team with complexity estimates on each item to be delivered and had converted those into time estimates as well. !   The product owner assumed no reusability for the components to be produced, working under the assumption that this would provide some padding in the schedule.© David Prior, 2010
  • 18. Working Time While there were some staffing fluctuations across the life of the project, we began with the assumption that we could expect to see an average of six hours of productivity, per day for each resource working on the project. We also assumed that each of them would work five days per week.© Dave Prior, 2009
  • 19. Planning the Sprint !   During Sprint planning meetings, we worked with our ideal hour of labor for that sprint and added items, based on prioritization. Each item would be estimated for both complexity and labor required to complete. !   We added only enough work to fill the number of available hours per sprint !   Because work on the use cases was just beginning at the start of the project, the team had to rely on the product owner to understand the requirements for each deliverable item© Dave Prior, 2009
  • 20. Watching the Variance !   At the start of each sprint we had a set list of tasks for the team to work on. !   We had complexity estimates and labor estimates for each task provided by both the Product Owner and the Development Team. !   We began tracking the variance, sprint to sprint between available hours and actuals and between planned hours and actuals !   We also began tracking the variance between the original estimates and team estimates for both complexity and labor required to complete.© Dave Prior, 2009
  • 21. The slightly educated guess !   By tracking the variance in Fibonacci estimation across sprints, we determined that the original estimates for complexity were, on average, 155% of what the team estimated for the same work. !   By tracking the variance in labor estimation across sprints, we determined that the original estimates for labor were 125% of what the team estimated for the same work.© Dave Prior, 2009
  • 22. The slightly educated guess In order to get closer to an understanding of when the project was likely to actually end, based on what we knew about the deliverables we had to provide, we applied the 3 Point Pert Estimation formula: Optimistic + Most Likely + Pessimistic 3© Dave Prior, 2009
  • 23. 3 Point Pert Application While not an entirely proper use of the formula, it provided a more likely estimate than just using one of the three: Pessimistic: Original Labor Estimate Most Likely: Original Labor Estimate/Fibonacci Estimation Variance Optimistic: Original Labor Estimate/Labor Estimation Variance© Dave Prior, 2009
  • 24. 3 Point Pert Application Example: Pessimistic=Orig. labor estimate = 1,000 hours Most Likely = 1,000 / 125% = 800 Optimistic = 1,000 / 155% = 645 (1,000 + 800 + 645) / 3 = 815 hours© Dave Prior, 2009
  • 25. Working with the educated estimate With an established labor capacity (# of team members * 6 hours/day * 5 days/week) and a revised estimate on how many hours of labor we expect to actually have to complete, we can determine how long it will take to get through the backlog. 4 team members * 6 hours/day * 5 hours/week = ideal work capacity of 120 hours per week© Dave Prior, 2009
  • 26. Applying capacity to the Pert Estimate !  With an ideal capacity of 120 hours of labor per week !  And an estimated 815 hours of labor to burn down !  The project should take 6.8 weeks to complete© Dave Prior, 2009
  • 27. Tracking Performance !   By tracking the team s actuals against their planned work, we were able to determine, on average, how effective they were at reaching their goal each week. !   If we know the team is planning for 120 hours of work per week, but, on average, they only complete 90% of that work, we can make adjustments to how we report on the burndown.© Dave Prior, 2009
  • 28. Tracking Performance !   120 hours/wk * 90% = 108 actual performed hours realized per week !   If we are three weeks into our 815 hour project, we will have realized 324 hours of work instead of our expected 360 hours of work !   This leaves us with 491 hours of work remaining after week three© Dave Prior, 2009
  • 29. Tracking Performance !   Given that we are realizing only 108 hours/week, we have to adjust expectations with the client because the remaining 491 hours will now take longer than originally expected !   491/108 = 4.5 weeks will be required to complete the remaining work as opposed to the 4 weeks it would take if we were performing at 120 hours as planned© Dave Prior, 2009
  • 30. Tracking Performance !   At the end of each sprint, adjustments were made to all of the previous calculations based on new performance data, as well as any new items added to the backlog. !   These adjustments to the estimates keep the reporting as near to real time as possible and it goes a long way with respect to demonstrating the value provided of this type of reporting over the originally request Gantt chart.© Dave Prior, 2009
  • 31. Performance Tracking Working Hours Hours Hours Remaining Remaining Available at Start of at End of (6 Sprint Sprint Targeted Planned Resources Actual Actual / (Based on (Based on Accuracy Accuracy Hours of Hours to at 6 Hours Available original original Planned to Planned to Sprint Start Date Work Work Hours/Day Worked (Goal = 75%) estimate) estimate) Actual Target Sprint 1 9/17/07 50 42 150 40 27% 5265 5225 95% 80% Sprint 2 9/24/07 100 35 150 56 37% 5225 5169 160% 56% Sprint 3 10/1/07 100 39 180 44 24% 5169 5125 113% 44% Sprint 4 10/8/07 125 11 144 47 33% 5125 5078 427% 38% Sprint 5 10/15/07 150 91 180 103 57% 5078 4975 113% 69% Sprint 6 10/22/07 160 89 180 58 32% 4975 4917 65% 36% Sprint 7 10/29/07 170 124 180 132 73% 4917 4785 106% 78% Sprint 8 11/5/07 180 72 180 132 73% 4785 4723 94% 73% Sprint 9 11/12/07 190 69 180 128 71% 4723 4595 186% 67% Sprint 10 11/19/07 120 50 108 54 50% 4595 4541 108% 45% Sprint 11 11/26/07 200 116 180 91 51% 4541 4450 78% 46% Sprint 28 3/24/08 250 4450 4450 Sprint 29 3/31/08 250 4450 4450 Totals 5905 885 48% 141% 57%© David Prior, 2010
  • 32. Keeping It Real !   You need to re-evaluate the variances and update the forecasting based on revised averages which include the new performance data at the end of each sprint and report on this, showing how it trends as the work progresses !   This not only helps you re-evaluate the total work remaining each Sprint it build a story for Sr. Management that can show positive or negative trends !   The story that is created through this type of reporting is what sells the value to Sr. Management© David Prior, 2010
  • 33. Wrapping it up for the folks upstairs... No matter how much information you have on work performed, or work remaining, it is only as good as your ability to communicate it to the parties who need to be able to digest it.© Dave Prior, 2009
  • 34. One Report to Bind It All The weekly report to management !   Summary Page of Issues/Accomplishments !   Summary Table of Performance Data !   Trend and Completion Information !   Breakdown of recorded man hours worked and cost of those hours (if these can be tracked against an original set budget, even better)© Dave Prior, 2009
  • 35. Highlights of Progress as of 6/6/08   Team will spend this week cleaning up bugs and stabilizing what is in place.   Benefits Exceptions is the only part of Timecards that has not yet been developed. Once this is complete and ready for testing, the team will have finished development on the most complex part of the system.   Tracking information has all been updated, all team members on on site.   New planning will begin for the next Sprint.   Q4 Release planning meeting was held.© Dave Prior, 2009
  • 36. Summary Table of Performance Data Project Development Summary       Week Ending 7/25/08   Estimated Total Man Hours of Work Available 3118 Total of Actual Man Hours Worked To Date 1018 Percent of Total Man Hours Worked To Date 33%   Hours of Work Completed in Sprint Ending (7/25/08) 87 Hours of Work Planned for Sprint Ending (7/25/08) 94 Percent of Work Completed to Work Planned 93% Percent of Work Completed to Work Planned Last Sprint 97% Velocity Change Since Last Week -4%   Estimated Hours of Available Work Remaining (Hours) 1620   Development Work Not Yet Done Done (Estimated Hours) 2009   Average Estimation Accuracy (Original vs. Developer) for Open Development Work (Hours) 145% Adjusted Number of Development Hours Remaining 2922 Adjusted Remaining Development Work - Remaining Available Work 1302   Weeks off based on Variance (with 150 wk Man Hours) 8.68© David Prior, 2010
  • 37. Additional Data Points We also track the following on a Sprint to Sprint basis: !   Targeted (ideal) hours vs. Actual Hours Achieved !   Hours Achieved vs. Hours Planned We report on these each week to show trends here as well© David Prior, 2010
  • 38. Trend Charts Percentage  of  Targeted  Hours  Achieved   Hours  Targeted  vs.  Actual  Hours   AVG  To  Date  =  57%   80% 70% 60% 50% 40% 80% 69% 78% 73% 67% 30% 56% 46% 20% 44% 38% 36% 45% 10% 0% Percentage  of  Work  Completed   Work  Planned  vs  Actual  Work  Completed   AVG  to  Date  =  141%     500% 400% 300% 200% 427% 100% 160% 186% 95% 113% 113% 65% 106% 94% 108% 78% 0%© David Prior, 2010
  • 39. What s Missing !   The Summary and Trend Analysis is a great starting place and provides excellent detail that you can use to measure progress, similar to earned value !   But there is an easier way...© David Prior, 2010
  • 40. The Most Important Point In This Presentation© David Prior, 2010
  • 41. Management Likes Pie!© David Prior, 2010
  • 42. The Detailed Pie We track each item in the product backlog by its status© David Prior, 2010
  • 43. A Simpler PieBreak out remaining workby status and total hours © David Prior, 2010
  • 44. Management s Favorite Pie© David Prior, 2010
  • 45. Management s Favorite Pie Not Done, Done, Done Done Not Done 70% 5195 Done 27% 1974 Done Done (includes TBD) 4% 264 7433 Not  Done,  Done,  Done  Done  Break out all work by Done Done• Done Done 27% (includes TBD)• Done Done 3%• Not Done Not Done 70% © David Prior, 2010
  • 46. Summary !   You can use Scrum in a Waterfall Environment, even if the environment will not be converted !   It may work best with a pair of scrum masters, one for the team and one for management !   Understanding the needs of management, not just what they demand is the key to your success !   You need to tailor the information you provide them with to meet their needs. If Scrum does not give them what they want, take what Scrum give you and translate it into something they can digest !   Management likes Pie© David Prior, 2010
  • 47. Questions?© David Prior, 2010
  • 48. Thank You! Dave Prior, PMP, CST Email: dave@mrsungo.com Twitter: @mrsungo© David Prior, 2010

×