The Economics of Scrum - Finance and Capitalization

The Economic of Scrum -
Finance and Capitalization
Instructor: Joe Vallone, MBA, CSP, CSM
Twitter: @joejv
4100 E. Third Ave, Suite 205, Foster City, CA 94404 | 650-931-1651 | www.cprime.com
The leader in training and consulting for project management and agile development

Who is cPrime?
ENGAGED FOR YOUR SUCCESS
Copyright 2013, cPrime Inc. 2

Today’s Presenter
Joe Vallone, Agile Coach
• Over 20 years of Software Development and
project management experience. Agile
experience since 2002
• Undergraduate Engineering, USF
• Graduate MBA, Cox School of Business, SMU
• Certified SCRUM Professional (CSP, CSM)
• Experience leading Agile Transformations at
Nokia, AT&T, American Airlines, Microsoft
• Previous Agile/Scrum opponent now proponent
• Certified SAFe Program Consultant (SPC)
• Have implemented both SAFe and CIF/Path to
Agility

Definitions
• CapEx – Capital Expenditure
• Capitalizing the cost of the asset (software)
• Spread the cost of the asset over its life
• Reduce tax liability against future revenue
• OpEx – Operational Expense
• Take the hit now
• Expense in the current period
• Too many expenses erase profitability and destroy shareholder
wealth

GAAP, FASB, ISAB – Oh My!
• Financial Accounting Standards Board (FASB) interprets the
laws to provide Generally Accepted Accounting Principles
(GAAP)
• International Accounting Standards Board (IASB) interprets the
international laws to provide International Financial Reporting
Standards (IFRS)
• FASB and IASB
• FASB 86 – Defines standards for software to be sold or otherwise
marketed
• IAS 38 – Intangible Assets

Agile Software as an Asset
• It’s a common misconception that Waterfall projects are easier
to capitalize
• GAAP and IFARS are slanted towards Waterfall capitalization
• General Rule:
• If you can capitalize a Waterfall Project, you can capitalize an Agile
Project
• More accurately, more transparently, and with finer granularity

The Economics of Agile and Lean
• Why does this make sense?
• Projects and Programs fit into one of 3 categories:
 Make money
 Save money
 Regulatory compliance
• Software is (generally) a long term investment
 Spend money up front to receive profit later
 Conversion of assets: cash -> software
• Potential reduction of tax burden via depreciation

Value Delivery

Waterfall vs. Incremental Delivery
Analysis Design Coding Tests Deploy
Deploy
Tests
Coding
Design
Analysis
Sprint 0
Deploy
Tests
Coding
Design
Analysis
Deploy
Tests
Coding
Design
Analysis
Deploy
Tests
Coding
Design
Analysis
Deploy
Tests
Coding
Design
Analysis
Maint

Effect on P&L
How can capitalization of software assets can limit your tax
liability?
• Deprecation
• Distributing the cost over the life of the asset ( software)
• Becomes part of the declared assets of the company
• Effect on P&L: Agile vs. Waterfall
• Agile and Lean Programs and projects reduce waste
• “All we are doing is looking at the timeline, from the where the
customer gives us an order to where we collect the cash. And we
are
reducing the timeline by reducing the
non-value added wastes.” —Taiichi Ohno

Effect on P&L Multi-Year Scenario
Credit: Dan Greening

Why Should We Care?
• Misunderstandings in how to track and report agile project costs
have cost companies millions of dollars in improper taxation
• Better use of money, increases shareholder wealth and makes
more funds available internally.
• Poor capitalization rules create choppy income statements for
companies, making them look poorly managed
• Company assets and expenses look unstable
• Expensing the wrong things destroys shareholder wealth

Why Don’t Firms Capitalize?
• Misunderstandings
• Agile projects are difficult to track CapEx and OpEx
• R&D is an expense - Nokia
• Innovation time is an expense – Nokia/AT&T
• Google 20% Rule
• Gives finance greater control and visibility on innovation
• Innovation Sprints

What Can be Capitalized?
• Longer term software projects that are designed to produce
revenue or cost savings
• Adding features which will increase revenue or cost savings
(i.e. business value).
• Hardware/Infrastructure (maybe)
• If it is tied to software features which are are being capitalized

What Can’t be Capitalized?
• Sprint 0, Release and ART Planning Meetings
• Your team fixes regression bugs in a released product, while it
develops new features,
• Your team is creating a product for international release, and is
localizing the product for multiple languages,
• Your team (not just its software) manually converts data from one form
to another,
• Your team helps train people to use the software,
• Your team participates in operations activities beyond deployment,
such as monitoring, reporting, backup, machine configuration,
• Your team performs routine Sarbanes-Oxley (SOX) or security reviews
[15 USC 7211],
• Your team refactors code unlikely to be relevant to new functionality
(you probably shouldn’t do this anyway),
• Your team modifies software to support individual customers.

When to Start Project Capitalization
• If we are following Scrum, we can start capitalization in
Sprint 1
• Assuming sprint 1 has points, it will be delivering value.
• The Project has been authorized and funded
• It is expected that the project will be completed and the
software will be used to perform the function intended.
• New or upgraded software functionality is being
developed
• Note: solely extending the software’s useful life without adding
additional functionality is a maintenance activity (OpEx)

