the economics of scrum - finance and capitalization
TRANSCRIPT
Instructor: Joe Vallone, MBA, CSP, CSMTwitter: @joejv
4100 E. Third Ave, Suite 205, Foster City, CA 94404 | 650-931-1651 | www.cprime.comThe leader in training and consulting for project management and agile
development
The Economic of Scrum - Finance and Capitalization
Copyright 2013, cPrime Inc. 3
Today’s PresenterJoe 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
Copyright 2013, cPrime Inc. 4
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
Copyright 2013, cPrime Inc. 5
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
Copyright 2013, cPrime Inc. 6
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
Copyright 2013, cPrime Inc. 7
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
Copyright 2013, cPrime Inc. 9
Waterfall vs. Incremental Delivery
Analysis TestsCodingDesign Deploy
Analysis
Design
Coding
TestsDeplo
y
Sprin
t 0
Analysis
Design
Coding
TestsDeplo
y
Analysis
Design
Coding
TestsDeplo
y
Analysis
Design
Coding
TestsDeplo
y
Analysis
Design
Coding
TestsDeplo
y
Maint
Capitalize
Copyright 2013, cPrime Inc. 10
Effect on P&LHow 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
Copyright 2013, cPrime Inc. 12
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
Copyright 2013, cPrime Inc. 13
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
Copyright 2013, cPrime Inc. 14
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
Copyright 2013, cPrime Inc. 15
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.
Copyright 2013, cPrime Inc. 16
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)
Copyright 2013, cPrime Inc. 17
Simple Rules1. The nature of work performed in the Preliminary and Post Implementation phases is primarily Expense2. 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
ANDCompletion 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 plannedWork effort is directly related to asset /product design, development, testing or implementation/integration (except for administration,
overhead, training and data conversion costs) CAPITALIZE ELSEExpense
Copyright 2013, cPrime Inc. 18
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!
Copyright 2013, cPrime Inc. 19
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
Copyright 2013, cPrime Inc. 20
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
Copyright 2013, cPrime Inc. 21
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
Copyright 2013, cPrime Inc. 22
Cost of Change $
Analysis Design Code Test Install Maintenance
Project Life Cycle
Traditional
Agile
Lowering the Cost of Change
22
Copyright 2013, cPrime Inc. 23
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
Copyright 2013, cPrime Inc. 24
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
Copyright 2013, cPrime Inc. 25
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
Copyright 2013, cPrime Inc. 26
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 FormatEnd result: more verifiable, better documented production data and more closely aligned with customer value
Copyright 2013, cPrime Inc. 27
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
Copyright 2013, cPrime Inc. 28
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
Copyright 2013, cPrime Inc. 29
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
Copyright 2013, cPrime Inc. 30
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?
Copyright 2013, cPrime Inc. 32
Agile Planning Framework
32
The Planning Onion
Vision
Daily
Iteration
Release
Roadmap
Business unit determines the program and/or product vision
Team determines how to break it up into multiple projects and/or releasesTeam defines and plans the upcoming Release.
Team plans and executes the current iteration
Team manages work daily
Copyright 2013, cPrime Inc. 33
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
Copyright 2013, cPrime Inc. 34
Agile Maturity Levels
Zanshin (aware)A state of awareness.
Shu (obey)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.
Zanshin(Aware)
Shu(Obey)
Ha(Break free)
Ri(Transcend)
*The instructor decides when the student moves on from phase to phase, not the student.
Copyright 2013, cPrime Inc. 35
Agile Maturity Map
Zanshin Shu Ha Ri
Behavior Product Development Iteration Planning Product Management Technical Excellence
Copyright 2013, cPrime Inc. 36
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
Copyright 2013, cPrime Inc. 37
Example Quarterly Improvement Plan
Assessment Focus Area
Task Owner Release
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 1Attend Backlog Grooming class to enhance team skillset. Tad 1
Technical Excellence
Establish a Stage Environment. Stephanie
1
Establish automated testing QA. Ron 1
Copyright 2013, cPrime Inc. 38
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-plannin
g-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