Let's start with a bold invitation to make sure that during the next half hour, you think about some of the things that I'll be talking about with the intent of walking away from the session today, really having a deeper understanding, and really having some tools to take back with you as you leave this conference to be able to address this critical issue. This certainly is not the most popular topic, but it is one of the most compelling topics in terms of it being probably the biggest impediment to enterprise-wide agile adoption and certainly impacts DevOps as well as the enterprise in general. So I'm having a little trouble with my clicker here. Great.

So as we get started with this goal, again, is everyone cool with the idea of trying to make this session simple and short with the spirit of taking a very complex topic and being able to reduce it down to some very simple rules that you'll be able to take away from this session? In that spirit, I'd like to invite you to try to keep this interactive, and also I'll keep the presentation slides brief so that we will allow plenty of time to handle questions and to actually extend some of the traps and some of the mental models that we'll be going over to address critical topics that are also of interest to you in terms of regulatory guidance and in terms of compliance. Because some of the topics you'll be learning about here today, especially the mental models that we fall into that prohibit us from seeing the answer, would be very helpful. Let me start by giving you a little bit of background of what is the problem we're trying to solve and a little background of when it all started.

You may recall in the '70s and '80s, as software development moved out of the back office and evolved not only into the front office, but to create a competitive edge for ourselves and our organizations, significant interest started to be being paid by the governance bodies in terms of ensuring shareholder investment and investor confidence, really, across organizations. So the spirit of this guidance that you'll see has now impacted all software development worldwide, not only in corporations but in nonprofits. The spirit of the intention of this guidance was to come up and ensure consistency across organizations in terms of reporting project labor cost accounting on agile projects in the spirit of ensuring consistency across the different companies and organizations throughout the world. Now, the problem comes up with the fact that in the '80s and '90s, when these guidelines were being crafted, you may recall that Waterfall was the dominant software development methodology of choice.

So it's only natural that the individuals who were tasked with developing this guidance wrote it in the language of staged gate of framework, which was very easy to implement and interpret while we were developing using Waterfall methodologies, but became quite problematic when our financial officers and our agile accountants were tasked with the challenge of interpreting this guidance with an agile lens. So that's what we're going to talk about today. Kind of not only what the heart of the guidance is, but how we need to suspend some of the mental models of how we are different using agile software development methods. Instead, look at the true spirit of the guidance and understand how we are the same and how you can take away from the session today some very simple rules, even a simple decision tree that we have along with this presentation to be able to understand and interpret the rules through an agile lens.

So it starts by having the essence of the guidance. This is not only SOP 98-1, but ASC 350 and also other guidance throughout the world is that there are three stages of an IT project defined. The language they've used is to define the preliminary stage as those costs that must be expensed. Because essentially what happens in the preliminary stage is feasibility analysis.

Those things that we might label opportunity assessment or R&D costs to assess the feasibility of success with being able to take on the technology solution that we plan to build or the asset that we're going to be developing. So any costs that are incurred, project labor costs or any costs incurred during this feasibility analysis phase must be expensed. The next stage is the application development stage, and in that stage, most of our project labor costs can be capitalized. The key is to understand the relevance of those project labor costs to the creation of an asset which we can then put on our books and depreciate over time.

The third stage, and one that most impacts DevOps, is the post-implementation stage. And the language in that stage is written heavily using terms like deployment. But again, the spirit of that stage is that the asset has been moved into production and is available to the end users who are actually gaining benefits from that asset that we've created in our software development life cycle. So it's important to remember the spiritthere, as opposed to the dense language that confuses most of our finance folks and our auditors.

So if we take responsibility to kind of understand that, let's start by highlighting the trap that almost all agilists fall into and almost all organizations fall into. We think we understand the differences in terms of being agile and practicing the agile software development life cycle. So the first thing we do when we're faced with staged gate language is we say, "No, wait a second. You don't understand us." In an agile world, we iterate continuously, and we continuously grow, and we continuously learn.

But we do a little bit of analysis, a little bit of design, a little development, kind of intertwined throughout each of the sprints or the iterations that we learn from in terms of our agile practices. That kind of thinking actually creates a trap for ourselves because although it's true, we're losing the spirit of the intended purpose of those guidelines and regulatory mandates to begin with, and that is to make sure that we don't start a project until it's feasible for us to actually create an asset, reasonably feasible. So if we take on the position of advocacy, just like the last panel was talking about, as opposed to adversary interpretation with our finance folks and our auditors, and we think about how to solve this problem from the point of view of what an auditor needs to know and what a CFO needs to know, and help them understand agile in their language, in the way they think, understanding their principles of conservativism and materiality, we take a look at what is the real solution that we need to put forward in terms of an agile, very clear, bright line that delineates when we move from how it is we're going to create the project from what it is we're creating.

