A Disciplined Agile Enterprise (DAE) is able to sense and respond swiftly to changes in the marketplace. It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces. Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.
The DAE layer is one of the four layers of the Disciplined Agile (DA) tool kit, overviewed in Figure 1. These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE). This blog focuses on the DAE layer.
The Disciplined Agile Enterprise (DAE) layer encompasses the capabilities required to guide your organization, to coordinate the teams/groups within your organization, and to support the value streams offered by it. Figure 2 summarizes the DA tool kit and Figure 3 overviews the process blades that are specific to the DAE layer. Several process blades of the DAE layer - Research & Development, Business Operations, Strategy, Governance, Marketing, Continuous Improvement, and Sales - are shared with the value streams layer. The are "shared" in that the scope of these process blades may focus on both the entire organization and specifically on individual value streams. For example, a financial institution may execute an organization-wide marketing strategy as well as specific strategies for their retail and corporate value streams.
Expanding upon the value streams layer, the DAE layer adds the following blades:
The asset management process blade addresses the purposeful creation (or rescue), management, support, and governance of organizational assets. This includes financial, inventory, contractual, risk management, and strategic decisions of these organizational assets.
The enterprise architecture (EA) process blade overviews how a Disciplined Agile EA team will work. An agile enterprise architecture is flexible, easily extended, and easily evolved collection of structures and processes upon which your organization is built. The act of agile enterprise architecture is the collaborative and evolutionary exploration and potential capture of an organization’s architectural ecosystem in a context-sensitive manner. The implications are that enterprise architects must be willing to work in a collaborative and flexible manner and that delivery teams must be willing to work closely with enterprise architects.
The finance process blade addresses a collection of potentially competing goals, such as ensuring cash flow within your organization, ensuring your money is being spent well, taxes are minimized, spending is properly tracked and recorded, and legal financial reporting is being performed properly. All of this will be performed in a manner that is compliant with applicable financial regulations, such as Financial Accounting Standards Board (FASB) and International Accounting Standards Board (IASB) guidelines.
The information technology (IT) process blade encapsulates the activities required to provide IT capabilities to the rest of the organization. This includes managing information technologies, data resources, applications, and IT infrastructure.
The aim of the Legal process blade is to ensure that your organization works within the parameters of the law of any and all legal territories in which you operate. Your legal team will work closely with your vendor management people on (Agile) contracts; with your people management team to ensure that their strategies reflect the local statutes and to help educate staff in legal concerns; with your marketing team to guide what they’re legally able to promise; with your strategy team to ensure the direction they're taking the organization is legally viable; and with governance to understand the legal implications of applicable regulations.
The aim of the people management process blade is to attract and retain great people who work on awesome teams. People management goes by many names, including human resource (HR) management, human relations (HR) management, talent management, staff management, people operations, and work force management to name a few. This process blade addresses strategies for forming teams; helping people to manage their careers; training, coaching, and educating people; human resource planning within your organization; managing movement of people within your organization; reward structures; and governing people management efforts.
The transformation process blade captures advice for how to redefine, and then reengineer, your organization. This includes understand the current context, identifying the desired future, identifying how to measure the success of the transformation, identifying a likely strategy for moving towards the desired state, and then executing on that strategy. Throughout a transformation you will constantly gauge your progress and the desired target state and adjust according. This process blade leverages the advice of PMI's Brightline Initiative.
The aim of the vendor management process blade, sometimes called supplier management, is to help obtain and then manage offerings (products, services, and intellectual property) from other organizations. To do this your vendor management team will collaborate with other parts of the organization to help them understand their needs (if any), identify potential vendors that can fulfill those needs, work with legal to develop appropriate contracts, address vendor-related risks, help monitor and manage vendors, and eventually close out any contracts.
An important financial governance concern in modern enterprises is how to expense costs properly. This of course includes the costs of IT, including the costs associated with agile software development teams. There is more to this of course than just adding up expenses, these expenses need to be categorized appropriately and in some cases can have a measurable impact on your bottom line. In this blog posting we explore how to categorize agile software development costs into either capital expenses (CapEx) or operational expenses (OpEx).
Let’s begin with a few important observations:
Why is This Important?
For publicly traded companies CapEx can potentially boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, OpEX is accounted for in the year that it occurs and thereby reduces net income which in turn reduces your organization’s taxes for that year.
How DAD Helps
As you can see in the appendix most of the rules for when to capitalize boil down to “start capitalizing when you know its real”, something that works well with DAD’s risk-based milestones.
As you can see in the diagram, we’ve identified two potential points where you can start capitalizing software development costs:
Of course, there are a few more issues to consider:
Needless to say, many developers, particularly agile ones, feel that time tracking is a waste. Spending 5 minutes a week is ok, and to be quite blunt should be more than sufficient, but spending fifteen minutes or more a day doing so is far too much. For CapEx/OpEx purposes you merely need to track broad categories of software development work such as Development, Prototyping, Vacation, and Training/Education. These categories will be determined by the applicable accounting rules and should be kept to a minimum.
Our advice is to keep your time tracking strategy as simple as possible, make it very clear to everyone why it’s important to capture their time accurately, and do not use the data to directly measure individuals. You may find the article Why Time Tracking Might Be the Most Valuable Activity an Agile Developer Performs to be an interesting read. And, as you would expect from Disciplined Agile, we compare and contrast several Strategies for Tracking Time on Agile Teams.
It’s important to note that tracking time simply for CapEx/OpEx reasons is very hard to justify in practice due to the overhead that it injects plus the loss in team morale (nobody likes tracking time). Another option is to simply track the amount of time that the entire team spends in a week and then assign a percentage of that time to each category. This would require a slight amount of effort to track, likely something done by your Team Lead.
The Bottom Line
CAPEX/OPEX decision is fairly straightforward for teams that are following a Disciplined Agile Delivery (DAD) approach. The team simply needs to keep track of important milestone dates (either the Project/Team Start date or the Stakeholder Vision acceptance date) and track their time in a few broad categories as described earlier. If you do that, it’s a simple matter of running a report against your time data.
Appendix: What The Regulations Say
Disclaimer: You must read the actual regulations for yourself, what follows is just a summary and may become out of date overtime as the regulations evolve.
International Financial Reporting Standards (IFRS) – IAS 38
You must be able to demonstrate ALL of following BEFORE you can START capitalizing costs:
Note: It is expected that FASB will recognise IAS 38 in 2016.
Canada – Accounting Standards for Private Enterprises (ASPE)
Based on ASPE, you must be able to demonstrate ALL of following BEFORE you can START capitalizing costs: