Pat Reed

Thank you so very much, and thank you all for being here on probably a topic that's not the most popular, but one of the most important in terms of enterprise agility and DevOps in particular.

I'm going to go through a lot of material fairly quickly in the hopes of leaving plenty of time for questions. Hopefully this topic will provoke some questions.

Some of the quick headlines behind this, as you've already mentioned: this is the number one enterprise blocker to organizational agility and enterprise agile. At the C-level, the CFOs just don't know how to properly capitalize for agile.

We're going to do a deep dive into why that is and offer you a playbook, as well as some very simple guidelines to help your C-level executives understand this to the greater good of the organization, DevOps, and agility.

Why is a playbook so important? Bottom line, the world today is so complex that some of the rules that were written into the government guidance and the regulatory requirements have not changed. The language of the guidance has not changed, but the world has.

Bottom line, organizations fall into the trap of trying to solve this complex adaptive problem with a very technical, deconstructive approach to interpreting the letter of the law, or the language of the guidance. That creates a block to organizational agility adoption. Sometimes it also raises polarities.

This issue truly is blocking our effective utilization of agile throughout the organization worldwide, by the way, and requires us to break through some mental models and come up with a filter for interpreting the guidance that can be extensible as well.

We're going to be applying this first to this compelling blocker, but we'll be talking, as well, about how this might help us deal with some of the other complex issues and challenges that we're facing, like the conundrum of whether to go to the cloud or maintain those enterprise assets in-house. What's the best approach for organizations?

There are significant benefits, which I think will emerge throughout the next half hour as we talk.

I'll get right to the heart of the issue in terms of the solution. When we look at an enterprise approach to adopting agile, the bottom line is, once we've proven the R&D, the research and development, and once we've done the feasibility analysis, and I'll reinforce the word feasibility, that we've actually funded work to be done, all of the work of the teams, the dev teams and the ops teams, in creating that capitalizable asset and getting it into the hands of the customer, which is what agility is all about, all of that work is actually capitalizable.

But because interpretation of that work is difficult, sometimes large organizations, very large organizations with a very high degree of capitalization at risk, choose to expense all of their agile projects because they don't know how to interpret it.

Bottom line, at the preliminary project phase, when we talk about what we're going to do, the feasibility of what we're going to do in terms of investing our resources into creating an asset, the work of the work there, the feasibility analysis, is expense.

But everything else, when we move from that what to the how, we move through that first clear, bright line there, and from the design storming, the project kickoff, whatever it is your organization uses to demarcate that point in time when the team starts to do the work, literally all of the work of the work that can be traceable or is important back to creating that asset is capitalizable.

We're going over this to the point that it really makes sense, whereas sometimes the language of this is not correctly interpreted.

The post-implementation stage, when we do that handoff from the ops team to the extended support team, is defined by the organization in terms of moving it into production.

Bottom line, if you can see those two blue lines, we use the language of calling those the clear, bright lines that help CFOs and accountants and auditors and regulators with capitalization audits realize that all of the labor costs that happen between those two bright lines are capitalizable with two very few exceptions.

Training costs, actually training people, are not capitalizable. That's expense. And then leave. If the individual employees are on leave, that's not capitalizable. That's expense as well.

In a nutshell, the simplicity of that: a very quick, overly simplified financial model to help make sure we're all aligned on what we're talking about when we delineate OpEx and CapEx.

CapEx is the labor cost expense that went into creating a capital asset that actually then, once the asset is defined and capitalized by an organization, it hits the bottom-line profitability of that organization.

Expense, on the other hand, operating expense, never gets translated into a material, valuable asset for the organization, and consequently, the bottom-line profits of that organization is impacted.

Does that make sense to everyone?

What we want to do is we want to maximize CapEx and minimize OpEx, and we do that naturally as we embrace agility. But this talk is going to talk through how we can really operationalize that.

In a nutshell, let's say we'll take a year, 2010, and we had a $50 million investment in creating an asset, and we generated $100 million of revenue that year.

That first year, 2010 profitability was the $100 million minus $10 million of CapEx, as opposed to if we weren't capitalizing and we were treating that as an OpEx, all of the cost of creating that asset would have to be written off in the current year, and that year we would have only had a $50 million profitability on our bottom line.

Does that make sense?

