The fact that your poject is agile is not (necessarily) a cost driver arlene minkiewicz

© 2020 PRICE Systems, L.L.C. All Rights Reserved
The Fact that your
Project is Agile Is Not
Necessarily a Cost
Driver
1
PRICE® Research

Cost Analytics

Today’s Presenter
3
Arlene Minkiewicz
Chief Scientist
• 36 years of cost research experience
• Leads PRICE® Research, responsible for data research and
analysis of costing trends.
• Designed and led the implementation efforts of the PRICE®
Models, predictive analytic cost models.
• She works with industry leaders to collect and maintain cost
research data, sharing analyses with the cost estimating
community
• Her research has been published in books, trade journals and
conference proceedings and has been awarded frequently by
the industry. She speaks frequently at conferences on subjects
of cost estimating and measurement.

Agenda
• Introduction
• Agile Overview
• Methodology and “Rules of Thumb”
• Agile Cost Driver Considerations
• Conclusions

Introduction
• What is Agile?
‒ Agile development practices have enabled
organizations to deliver quality software that
optimizes customer satisfaction
‒ Agile processes rely on highly skilled developers communicating
with clients and each other to optimize value delivered
‒ This requires a mind shift during project planning
• Development teams
• Consumers
‒ From a purely agile perspective estimation doesn’t make sense
‒ From a business/program perspective estimation is still important
5

Introduction
• Agile is a philosophy, not a specific process
‒ All agile teams apply this philosophy but not in the same ways
• There are many different frameworks for agile
implementation, each of which potentially apply:
‒ Different Processes
‒ Different Practices
• The fact that a project is agile may suggest a different
approach to estimation
• Knowing a project is agile is not enough to inform an
estimate without conversations between
‒ Estimating Team
‒ Agile Development Team
6

Overview
7

Agile Introduction – History
• At inception, software development was not treated as an
engineering discipline but rather a combination of:
‒ Art
‒ Science
‒ With a sprinkle of black magic
• As technology improved, complexity increased:
‒ Ensuing failure to step back and take a breath
• Many software projects spiraled out of control
8

Agile Manifesto
• We are discovering better ways of developing
software by doing it and helping others do it
‒ Individuals and interactions over processes and tools
‒ Working software over comprehensive documentation
‒ Customer collaboration over contract negotiation
‒ Responding to change over following a plan
• All agile projects
‒ Adhere to this manifesto
‒ Share a common set of principles
‒ Uses a unique set of agile practices to implement these
principles
• Successful estimation for an agile project is like
software estimation for any project – you need to
understand the project properties and the practices
employed
9

Agile Software Development
• Usable chunks of software are developed in short periods of time
(sprints, iterations, etc.)
• Requirements are translated into user stories and become the
project backlog
• User stories deliver business value and are small enough to
complete in an iteration
• Customer works with team and reviews software regularly
• Each iteration focuses on the user stories that are currently the
highest priority of the customer
• Priorities may shift from iteration to iteration
• Agile teams expect and embrace change
10

Common Agile Practices
• Pair programming
• Continuous integration with automated testing
• Test driven development
• Daily stand up meetings
• Co-located teams
• Code refactoring
• Small releases
• Customer on team
• Simple design
11

The fact that your project is agile is
NOT a cost driver!
12

Methodologies
and Rules of
Thumb
13

Estimating Agile Software Projects
• Conundrum around all software estimates – when the first
estimate is required – information is incomplete
• Good understanding of project, technical and team
parameters is paramount to credible estimates
14

Estimating Agile Software Projects
• When the development team declares agility – how is the
estimator to respond
‒ Is the team truly agile – if so, estimate is easy
‒ Most agile teams are not quite that agile – especially in the
government space - program is likely held to some or all of the
following:
• Schedule Constraint
• Firm fixed price
• Fixed requirements (MVP)
‒ This second category of agile teams are those who have chosen to use
agile best practices within constraints of government contracts and
acquisition mandates
15

How to Adapt Estimation Methodology
• At the far left – the truly agile team.
‒ What is known
• Team Size
• Length of iterations or sprints
• Expected deliver date
• Expected release cadence
• Agile practices employed (conversation between agile team and developers)
‒ The estimators job becomes
• Apply their estimation methodology to what is known about the expected
schedule and capability
• Take into account affects of specific agile practices
• Offer agile team and decision makers advice about schedule feasibility and risk of
delivering expected capability
• Significant variance between the two estimation methods
should stimulate discussion leading to better convergence
16