Simple Rules
1. The nature of work performed in the Preliminary and Post Implementation phases is primarily Expense
2. The nature of work in the Development Phase determines whether it will be Capitalized or Expensed:
Expense vs. Capitalization
» What How
People or Process-Centric Asset-Centric
Administrative Technical
Support Decision-Authority
» Discretionary/Supplemental Asset-Critical
3. Decision tree:
IF
Minimum expected life of 3 years beneficial use
New software functionality
AND
Completion of preliminary (expense) phase with e-mail from management authorized with appropriate spending authority to fund project
as evidence of readiness for design storming (triggering the development/capitalization phase)
AND
High probability that the product will be completed as planned
Work effort is directly related to asset /product design, development, testing or implementation/integration (except for administration,
overhead, training and data conversion costs)
CAPITALIZE
ELSE
Expense

Summary of Rules: CapEx vs. OpEx For Agile
Software
• CapEx
• Customer facing, revenue generating
• Long term economic value (greater than a year)
• You're selling software
• OpEx
• Sprint 0, Release Planning, Requirements Gathering
• HIP Sprints (SAFe)
• Short term software projects that receive no value
• Hybrid projects
• Need to track both!

Current CapEx and Project Staffing
• Force engineers to track hours (degrading their creativity and
productivity with mind-numbing work-tracking),
• Undercapitalize software development (leaving huge sums on the
table), or
• Reclassify past expenses and restate earnings (raising investor
questions about the stability of the company).
• Agile projects are not preliminary stage work
• Companies often capitalize the wrong thing or try to extend the
project beyond its useful life

Funding by Release vs. Project
• Pro:
• Acknowledges sunk costs
 Shut down the project at any point
• Don’t spend more than you need to
 Project is done when the value delivered < cost
• Con:
• MUST have Lean/Agile Finance department that understands to the
value stream
• Release funding must happen in hours/days not weeks/months
• Finance must collaborate with the Agile team

Funding By Project
• Pro:
• Only go to the well once (maybe)
• Total cost is known up front (maybe)
• Con:
• Need to be right the first time or risk going back to the well
• If there is money, people will spend it
 Temptation is there to continue spending, even after cost has
exceeded the value

Lowering the Cost of Change
Cost of
Change $
Traditional
Agile
Analysis Design Code Test Install Maintenance
Project Life Cycle
22

Story Point Capitalization
• Requires a paradigm shift
• Only assign points to business value stories
 See the “so that,” <business value> part of the statement
• Bugs and Spikes are relegated to OpEx
 No Points
• User stories must be written to deliver business value in order to
be capitalized
• Must apply to all projects as a policy
• User stories can determine if value is being added to existing
software
• Very important for capitalizing “internal use” software
• Velocity now measuring delivery of business value

Lead and Lag Indicators
• Velocity can be used as a lead indicator to predict scope and
value release
• Funding by Story Points, allows you to be predictable about
costs
• Both CapEx and OpEx
• Timesheets are purely lag indicators, inaccurate, and do not
provide enough documentation
• Agile projects are better documented and easier to determine
business value delivered

End of Timesheets
• Why?
• To increase accuracy 
• Not inherently evil, just misused
• Developers hate it
• Record every hour, or end of the week?
• Better correlation to points and velocity (over time)
• Velocity is an average and overtime will correlate to the
capacity
• Still want hours?
• No problem. Use ideal hours, they are already being
tracked

Why Auditors (and Finance) Will Learn to Love
It
• Dates are fixed, easy to track
• We know exactly which team(s) did the work
• Day-by-day task burndown
• Stories, Features, and Epics are traceable in the Agile tools
• PBI is well documented and easy to understand, thanks to User
Story Format
End result: more verifiable, better documented production
data and more closely aligned with customer value

Lessons Learned
• Large Airline
• Goal: only fund what we need. Return the unused project funds to
fund other projects
• Tried (and failed) funding by release
• Went back to funding by project
• Money NEVER got returned
• Took 3 months to get funding approved
• Lesson Learned: This only works if you have an Agile finance dept
• Large Mobile Phone Developer used 6 month rolling wave
budget planning.
• Seemed to work fine
• Week to 10 day approval cycle

Metrics and Models
• Standard ROI/Payback ignores risk and time-value of money
• Use Net Present Value instead
• Use sensitivity analysis to vet hurdle rate
• Mobile Phone Developer used 10% for familiar Software Projects
• Airline Used 15%
• Airline used Agile Metrics to track (and predict) CapEx
• Time to Market
• Planning Predictability
• Scope Released

Implementation Suggestions
• Training of Finance in Agile Frameworks (high level)
• SAFe – Scaled Agile Framework for Enterprise
• Training of Scrum Master in CapEx vs. OpEx
• Collaboration
• Finance MUST attend (at a minimum) Release/ART
Meetings
• Product Owners MUST treat Finance as a stakeholder and
inform them of changes to the release and sprint goals
• Metrics
• To track and predict sprint and release goals
• Project ROI tracking
• Did we achieve the value we said we would?
• Inquiring shareholders want to know
• Implement lightweight Business Cases