So those of us who practice agile understand that there's a clear, bright line between what we need to develop and how we need to develop it. That clear, bright line is at the design storming phase or when you actually have the right people in the right room to start to design the solution. And everything thereafter, all of the work of the work, any project labor costs that are vital or critical to the creation of an asset can be capitalized. This actually simplifies the interpretation of the rules, and it creates for us consistency and clarity in ensuring that we don't waste any time from our valued DevOps engineers or development engineers in terms of worrying about what is the work of the work that they're doing, how much of it should be capitalized, and how much of it should be expensed.

Generally, all of the work that starts once a project team has been pulled together or once a new body of work kind of flows to an intact product team, the work of the work then in terms of designing, when they move conceptually from what it is they need to create, thoroughly understanding that, to how it is they intend to create it in terms of architectural reviews, architectural discussions, tech stack diagrams, or any other kind of understanding of how it is they're going to create that work, create the asset that's going to be produced as a result of their software engineering effort, is capitalizable. Very simple. Let's walk through those tasks and activities that are not capitalizable, so by exception, based only we understand the simplicity of how to enforce this simple, bright line.

Technically, any administrative tasks need to be counted as overhead, and administrative tasks are expensed. But as we mature in our adoption of agile, we generally find that we've been successful at moving a lot of those expense tasks out of our life cycle, right? Very rarely do we have administrative assistants that are responsible for scheduling meetings or scheduling rooms. Any of that work, we generally adopt ourselves very dynamically, shared across the team, and minimize the expense work there, maximizing the time it is that we spend creating the asset, really creating valuable assets for our customers, focusing on customer value creation.

Other exceptions that we would need to expense include training and include manual conversion of data, and obviously any leave time. If any of our engineers or DevOps engineers are taking leaves of absence, then that time needs to be expensed. But virtually everything else, if it can be traced back to the creation of an asset, is capitalizable. So we can move away from the constraints of having to either have our engineers worry about it or even track time.

Time is no longer necessary to track relative to capturing kind of WBS code level or task-based level of hours spent because all of the hours, the intent is that all of the hours that our engineers are spending between these clear, bright lines here are capitalizable.So the next question is closer to home in DevOps, and that is what really is deployment and where does that second bright line need to occur to delineate when the asset is fully accepted in production and ready for turnover, let's say, from the technical development team to the production support or ops team? Generally, it would be advisable to set up a rule for your organization that would represent the typical amount of time or relative amount of time it would take to actually deploy that asset, depending, obviously, on how automated your deployment is and how accurately you're able to test user acceptance test in production. But you'd want to make sure that all of your performance criteria were met and that you were ready to go and move this asset fully into production. At that point in time, the second bright line indicates that there's been user acceptance test and that asset is now fully deployed and in production, and then any maintenance or bugs that come up in production would be tracked as expense.

Does that make sense? Very simple rules to tackle a very complex challenge. Yes, Sam? So, Pat, what if you're deploying weekly?

Ah, yeah. Excellent. If you're deploying weekly and there's measurable benefit of that asset to the customer, your finance folks and your accounting folks would use their principles of materiality to determine at what schedule they would want to actually bundle those weekly deployments to start to depreciate the asset. So just as the last group was kind of sharing the importance of us to build strong, important, and trusting relationships with our finance folks, that should be a finance decision.

The key there is that you've developed, that we have developed the asset that's fully in production and deployable, if you will. But the finance folks need to determine the feasibility of what makes the most sense for them in terms of starting that depreciation cycle, because the work of the work is then on their part to actually work on all of the features that we're creating for that asset, what the depreciation schedule would look like, right? But from the IT point of view, the clear bright line has been passed, and then the finance and the tax folks, because there's some tax impact as well. That's where it's so important for us as IT professionals to maintain a very strong and trusting relationship with our finance and financial reporting and accounting business partners.

Does that make sense? Good question, Sam. Other questions on this? I have a question.

Yes. Thank you. Thank you, Damon. I heard some core story about we were able to walk into the CFO's office and hit him with a app and explain how you had this massive pool of messy OpEx and how you were able to turn much of it into CapEx.

Cool. And made a big impact on actually the bottom line of the corporation. Let me- That story would bring home for a lot of people in the room. Excellent.

Thank you, Damon. Damon is kind of reminding me of how I became enthusiastic about this topic to begin with. It was critical for me to solve the problem in the role that I had at the time as an executive at a retail company, let's say, a local kind of Fortune 100 retail company. It was critical for me to solve this problem real time, and I was surprised at that time to find that there was no one else who had solved it, who had really approached it.