So we take that expense, that CapEx, and we can depreciate it over a five-year life cycle, or three to five years is the typical length, sometimes longer. But considering the pace of technology, that's usually a safe point.

This, in a nutshell, helps us see how capitalizing costs can effectively impact the bottom line. Particularly important in the event that all of us know in our worlds that technology is becoming an increasingly important enabler to creating innovation and business value. We're going to see that exponentially jump over the next decade with the Internet of Things.

This is becoming increasingly important. I have one client that currently invests $10 billion a year in IT capitalization, so you can imagine how this bottom line, just using this simple formula, could impact the bottom-line profitability of major corporations to the tune of billions of dollars, which is truly impactful.

Now maybe it starts to make sense why this is becoming the number one hot topic out there of enterprise agility. Because if organizations don't understand this, and if we don't effectively invest building trusted partnerships with our auditors, and our financial reporting folks, and our finance folks, and our accountants, we'll never solve this complex problem.

Reality check two is a lot of people... So the first reality check is the opportunity is profound, and agility enables our ability to do this.

Second reality check is a pattern that I've found all organizations fall into. They fall into a mental model, a misunderstanding of agility, thinking that we do a little bit of analysis every day as we're developing and operating our asset maintenance or delivery process.

But the language that we confuse ourselves with is, yes, we do analysis all the time, but that analysis that we're doing in the creation of an asset that the teams are doing as they're working and finding the best way to create that asset is 100% capitalizable.

They get confused with the what analysis and the how analysis, and they inadvertently or indirectly assume that we now need to ask our technology engineers to track their time, every bit of their time they spend doing analysis versus design versus development versus test versus deployment.

That is totally unnecessary, an extreme waste. It actually distracts our technical team members from doing what they do best, which is really creating the amazing assets that we need to create to differentiate ourselves and delight our customers.

This talk is about how we can create the partnerships and develop a relationship of trust so that we can develop a defensible, auditable, scalable, sustainable, and agile solution to remove this blocker that's out there to enterprise agility and to DevOps.

The quick capitalization playbook that I've put together for you to use, it works, again, not only just for solving this complex adaptive problem, but any other problem. For example, organizations that are challenged with understanding ITIL and how that fits in, or organizations who may be struggling right now with trying to look at the bottom-line benefit of moving to the cloud versus maintaining that asset schedule of depreciation themselves within their organizations.

Step number one, as we've been learning throughout the day yesterday and today: it's always about the people, and it's always about people working together to align and understand about why we're doing the work and why we need to interpret the guidance.

It's engaging the right people, making sure that everyone's at the table so that we don't dismiss our accountants and our auditors, but we actually engage them at the table so they truly do understand how it is we work, and they become delighted in the transparency of the practices that we practice in agile development and DevOps.

Applying lean systems thinking helps us to break through those mental mindset blockers and those blind spots that we have, in terms of helping everyone understand that as long as we're creating the asset, all of the work of the work is capitalizable. Zooming in and zooming out when we need to.

One of the things we've learned very effectively in agile development is design the test first. We should apply that practice in designing the solution for capitalization in your organization, and it works like wonders.

I've had a number of very large corporations apply this playbook very successfully in getting through the blockers that have been previously inhibiting them from convincing their very senior finance, accounting, financial reporting, and auditing leadership of the true benefits of agility.

And then discover simple rules. As I mentioned earlier, one of the reasons why this has become such a complex problem is that the solution is complex, and it requires us to apply simple rules to cut through the chaos. Whereas a lot of organizations and individuals fall into the trap of overly complicating or overly engineering a solution, we want to apply simple rules.

In this deck and in the appendix of the deck, there's a lot of technical detail and a real simple decision tree that reduces all of the guidance down to a set of simple if-then-else rules that you can help work with in terms of your organization to educate the folks that need to be, and to align on coming up with the right solution.

Co-create your solution with all the players at the table. It's very important so that you're working together with your finance and your accounting folks, and particularly your technical accountants. Because if in your organization you have a role called a technical accountant, ultimately it's their job to solve this, and their career depends on it. You're going to want to work in harmony and collaboration with those technical accountants as well as the other accountants and the experts.

And share knowledge and empower your people.

We'll go through the playbook pretty quickly, and you'll have this as a reference. But really start by understanding why and building the trusted relationships with the right people at the table to reduce the risk of over-expensing and to reduce the risk of bottom-line profitability and sometimes even survival, if not thriving, in your organization as they're dealing with the competition of the marketplace today.