Next Steps
• Finance and business leaders are brought up to speed
• Could start capitalizing story points now, just need to sort out
which story points are delivering value
• Scrum Masters promote capitalization processes
• IT and Finance Leadership to provide project funding guidance
• CapEx, OpEx, Hybrid using lightweight business cases
• Only assign points to business value stories
• Increase the maturity of the Agile teams
• Especially in planning activities
• How?

Increasing Team
Maturity

Agile Planning Framework
Roadmap
Release
Iteration
3
The Planning Onion
Vision
Daily
Business unit
determines the
program and/or
product vision
Team determines how to
break it up into multiple
projects and/or releases
Team defines and plans
the upcoming Release.
Team plans and executes
the current iteration
Team manages work daily

Assessment Process
Teams Assess
themselves with
the help of a
Coach each
quarter
Team & Coach
plot their
maturity level
using Zanshin,
Shu, Ha or Ri
for each of the
five assessment
dimensions
Team & Coach
build a plan for
the team to
achieve the
next level of
maturity in 2
dimensions
The team
schedules a
follow-up
assessment for
next quarter
Coach & PM
Review Team
assessments
with Leadership
Team

Agile Maturity Levels
Zanshin
(Aware)
Zanshin (aware)
A state of awareness.
Shu (obey)
Shu
(Obey)
Ha
(Break free)
Ri
(Transcend)
A sound technical foundation can be built most efficiently by following a single route to that
goal.
Ha (break free)
At this stage, each technique has been thoroughly learned and absorbed into the muscle
memory, the student is prepared to reason about the background behind these techniques.
Ri (transcend)
In this stage, the student is a practitioner testing against the reality of his/her background
knowledge as well as the demands of everyday life.
*The instructor decides when the student moves on from phase to phase, not the student.
34
Copyright 2013, cPrime Inc.

Agile Maturity Map
Zanshin Shu Ha Ri
Behavior 
Product
Development

Iteration Planning 
Product
Management

Technical
Excellence


Assessment Focus Areas
Product Management
 Product Owner
 Vision, Roadmap, Releases
 Burn-up
 Product Portfolio Management
 User Story & AC /Requirements
 Prioritization
Iteration Planning/Review
 Iteration Planning
 Velocity
 Feedback - Feature Demos
 Improving & Adapting
Product Development
 Daily Standup
 Burn-down
 Task/Work & Quality
 Development Skills
 Productivity & Effectiveness
Behavior
 Teamwork
 Communication
 Self Organization
 Cooperation to Collaboration
 Accountability & Empowerment
 Productivity, Effectiveness, Speed
 Commitment to Agile Values &
Principles
Technical Excellence
 Continuous Integration
 Automated Unit Test
 TDD
 Refactoring
 Code Review
 Simple Design
 Collective Code Ownership

Example Quarterly Improvement Plan
Assessment Focus
Area
Task Owner Releas
e
Product Management
Keep current team together and continue
to use Agile practices to manage
maintenance/small enhancements.
Stephanie 1
Product owner grooms the backlog
regularly.
Tad 1
Planning & Review &
Product Delivery
Learn to appropriately apply KPIs in
planning discussions.
Tad 1
Attend Backlog Grooming class to enhance
team skillset.
Tad 1
Technical Excellence Establish a Stage Environment. Stephanie 1
Establish automated testing QA. Ron 1

References
• http://www.infoq.com/articles/agile-capitalization#anch96301
• http://scaledagileframework.com/capitalization/
• http://scaledagileframework.com/budgets/
• http://scaledagileframework.com/original-whitepaper-lean-agile-financial-planning-
with-safe/
• [ASC 350-40] Financial Accounting Standards Board, 350 Intangibles–Goodwill
and Other; 40 Internal-Use Software, (paywalled).
• [ASC 985-20] Financial Accounting Standards Board, 985 Software; 20 Costs
of Software to Be Sold, Leased, or Marketed, (paywalled).
• [North 2006] Dan North, Introducing BDD.
• [15 USC 7211] 15 USC Chapter 98 – Public Company Accounting Reform and
Corporate Responsibility (related to Sarbanes-Oxley)
• [26 USC 167] 26 USC § 167 – Depreciation
• [26 USC 197] 26 USC § 197 - Amortization of goodwill and certain other
intangibles
• [26 USC 179] 26 USC § 179 - Election to expense certain depreciable business
assets

Q&A

The End
• Thank you!
• Now, go forth and Scrum!
• Call or email if you need help—that’s what we do!
• Please fill out evaluation forms before leaving

The Economics of Scrum - Finance and Capitalization

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à The Economics of Scrum - Finance and Capitalization

Similaire à The Economics of Scrum - Finance and Capitalization (20)

Plus de Cprime

Plus de Cprime (20)

Dernier

Dernier (20)

The Economics of Scrum - Finance and Capitalization