Scrum In the Waterfall

Scrum in the Waterfall
Dave Prior, PMP, CST, MBA

© David Prior, 2010

Once upon a time in the far
off land of Oklahoma...

© Dave Prior, 2009

There was a really big little
company that had some very
old software...

© Dave Prior, 2009

That took two years in
requirements, and four years
to build... ten years ago

© Dave Prior, 2009

that they needed rebuilt in
eight months, using .Net...

© Dave Prior, 2009

and they had no
documented requirements...

© Dave Prior, 2009

and they wanted to switch to
Scrum... at least, some of
them did.

© Dave Prior, 2009

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.


Here s the rub...
!   Dir. of IT/Product Owner wants a fresh start,
embracing change and believes deeply in the
beneﬁts of Scrum

!   Senior Mgmt./Project Sponsor wants results, but
is not interested in changing how the company
looks at work

!   We needed to ﬁnd a way to keep both sides
happy so we could get the work done.


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

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

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


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


Want - Need
!   They want a Gantt chart with milestones, cost estimates,
stafﬁng 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

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


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

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.


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

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 ﬁll 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

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

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

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

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

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

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

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

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

!   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

!   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

!   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

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%

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

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

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

Highlights of Progress as of 6/6/08
  Team will spend this week cleaning up bugs and stabilizing
what is in place.

  Beneﬁts 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 ﬁnished 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

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


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

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%


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


The Most Important Point
In This Presentation


Management
Likes Pie!


The Detailed Pie
We track each item in the product
backlog by its status


A Simpler Pie

Break out remaining work
by status and total hours


Management s Favorite Pie


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%


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

Questions?


Thank You!

Dave Prior, PMP, CST
Email: dave@mrsungo.com
Twitter: @mrsungo

Scrum In the Waterfall

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Scrum In the Waterfall

Semelhante a Scrum In the Waterfall (20)

Mais de Dave Prior

Mais de Dave Prior (8)

Último

Último (20)

Scrum In the Waterfall