How to Adapt Estimation Methodology
• At the other end of the spectrum
‒ What is known
• Capability requirements
• Schedule constraints
• Agile practices employed (conversation between agile team and developers)
‒ The estimator's job is not different than a traditional estimate
• Apply their estimation methodology to what is known about the expected
schedule and capability
• Take into account affects of specific agile practices
• Create a cost, effort and schedule estimate
• The advantage in this scenario is that agile team should
have collected significant metrics against which this
traditional method results can be compared – also
facilitating discussions that should lead to convergence
17

Focus on Value Driven by the User
18
Scope
Quality
Schedule Cost
Scope
Quality
Schedule Cost
Traditional Waterfall
(Adjust cost and schedule
to complete the scope)
Agile
(Align scope to fit the time box
allowed for a defined capability)
= Fixed = Variable

Estimators concerns….
• Size
‒ Though negotiable, there needs to be a starting place
‒ Calibrate for a team (e.g., 1 Story Point = XXX SLOC)
• Agile Team
‒ Size
‒ Capability (Velocity)
• Iteration Length
• Release Cycle
• Other team, project and program factors
‒ Like any other software development project
• Estimators job becomes determining
‒ Schedule feasibility
‒ Iterations required
‒ Uncertainty around proposed capability
19

Agile Cost Driver
Considerations
20

Agile Cost Drivers
• The fact that your project is agile is not a cost driver
• There are potential cost implications to adopting agile
practice
• Estimation team needs to determine which agile practices
apply and how they might impact cost and schedule
21

Agile Cost Drivers
• Agile teams tend to be highly skilled
‒ Hard to be a slacker in an agile environment
‒ Working closely with high skilled team members, learning curve for new
members is quick
‒ Input parameters to your model indicating team experience would be
affected
• Agile teams tend to have tool sets that are quite sophisticated
‒ This would be especially true on teams working with real time and safety
critical software as it greatly facilitates compliance to standards
‒ Input parameters around tools or automation would be affected
22

Agile Cost Drivers
• Co-location of teams should improve team productivity
‒ Culture of interruption
‒ Questions answered in real time
‒ Team cohesion increases
‒ Co-locating stakeholders and SMEs with development team creates a
real time IPT
‒ Well run stand-up meetings increase productivity and quality
‒ Cost drivers indicating distribution of team and communication
practices would be affected
23

Agile Cost Drivers
• Continuous integration with automated
testing should increase delivery
productivity
‒ Code is checked in frequently and builds are run
and test regularly before developers forget what
they changed
‒ Red tests raise red flags – team fixes them right
away
‒ Since little code is changed, errors are easy to
track down
‒ Fixes occur quickly
‒ Cost drivers focused on integration test complexity
would be affected
24

Wrap Up
• The Agile Paradigm is here to stay
• Current practices of agile, particularly in the government,
are limited, not necessarily truly agile
‒ Entirely reasonable approach, enabling the benefits of agile without
risking consequences of failed contracts or unmet expectations
• Estimators need to understand what ‘agile’ means:
‒ In the context of the project that is being estimated
‒ In the context of the agile team(s) working on the project
‒ In the context of the agile practices being utilized on the project
• The fact that your project is agile is not a cost driver, but it
should start a conversation about how agile practices may
influence your cost estimate
25

Contact PRICE®
www.pricesystems.com
1-800-43PRICE
arlene.minkiewicz@pricesystems.com

Backup
27

Useful Agile
Metrics
28

Team Metrics
• Many agile teams have retrospectives at each
iteration or sprint
• Agile team metrics are team specific
• Common team metrics include:
‒ Stories or story points per iteration
‒ Defects inject/removed during iteration
‒ Velocity
‒ Burn down chart
‒ Burn up chart
‒ Cycle time
29

Project Control Metrics
• Team metrics are not good for project control in cases
where there are multiple teams across a project
• Metrics can be normalized across teams for project level
• Common Project Control Metrics include:
‒ Epic/Release Burn Up Chart
‒ Epic/Release Burn Down Chart
‒ Product Backlog
‒ Changes to Product Backlog
‒ Defects injected
‒ Defects Removed
‒ Latent Defects Delivered to the field
‒ Cumulative Flow Diagram
‒ Number of Features Delivered
30

The fact that your poject is agile is not (necessarily) a cost driver arlene minkiewicz

More Related Content

What's hot (20)

Similar to The fact that your poject is agile is not (necessarily) a cost driver arlene minkiewicz (20)

More from Nesma (20)

Recently uploaded (20)

The fact that your poject is agile is not (necessarily) a cost driver arlene minkiewicz