I contacted all my typical friends in the industry and gurus and was under pressure to actually come up with this solution in order to address an audit that we were facing with one of our more large-scale projects. And in so doing, what I started to do is work with our finance folks and understand the compelling advantage to being able to crack this enigma, if you will, and to solve this. And subsequent to that, so one of the things I might toss out might be for you to think about what is the current cap expense ratio in your organizations today? Kind of that's what Damon is kind of referring to.

By solving and resolving this problem consistently, it takes a little time of understanding all of the drivers that influence this, but you can definitely improve the competitive advantage and the consistency of financial reporting in your organization by deeply understanding this and then addressing it consistently. Not only do you save a lot of time and wasted energy in unnecessary friction between the accountants and the finance folks and IT, normally many of you might recognize that that is a typical source of friction because accountants and auditors don't always fully understand the way we work in an agile world. And if we can take the time to step back and look at how some of this guidance is written with staged gate language, we can certainly understand and advocate for helping our finance and accounting friends understand agile better. We can eliminate and kind of remove at the source some of that friction and then work together, as Damon's talking about, to really create a strong competitive edge.

As we've heard throughout the day today and yesterday, that CapEx and OpEx effective management is generally perceived as a critical business value.Certainly imperative to driving agile adoption, and even more so why this topic has become very important to me, and you'll see the Agile Alliance logo on these slides, is that we recognize that this is one of the most serious, if not the most serious impediment to widespread organizational enterprise adoption of agile. Because until organizations can work with all the right people at the table to come up with an internal capitalization policy and really make sure that they embrace and define a solution that's unique to them, many companies are not enabling these multi-billion dollar projects or very large-scale projects to leverage agile because they're not confident that they have the understanding that's necessary, which we're outlining here. So I'm a member of the Agile Alliance board and have developed a program that the Agile Alliance is supporting, to offer this solution to everyone and to offer guidance and support in terms of helping to identify and take advantage of this. It's a very complex subject, but what we've done is we've reduced it down to very simple rules, and you can see from this chart, by having two clear, bright lines and using the language of finance to work together with them, and accounting and financial reporting in your firms, to come up with a solution that is defensible, auditable, and creates a significant competitive advantage by making sure that you don't over expense.

Oftentimes, accountants will err on the side of conservatism, and if they don't have a really thorough understanding of how to accurately track project labor costs for very large projects, they will sometimes over expense or err on the side of expensing completely so as to mitigate any kind of risks of having to re-report. Does that make sense? Thank you for that question, Damon. So basically, in a nutshell, when can project labor costs be capitalized on an agile project?

There are a couple rules, and we've distilled these rules from this very dense and thick legalese language of the guidelines that are out there. Once your team, once your organization, has a high degree of confidence and an expectation that the project can be completed... Remember again, compared to today, where the technology is significantly more feasible than it was in the 1980s and '90s, where some of these rules were starting to be generated. We're pretty confident that once an opportunity assessment's been done, once an idea's been generated in your organization, there's a high degree of confidence that you have the technical capability of actually being able to deliver it.

But that is a prerequisite, and you want to make sure that you do that reality check as you start. New or updated, upgraded software functionality is being developed. This is one of the rules that clarify for us that these capital guidelines are in effect for any new significant functionality. They would not be in play for just, let's say, a software upgrade without any new measurable functionality in terms of a new feature set.

Again, very easy to pass this hurdle in our current world of agile development. There's a high probability that the project is going to be complete or that the asset is creatable, and that the preliminary project stage is complete. And again, if we look back on that clear bright line there, that preliminary project stage is after we've determined what it is we need to develop and have clarity around the high-level epic stories of the features that we need to develop for that asset. And we have assembled the right technical team, and they're working together on the architectural design, sometimes called design storming, or the deeper dive of exactly starting to architect how they're going to develop this solution.

Understanding that developing how they're going to develop that solution is indeed critical to the value of the life of the asset. Everything thereafter, as long as the work of the work can be attributable to creating an asset and deploying an asset, it is capitalizable with the exception of leave time training,And then management with the relevant authority needs to authorize the commitment and spending of funds. It is critical to memorialize or capture that point in time knowing that all the project labor costs after that point in time should indeed be capitalized. In fact, if your organization is embracing capitalization, there needs to be a consistency of that, and that should be applied consistently across the board.

So generally, I recommend that that memorialization be referenced in an email or in any of the product tools that you might be using for story management or portfolio management, where you mark that as a milestone if nothing else, so that you know clearly at that point in time on that time date stamp, your project or this product work has been considered capitalizable. So, questions, more questions on this. You can find more documentation. In this document here, I've intentionally kept it very simple to encourage that we have at least six minutes to answer questions.

