the economics of scrum - finance and capitalization

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

http://www.cprime.com/

Copyright 2013, cPrime Inc. 2

Who is cPrime?ENGAGED FOR YOUR SUCCESS


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


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


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


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


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


Cost of Change $

Analysis Design Code Test Install Maintenance

Project Life Cycle

Traditional

Agile

Lowering the Cost of Change

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

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


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


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


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

http://www.infoq.com/articles/agile-capitalization%23anch96301



http://scaledagileframework.com/capitalization/

http://scaledagileframework.com/budgets/

http://scaledagileframework.com/budgets/

http://scaledagileframework.com/original-whitepaper-lean-agile-financial-planning-with-safe/



https://asc.fasb.org/subtopicviewall&trid=2144505




http://dannorth.net/introducing-bdd/

http://www.law.cornell.edu/uscode/text/15/chapter-98

http://www.law.cornell.edu/uscode/text/15/chapter-98

http://www.law.cornell.edu/uscode/text/26/167





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