Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

The Disciplined Agile Enterprise (DAE) Layer

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: FoundationDisciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the DAE layer.

Figure 1. The layers of the DA tool kit.

Disciplined Agile Layer Overview

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.

Figure 2. The Disciplined Agile (DA) tool kit.

The process blades of Disciplined Agile

Figure 3. The process blades specific to the DAE layer.Disciplined Agile Enterprise (DAE) process blades

Expanding upon the value streams layer, the DAE layer adds the following blades:

Asset management

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. 

Enterprise architecture

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.

Finance

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.

Information technology

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.

Legal

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.

People management

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.

Transformation

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.

Vendor management

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. 

Posted by Scott Ambler on: October 12, 2020 06:24 PM | Permalink | Comments (6)

Agile Software Development and CapEx/OpEx

Categories: capex, finance, governance

Financial Goverance

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

Some Basics

Let’s begin with a few important observations:

  1. How you expense cost (and revenue for that matter) is driven first by accounting rules, such as Financial Accounting Standards Board (FASB) in the US, Accounting Standards for Private Enterprises (ASPE) in Canada, and International Financial Reporting Standards (IFRS) IAS 38 in general.  The implication is that CapEx/OpEx decisions in part are driven by geography.  At the end of this posting is an appendix summarizing these regulations.
  2. There are a few categories of expense, such as training and education (including coaching related expenses), which automatically fall into the operational expense category regardless of when they occur in the lifecycle.
  3. Where the appropriate accounting rules provide leeway, for example financial minimums for what to consider for capitalization, your corporate policy will need to guide you.  A common problem in established organizations is that some of this guidance was set before agile approaches were adopted and reflect waterfall-style governance.
  4. How you account for expenses is orthogonal to development paradigm.  It doesn’t matter what method the team follows, the actual capitalization rules remain the same.  The implication is that you need to determine how to apply these rules effectively for each paradigm, and as you’ll see even by lifecycle.
  5. This decision, or as we’ll soon show reporting activity, is typically the purview of Finance, not IT.  You really shouldn’t have to worry too much about this.
  6. You must engage the appropriate Finance, IT, and Audit people to ensure that everyone understands the implications of how you’re working and agrees to how you will approach accounting for expenses.

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.

Agile Software Development and CAPEX/OPEX

As you can see in the diagram, we’ve identified two potential points where you can start capitalizing software development costs:

  • Conservative: Stakeholder vision milestone.  This is the point which most organizations use as their CapEx starting point.  As you can see in the appendix, this milestone lines up perfectly with the regulations – you’ve made the decision to go forward with development, you’ve got a technical architecture strategy in place, you have an understanding of what you hope to produce, and so on.
  • Aggressive: Project/product team start. Some organizations will choose to start capitalizing at the very beginning of a software development project because they have effectively made the decision to move forward with the effort at that point, they know what the architecture is (due to a good understanding of their existing environment and technical road map), and due to their culture it is highly unlikely that they will cancel the effort.

Of course, there are a few more issues to consider:

  • You cancelled the project.  If you cancel a project (or release of a product) most organizations will choose to reverse their capitalization decision for any expenses incurred with that project/release.
  • You’re prototyping.  Prototyping, including time spent on proof-of-concept (PoC) or spikes, is usually considered to be an operational expense because it is a learning activity.  This is the case regardless of when in the lifecycle this work occurs.
  • Your team follows the continuous delivery lifecycle.  Teams following this lifecycle are in the Construction and Transition efforts all the time, so they’re effectively past the Stakeholder Vision milestone (the Conservative point) at all times.
  • Your team follows the exploratory/lean start up lifecycle.  Teams following this lifecycle are not yet at the point where they’ve made the decision to continue with development, and when they do so the typically kick into one of the other lifecycles anyway.  The implication, at least from a conservative point of view, is that these expenses should be operationalized.

Time Tracking

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.

US FASB 

  • Internal and external costs incurred during the preliminary project stage shall be expensed as they are incurred
  • Internal and external costs incurred to develop internal-use computer software during the application development stage shall be capitalized
  • Costs to develop or obtain software that allows for access to or conversion of old data by new systems shall also be capitalized
  • Training costs are not internal-use software development costs and, if incurred during this stage, shall be expensed as incurred
  • Data conversion costs, except as noted above, shall be expensed as incurred
  • Internal and external training costs and maintenance costs during the post implementation-operation stage shall be expensed as incurred

International Financial Reporting Standards (IFRS) – IAS 38

You must be able to demonstrate ALL of following BEFORE you can START capitalizing costs:

  • Technical feasibility of completing the intangible asset so that it will be available for use or sale
  • Its intention to complete the intangible asset and use or sell it
  • Its ability to use or sell the intangible asset
  • How the intangible asset will generate probable future economic benefits. Among other things, the entity can demonstrate the existence of a market for the output of the intangible asset or the intangible asset itself or, if it is to be used internally, the usefulness of the intangible asset

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:

  • Technical feasibility of completing the intangible asset so it will be available for use / sale
  • Intention to complete the intangible asset and use / sell it
  • Ability to use / sell the intangible asset
  • Availability of adequate technical, financial and other resources to complete development and use / sell the intangible asset
  • Ability to reliably measure the expenditure related to the intangible asset during development
  • How the intangible asset will generate probable future economic benefits

 

Related Reading

Posted by Scott Ambler on: April 10, 2015 11:28 AM | Permalink | Comments (0)
ADVERTISEMENTS

"The human race has one really effective weapon, and that is laughter."

- Mark Twain

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events