You will find maybe 20 slides at the back of this deck, including a decision tree, very simple rules, which can help you interpret these relative to your organization, and working with your accountants and your finance folks, and possibly even your auditors and your financial folks. I generally recommend starting with a technical accountant because it's their job to fully understand this, and if you pair with a technical accountant and help them to understand Agile, you're going to be amazed at what you can achieve by working together as a pair. So there is a lot of content here that will be available for you with deeper dive FAQs and questions, but let's use this time together. We've got about five minutes.

I'll wrap up by saying what I'd like to hear from you and what I need your help on is hearing any success stories. Having you share success stories, if you have effectively solved this problem for your organization, it would be great to share your story. Hopefully, even allow us to share that on the Agile Alliance website, so that others can benefit from the great work you've already done. Or if you are still struggling with this challenge and you could use some help by following up and having us kind of help you with that and then share your story on the website.

We can create a rich community of practice that can accelerate the use of this standard, this recommended solution, across industries, across the world. So on that note, here is my contact information and Walt Wyckoff's information. We can help you with any questions that you might have, and we've got four more minutes for questions from the audience. So what questions might you still have?

Questions? Yes. Okay. So we practice this, or we try to practice this.

Awesome. But it's very, very painful for, let's say, the developers, the QA, anyone working on a project to think about this on a daily basis. You are absolutely right. The question is, we practice this, but it is very, very painful for any technical member of the team to even think about this.

You are absolutely right, and that's why these clear, bright lines enable you to ensure that your technical folks are focusing on exactly what they need to be focusing on, right? Creating the asset, testing the asset, deploying the asset. When done correctly, no one on the technical team should ever even think about whether the work they're doing is capital or expense, right? When you implement these clear, bright lines, then technically once the line's memorialized, if you have a way to track leave time, let's say.

That's important, but that probably shouldn't be too painful for your developers to know whether they're working or not. It's that simple. So they may always be working, but there may be three or four projects that you drive to, correct? Ah, yes, exactly.

Different lines. Exactly. Location, right? Absolutely.

They have to associate their hours worked with certain projects, so they're not always aware of those moving lines, and I think that's something I'm trying to figure out a way to help out with. Excellent. I better understand your pain point now. Thanks for that clarification.

Ideally, we could all work in a perfect world where a project team is dedicated to one creation of an asset and create that asset in these rapid... But oftentimes, especially in shared service environments, we're working across multiple projects. So that still is an opportunity for simplification. If, for example, when I was leading DevOps for an organization, and I worked very carefully with my release managers.

There was, let's say the release managers were spending time implementing features from maybe 10 products across an environment for that full deploy and test. What I would do is work with my accounting partners and come up with an algorithm that was sufficient. Again, you can trust that your business partners, your finance folks, and your accountants will work with you to solve a problem, to come up with a much more effective solution than you could do on your own. And in working with them and building that strong, trusting relationship, they will help you come up with a very simple algorithm so that your technical teams don't need to be tracking hour by hour-Our friends in finance have a materiality principle, and that is if it takes more to track the time than it is of value to depreciate the asset, then simplifying it makes sense.

So they will work with you, your accountants will work with you to simplify that. Was that the scenario that you were referring to? Thank you for the question. Other questions?

We've got about a minute left. Time for one more probably, right, Damon? Yep. Cool.

If nobody goes, I'll go. Go for it. All right. So self-service, right?

So if developers are all driving towards this kind of self-service deployment model, continuous delivery, and your operations teams are building services that can be consumed by those folks, kind of the unicorn model that people are all aspiring to and we've been hearing about, how does that work here? In terms of being able to go back to business and say, all that stuff used to be OpEx, is that now CapEx? CapEx. Absolutely.

It's a great question. The definitive answer that we always need to ask ourself is are we creating enhanced functionality for the customer? And your business certainly knows based on your demos and what's being deployed, where there's new functionality being delivered and how that new functionality should best be managed or written off or taxed. So there is a significant opportunity as we embrace this and better understand the implications here to eliminate waste from our processes.

Look at all the stories we've shared here so far in the past two days. Phenomenal amount of waste is being exposed and pushed out of the system, which significantly impacts our cap to op ratio, right? CapEx to OpEx ratio. Absolutely.

Again, the spirit here is have everyone doing what they do best to create value, automate the rest, and simplify to the extent that you make this absolutely seamless so our technicians, our engineers should never have to worry about the work of the work. What am I doing? Capital or expense work. Cool.

Thank you, Pat. Thank you. Appreciate it. Thank you all very much.

Great outreach. Thank you.