It certainly could sound boring, Shane thank you, but it’s actually an incredibly important program to enable enterprises to adopt Agile. The intend of the program and the reason I got started in this in the first place was to address an enterprise blocker and as I’m hearing from a number of the members of the conference this year, it’s become the number one blocker that they are concerned with in terms of understanding how to address, to embrace Agile across the enterprise, and so what we will be talking about today is I won’t be offering director or specific Agile advice. Agilists need to work with their own corporate or company technical accounts to work out their own solution, but what I’ll be sharing is a solution that we found to work, that’s defensible and effective to help people sort of change their mindset around Agile Accounting and help them understand how to solve the problem for their organization. I tell you a little bit more about what the problem is Shane.
The problem is that Agilists as we embrace or our Agile Engineers and our Agile Project Managers and Scrum Masters, don’t necessarily speak the same language as our accountants and because of that we also, although we share some of the core values, the principles that drives accounting of conservatism and conservancy, accountants needs to err on the side of being conservative when they don’t fully understand how to interpret something, and because of that and because most of the guidance that’s been written by the various governmental agencies around the world, were written at a time when Waterfall was the predominant framework, they were written in very staged-gate Waterfall linkage, and accountants don’t necessarily have a full understanding of how we work and how we create value in an Agile method using Agile methods, and that’s compounded by the fact that it doesn’t fit the world that they are governed by in terms of the letter of the law, if you will, so the language inconsistencies get in the way and what often time happens as a result of that, is there is sometimes not the strong collaborative partnership that we’d like to see in an effective Agile enterprise adoption. So the solution that we are recommending or at least the approach that we found to work very, very well in adopting Agile Accounting practices….
That’s the root of the confusion and because if they don’t know how to reconcile that, resolve that confusion, then where has often happened is that very large enterprises with those very large budgets either say that we cannot adopt Agile and then we are going to have to retain our Waterfall methods that fit that language very well, and that’s exactly the essence of what prohibits enterprise Agile adoption for those larger scale projects, and if we really do want to scale to the enterprise and fully leverage the benefits of Agile, we’ve got to resolve that conflict so you’ve nailed it. That is the problem we are trying to solve and what we are offering is an interpretative framework that lets us get beyond the staged-gate language, the Waterfall language. And interpret use, enable us to use Agile in a very defensible accurate and even more effective resolution to address the true guidance or the true letter of the law that’s come down from a SEC or FASBI, whatever other governing bodies there are worldwide. This is not just a North America challenge, it’s actually sort of faced worldwide and as we go into more global most of our large organizations are span multiple global markets, becomes increasingly important to solve.
So the solution that we’ve, that has been used by a number of organizations very effectively, is to use an Agile lens to kind of get beyond that framework language, that staged-gate framework language, and then apply the principles or the spirit of the language to our Agile project and if you like me to just jump right in and sort of elaborate on what that looks like, is the guidance that’s been written for the United States, let’s say is SOP 98-1 and ASC 350-40 the ones that I’ll be kind of referencing, indicate that all of the work that we do at a beginning of a project in terms of the preliminary phase, so they’ll use phase languages that would literally be translated in Waterfall World to that analysis and high level design work, needs to be expensed so there is very clear guidance that must be followed by all organizations that includes corporate organizations as well as non-profits in order to be in compliance with the guidance. So what do we do as Agilists when we hear that, we say: “Wait a second, that doesn’t really work for us because we don’t finish the analysis and the design at the beginning of the project” so that we have a clear staged gate that we can say ok now, we start capitalization, but instead we know that the work we do entails continuous analysis and continuous design throughout the life, throughout the life cycle of delivering the solutions that we are delivering into releasable value to the customer. So that’s the essence of the problem, and everyone stumbles with and everyone has a challenge in terms of finding out how do we address that problem, what is the solution.
If we take a step back and get beyond the language, and get beyond the gates and the stages and the methodology differences and we learn that the intention of the preliminary phase in the guidance is to establish feasibility, is to establish with confidence that we will be effective in investing our very precious funds and coming up with a consistent solution that meets the needs of our investor confidence that is feasible for us to continue with this solution, and so it’s really not about Agile or Waterfall, it’s about understanding the purpose or the intent of the phased approaches, so in an Agile World what we do is, we do a lot of the preliminary idea vetting and the preliminary what’s called the Business Case Development or assessments, you know, treatments at the beginning of the project, that work is all expensed. By the time we actually pull our teams together in a formal kick-off or let’s call it an inception, whatever the language that we use, that period of kick-off is after we’ve already established with a high degree of confidence that we are going to move forward and this is a technically feasible solution, otherwise we wouldn’t be investing and pulling the team and assigning our talent to start the work. So technically at that inception or that kick-off meeting, when we’ve understood what it is we are going to be delivering is that differentiation between what we are going to be doing and we start the work on how we are going to do it in terms of detailed design or a deeper level design, the epic level stories, then at that stage marks a clear bright line that our accounting friends can understand is memorialized and after that point in time all the work that we do as an Agile team developing and creating the asset that we are going to be depreciating and capitalizing, is capital. So we’ve come up with a very, very simple solution to a very complex problem and that so often happens simple rules and simple solutions, can easily adapt to the uniqueness of every different project and every different organization.
Shane: Occam’s razor - the best solution to any problem is the simplest one that solves the problem.
Exactly and did that make sense, this proposal make sense.
Shane: It sounds good to me.
Excellent, so then after we’ve reached that clear bright line and the way that I recommend we memorialize that clear bright line is by having the people who know best about the technical feasibility of the solution maybe it might be different for each project or might be different for each organization, but basically the technical lead, the domain architects possibly, you know the solutions architects, the enterprise architects depending on how extensive this project is, we need to pull together all the right talent who can assess, who can understand the value that we are going to intentionally deliver to the customer, and who can assess the technical feasibility with a high degree of confidence based on the depth of their expertise and the depth of their domain knowledge. They know best, so we move away from artificial approvals by people who are just looking at check lists and actually pull together the right talent, generally again that includes the right level of architects, technical leads, product owners, product managers and Agile project managers or Scrum Masters whoever the right level of people are, to align on the feasibility that we are good to go, they’ve high degree of confidence, they got the right talent, the right team, the right resources and we have a good enough understanding that we are ready to know go into design, understand deeper level of requirements gathering in design. Then we have those individuals come together and a test to that kind of sign or documented, eDocument, so that we can validate for future auditors that we have memorialized the approvals of the people who know best.
3. And met that compliance need?
Exactly, one more thing we need to do meet that compliance need, is that those thought leaders who’ve come together to say that technically we are good to go, after they sort of signed an email or a document and forward that to the leader in the organization who has fiscal responsibility to approve the funds that would be what we believe to be sufficient to cover that, so we’ve got to get that clear then the appropriate finance approval with the appropriate managerial approval who has funding authority at the level of funds that we are requesting for this particular solution to be delivered, does that make sense?
Shane: So all of that early work of what we call it Scoping and the feasibility issues that we do, we have to draw the bright line? That’s something that perhaps for some of our audience “that’s not Agile”.
What we are doing is we are assessing here the feasibility of being able to deliver the planed value to the customer and that very much is Agile in terms of rigorous planning to ensure that we are focusing our energies on the highest value work, so if we get to the core of Agile it’s about delivering value to the customer, and that’s the Manifesto, it’s kind of what we do, and that’s actually what I believe it’s our kind of touchstone is really focus a laser-like focus on customer value delivering. So I believe it’s really consistent, very consistent with Agile. We wouldn’t want to invest our talent in delivering something that see of either marginal value or there’s not technically feasible, because if we are not delivering value, then we are being wasteful and we do want to put that rigor upfront in terms of validating that we do believe with a high degree of confidence that we can deliver planed value to the customer. Notice it’s at the beginning of the project where we have a very high level interpretation of what that value is going to look like, we continue as we work through and discover with the client, understanding what that value really turns out to be. We are not locked in to that specificity upfront and that’s I think one of the key differentiators between Waterfall, where a great deal of time is spent upfront locking down those requirements before their clear bright line was defined. In our Agile interpretative framework of this, you know we focus on the feasibility of being able to deliver that value in the a form of an asset, but the asset, the architecture of that asset is going to emerge as we work on building and delivering and further tuning that asset to optimize the delivery of value.
All of the work that we can trace to being critical for building the asset, so certainly all of the technical work automatically has covered. It might help of a start to talk about what is not covered and then we can say everything else is covered, so after we’ve kind of memorialized that clear bright line, would generally be in a Scrum World like iteration 0. Everything that we do everything that the team does together that it’s critical to the creation of that asset is capitalizable, and that pretty much means everything that we do with the exception of administrative work. Now as we’ve matured in our adoption of Agile, we naturally kind of remove or eliminate the waste that’s associated with the excessive administrate of work, we do daily standup meetings, we don’t spend a lot of time trying to find meeting rooms or scheduling, we don’t have, I’ve not worked with any Agile teams that have administrative assistants who actually do all their meeting scheduling for them, we do that naturally as a part of the way we work and the way we do business. So that administrative work usually doesn’t enter into the picture with Agile, but if we did have an administrative assistant in our team, that was taking care of making physical arrangements and that individuals labor could not be capitalized, the administrative labor would have to be expensed.
But all of us know that the work of the work that our Scrum Masters and our Agile project managers, Agile program managers are doing, is vital to the contribution, or at least most of the work, they’re doing is vital to the building of the asset. So that’s the differentiator, if a program manager for example is spending a great deal of their time in relationship building or connecting with other projects or outward facing, not inward facing to support the team in developing the asset, then the outward facing time that technically could not be traced back to the building of the asset, maybe expensed. Would be handled as more of an expense as a post to the Scrum Master let’s say, there’s been a lot of debate or question about, is this Scrum Master’s time technically attributed to creating the asset and if I asked you to speculate on the answer for that …
Shane: My feeling is that the Scrum Master is so crucial to that delivery, they are constantly facilitating and often they are actively doing stuff with the teams, I would find it hard to draw the lines, I would go with capitalized.
Great answer Shane, that’s exactly the right answer. Our Scrum Masters who are inward focused on really enabling the team and supporting the team, sometimes often can raise technical issues for resolution before the team might even see it and might need to rally a lot of external resources around to remove a blocker from the team. Technically all of that work is vital and critical to the creation of the asset, in other words could the asset be delivered as efficiently without that individuals contributions? If we ask and we’ve kind of frame up the questions and the challenges in that regard, then we can clearly see that the Scum Master is not providing administrative support, that the Scrum Master is playing an equally vital role to anyone on the technical team in terms of creating value to the end customer in the form of creating the asset.
Shane: So that actually makes it pretty straight forward to identify which members of the team or members of the extended team, who are interacting, how we do, account for and capitalized her expense and keep the accountants happy.
So can I ask you another question, this seems to be working, so if I was to say to you what about time tracking. You know it’s very important in my organization that our technical teams track their time because they need to differentiate time that they are spending on analyses, design, development or testing or deployment and if you understand through this dialog, with the clear bright line do you think there is a need to track technical teams time.
Shane: It’s all of that work is crucial to the delivery of the product.
Exactly, so the need to differentiate or to track your time which we know is impossible anyway, you know in terms of being accurate, that need goes away and so the original in the world, in the Waterfall World, a lot of these requirements have out lived their useful life as we’ve adopted an Agile Solution. In the Waterfall World we may have found it critical to use the infamous WBS codes and be able to have every engineer track their time with rigorous precision to one of those WBS codes for proper accounting. You know again in the different interpretation that wouldn’t been a defensible solution of being able to prove with a high degree of confidence during an audit that how I spend my time 3 years ago, but as you understand the solution that fits for an Agile World understanding that we’ve already compressed all of the administrative work out of our life cycle, our Agile life cycle, and we rigorously manage and plan for that on a daily bases, then the need to track time according to WBS codes or whether, or break down structure codes of whether we were working on analysis design development, goes away and we can focus our talent’s time on doing what they do best, which is creating assets value to the customer.
Shane: Pet that’s really interesting, thank you for taking the time to talk to InfoQ today.
My pleasure.
5. People can find out about this on the Agile Alliance website?
Yes, go to the Agile Alliance website and you can find the program and download the information there that kind of outlines the framework that can help get you started.