Ultimately, it has profound impact on not only the company's bottom line, but on the company's or the organization's ability to actually invest in innovation and in creating future profitability for the organization. Not only that, but also to attract talent and help your talented engineers stay very focused on what it is they do best and never get distracted.

All of us have probably experienced that. What does an engineer feel like if we tell them they need to track every minute of their time? It's bizarre, right?

A, we don't get accurate data, and we get very unhappy engineers if they have to be distracted from the really challenging job of staying razor-like focused on creating assets.

Start with why. Engage the right people.

This is just a list of the types of people that you're going to want to engage as you work towards solutioning this challenge in your world. There's never a single answer, but you want to get the collective wisdom of all these roles at the table.

The importance of getting everyone engaged at the table from the beginning is that they feel as if they're creating the solution, and you're going to cut through a lot of unnecessary resistance. If you come up with a solution together, you don't have to defend it. You actually sell it together.

That's where the magic happens in terms of cutting through this complex problem with a very, very simple and defensible solution that is auditable.

Apply lean systems thinking. Help look beyond specific language challenges in various compliance or internal policies, procedure documents, to actually understand the intent or the spirit with which the guidance was written.

Remember, most of the guidance worldwide, certainly in the United States, emerged out of the 1970s and '80s and was written possibly in the '80s and early '90s. Anyone been around during that time? The world has changed significantly, but the language of the guidance has not, and that's what trips us up.

I'll give you a very specific example. In the 1970s and early '80s, if any one of you were there, the process of moving code into production was labeled deployment and was quite a bit different than the world of continuous delivery, continuous integration, and DevOps.

The guidance actually says deployment costs are expense, but intentionally, that was not the intent. The work that we're doing now in moving our code into production is a continuous process, and it actually is vital to the creation of the asset. Does that make sense?

The costs, in other words, the asset that we're deploying into production cannot be received into the hands of our customers until we go through that process. That process and all of the costs related, the DevOps costs related to that, are capitalizable.

Yet if the CFO is reading the letter of the law and they see the word deployment and they ask you, "Is that a deployment cost?" and you say, "Yes," then the conflict and the distrust starts to kind of exaggerate.

Does that make sense to everyone? That's just a simple example.

But if we apply lean systems thinking and why, and we understand the intent of the guidance, then we can align with all the right players in the room in terms of accurately interpreting it and being able to defend it in terms of each organization's interpretation.

This is a slide that I get from one of my very large international clients who've adopted this approach and designed the test first and were able to break through. This is a blocker. They'd been struggling with this for many years until they learned this playbook. They designed the test first, and here is how they've actually operationalized that test.

We're sharing it with you as an example of how one very large financial services company has solved it.

Here's an example of the simple rules, the decision tree, the actual code that I wrote here to reduce that very large guidance down to a simple decision tree that you can work into your test. But you always want to start with the test first, get everybody aligned on it, and come up with a very simple solution.

Amazingly, the complexity of this challenge and the impact that everyone is facing all over the world with it can be reduced to quite a straightforward, simple solution when we've got all the right people aligned on the right interpretations.

But most importantly, co-create your solution with your finance folks, your accounting folks, your PMO, all the right players at the table, and your auditors so that everyone is confident in the rigor, the discipline, and the transparency of your solution for auditability and defensibility.

That fear of future potential audits is what holds a lot of organizations back in terms of interpretation of the guidance.

And then share knowledge and empower your people. Once you've come up with a solution, it's important to share it with your tech leads, with your dev leads, with your ops leads, so that everybody understands with clarity how to properly quantify CapEx versus OpEx.

It's important, in particular, to define the control points that are necessary to memorialize the evidence that you're going to need for future audits.

Generally, I encourage organizations to put those control points at the DevOps level, at the release train, and/or at the front end, the first clear, bright line at the front end, with the PMO and the people that have the financial authority to actually fund the work that's being done.

Very simple. Hopefully that makes sense.

If we think about it relative to another problem that many of us are facing today, and that is as technology is changing and we're exploring either moving entirely to the cloud, or which cloud frameworks we want to move to, this same playbook can help address those problems and ensure that we're actually asking the right questions.

Most of us that are struggling with not only that challenge, but the agile accounting challenge, get distracted in that... I've heard this in several talks today: the iron triangle of scope, schedule, budget. We've all heard that. That's been a mantra for PMs forever.

They focus most of their attention on managing constraints. Everybody okay with the fact that we're reframing scope, schedule, and budget as actually constraints?

When we focus all of our energy or all of our focus on questioning the cost or the schedule or the scope, it's constraints. Jim Highsmith, one of the founding fathers of agile, has given us this agile triangle to make sure that we elevate our focus and we elevate our attention and ask the right questions to value and quality.

Notice quality has an equally important place in the agile triangle as the combination of all the constraints before. Yet so often our finance friends or some of our organizational governance bodies are focused so much on cost, schedule, and scope, or the cost, that they lose sight of the opportunities that we're missing because we're focused on the cost.

What we have an opportunity to do is to elevate the focus and elevate the conversation. I sometimes refer to that as driving through the rearview mirror, trying to drive forward through the rearview mirror. We need to elevate our focus on what is the cost of value, but truly be measuring value and not cost.

Once we do that by applying this same playbook, then amazing things happen in terms of setting ourselves up and our organization up for success in asking the right questions and not getting stuck between the trying to manage that triple constraint, which we've learned over centuries, or at least decades, that that is not truly manageable.

Bottom line, a few words to remember in terms of the time we've spent together today. Bottom line, the impact of this is significant. It is probably the number one blocker to enterprise adoption of agility, and until we apply these kinds of new ways of thinking and challenge some of our mental models that are getting in our way or members of our organizational team's way, we won't be able to solve it.

Once we do, the results are amazing in terms of improving bottom-line profitability and actually enabling the organization through agility, which we've learned how effectively that works.

Here's the help I'm looking for. We've made amazing advances in the area of DevOps, which at one time was a polarizing, challenging area of conflict, just like the area between accounting and agile is today.

What can we learn from our successes in DevOps, and how can we actually extend those learnings to create a community where we can help organizations cut through the chaos and the challenges that they're struggling with to truly enable them to effectively utilize agile for the greater good of the organization, and most importantly, for the greater good of their customers?

That's the help I'm looking for. Anyone interested in continuing the conversation or becoming part of that community, I would love to hear from you.

If time permits, are there any questions that we can take that any of this might have prompted?

You will all have access to the slides, and there's a lot more detail in some of the slides in terms of case studies and detailed tests and useful references.

Questions. Do we have any questions in the group?

Q&A

Q: Yes, please. Hi. So you talked about deployment having changed...

A: Yes.

Q: ...when the documentation was written to now.

A: Yes.

Q: And saying how that impacts your interpretation of how you capitalize it or not. So the fact that the documentation says it's not a capital thing, are you going to get in trouble if you start using your own way of judging it because we're changing definitions all the time? Like...

A: Yes.

Q: ...do we need to try and get the documentation changed, or can you just go ahead and do it?

A: Well, to your point, are you going to get into trouble? That is the whole reason why I'm pretty much talking to you guys today.

You certainly won't get in trouble if you ensure that in your organization, your financial reporting people understand it and they come up with the rules. You won't get into trouble. But this is a complex challenge, right?

These are defensible, auditable. We've passed that challenge, right? But the important part is aligning your organization's approach to this.

As the company that shared some of this material with me that I'm sharing with you, very large enterprises, I can't exactly say their names, but you definitely know who they are. The important thing is getting everybody aligned on the solution and ensuring that within your organization, you've completely rewritten, if you will, your internal capitalization policy, that you've memorialized the control points, that you've put in new controls around these points to accurately interpret the change of that language.

It's not simply expecting one person to say, "Aha, now it makes sense. I'm just going to run with it." Then you would get into trouble.

But when you follow the playbook, get all the right people, understand why, craft the solution, challenge the old control points with the new control points. Does that make sense to everyone?

A lot of the old control points that were providing the appropriate mandatory compliance with the regulations that were written in 1980 are completely different. Where's the natural new control point? At the release. At that point of the release, right? Not scattered all over in the framework.

And so when we help auditors understand that, and we help auditors understand the transparency and the traceability that we currently use in enforcing our movement of code to production and starting to depreciate the asset, then that's what you're looking for, that alignment and that collaboration with all the right players.

Great question.