You are hereFeed aggregator

Feed aggregator

Achieving Collective Purpose

All About Agile - Wed, 03/30/2016 - 04:00

Teams are cross-functional - containing all skills necessary to define, build and ship the new features. The teams are aligned to producing value to the business rather than to the abstract purposes of providing excellence within a functional silo. This not only gives the team a laser-focus on adding value to the business.

Agile Change or Adoption Always Starts with Why

All About Agile - Wed, 03/30/2016 - 00:08

Your organization has decided to become more “Agile.” Why? As we learned in a previous blog post, “Because Our Competitors Are” is not a valid – or sensible – reason. Before embarking on a change, adoption, or improvement program, you need to know the rationale behind that decision. So… why Agile? A traditional approach to answering this question might see the executive team going off-site for two to three days and holding a workshop where they decide why they should be Agile, then design an adoption strategy, and then summarize the whole thing in a few sentences to be sent out in a memo. Typically, large-scale change initiatives have a lot more ceremony, more meetings, and more setup than this. However, there are several key failings, including that they involve only a select few executives in the envisioning and decision-making process, and they attempt to plan for the long haul. There are dozens of examples in our industry of failed change efforts that have cost billions of dollars and proved that this approach doesn’t work. At Nokia, Stephen Elop issued the famous ‘burning platform’ memo in 2011, and yet two years later the company was sold to Microsoft. In 2013 Avon had to write off $125 million[1] of work that built an enterprise software implementation which drove representatives away. This was change that failed to help the very people it was intended for. These and other failures involve some combination of the following: Why – The “Why” isn’t understood by most of the victims of change. Strategy – The “Strategy” created by the executive group doesn’t make sense to all of the people doing the work. Ownership – People at the edges of the system (who do most of the work) feel no ownership of the change. Connection – The strategy doesn’t appear connected to the problems that the people at the edges of the system are experiencing. Improvement -The strategy appears to improve the lot of the executives, but not of the doers. Culture – The change doesn’t fit the organization culture. Leadership – Top level is asking for change but doesn’t appear to be involved in making it happen. To be effective, Agile organizational change needs to… well, involve the Organization! Not just the executives who have made the decree, often without fully understanding what the goals of the change are. This shouldn’t be a quick decision made at a two-day corporate retreat. It needs to be an ongoing effort to figure out the “why” collaboratively and share it effectively, being mindful of some essential ingredients. We will address those ingredients in the next several blog posts. Avon’s Failed SAP Implementation A Perfect Example Of The Enterprise IT Revolution – Ben Kepes: Image attribution:

Refactoring: 4 Key Principles

All About Agile - Thu, 03/24/2016 - 16:35

Learn more about transforming people, process and culture with the Real Agility ProgramI believe in refactoring.  The Agile Manifesto holds that The best architectures, requirements and designs emerge from self-organizing teams. The quality of our software systems depends on refactoring.  In fact, I believe that the only way that an organization can avoid refactoring is … Continue reading Refactoring: 4 Key Principles →

The post Refactoring: 4 Key Principles appeared first on Agile Advice.


All About Agile - Mon, 03/14/2016 - 08:52

In 201x, the global financial markets collapsed. Reason: mortgages were given to people who couldn’t afford them. This debt was then repackaged and sold to banks and other institutions as good debt. (“The Big Short” by Michael Lewis is an excellent indictment of this time). However, the bigger question remained. Why didn’t the financial regulator system catch the problem early, while it was still small? The answer? Complexity. In “The Dog and the Frisbee” (pdf), Andrew Haldane, Executive Director Financial Stability at the Bank of England, explains all the things a dog would have to know and understand to catch a Frisbee: wind speed and direction, rotational velocity of the Frisbee, atmospheric conditions, and gravitation. It might require a degree in physics to know how to express the control problem involved in catching the Frisbee. Yet dogs, without physics degrees, do this everyday. They obey a simple rule/heuristic: “run at a speed so that the angle of the gaze to the frisbee remains constant”. Empiricism and Simplicity. Agile works because it is an Empirical process using constant feedback to update both the work itself and the way we work. Haldane goes on to show that the financial regulatory system evolved from something simple that many people at a bank could understand, to something only a few people could understand. Eventually it became so complex that no one person understood the system as a whole. The earlier regulatory frameworks worked well in part because many people understood, and therefore many people could spot problems early, before they got too complicated and large to resolve. As we deal with ever-larger organizations, it’s tempting to say that this increase in complexity is okay because we’re larger. But if financial crisis taught us anything, the answer should be no. The bigger the system, the more important it is to use simple control mechanisms, simple feedback loops, and simple measures that can be understood by all. Decreasing complexity – not increasing it – has to be at the heart of all of our decisions. And coupled with that has to be the ability to respond quickly and change appropriately.   Image attribution: damedeeso, via photodune

Overhaul to "It’s not just standing up"

All About Agile - Tue, 03/08/2016 - 04:45

Jason Yip has overhauled his definitive article on running stand-up meetings. The update incorporates his latest understanding on what separates a valuable meeting from a waste of time, emphasizing the "walk-the-board" style of ...

So You Think You Can Agile?

All About Agile - Thu, 03/03/2016 - 10:00

Your corporate organisation has just publicly declared it’s “agile,” but what does that really mean?

Since the Australian Prime Minister announced, "The Australia of the future has to be a nation that is agile," we assume he is referring to our role as an agile society and how corporations can enact that change. His proclamation seems to have spurred a great deal of movement by large corporates to respond in their shareholder statements to meet that call to action.

Moving toward business agility means significantly changing the way we work, the way we approach our roles and the way in which, as knowledge workers, we all interact.

In our world, we define business agility as:

The ability of an enterprise to sense and respond to change quickly and confidently—and as a matter of everyday business.

Let’s imagine we take the “a” word out of the corporate statements. Could these ASX 100 listed organisations state that they not only merely respond to change but are sensing (innovating, hypothesising and learning) and creating (experimenting, testing, learning some more)? Once they've evaluated that part of the statement, can they then really lay claim that they do all of these things quickly and confidently?

Agility is a Journey

When considering the organisational impact of this definition, the task ahead for many is daunting. But moving your organisation toward business agility is a journey. You not only need to provide clear executive leadership but make and meet your commitments throughout your continuous improvement effort.

“MIT Sloan reports that agility shows up on both the top and bottom line, with Agile firms growing revenue 37% faster and generating 30% higher profit.”*

In a recent SMH article, nine large Australian enterprises stated that they are adopting more lean and agile organisational and operational business models. All are profitable or have seen significant profit growth in the previous 12 months. Does that mean we can attribute part of their success to becoming or being more agile? We also need to understand how they are sustaining and improving agility, and building an ongoing culture of learning.

Many of the organisations we work with have great team-level IT execution and are now more concerned with how they align their capacity to build the right things (versus building things right) to their business needs over a longer time horizon. They’ve observed some small wins around productivity but are now looking for those larger organisational gains that relate back to the MIT Sloan metric I shared above.

Have they truly taken the learnings from team-level agile up into programs and beyond into their portfolio and investment strategies? Or should we say, are their customers realising value, continuing to engage with these enterprises and paying it forward? A big challenge lies in understanding the goal for change and having the right organisational support to implement it. Then, you need to strive for some level of consistency and repeatability whilst still respecting the definition of agility. Team-level agile is a starting point for many, but realising big change requires consistent commitment across the enterprise.

Sustain Change With an Agile Approach

You don’t change an entire organisation overnight. Once you’ve identified clear leadership and compelling goals for your organisation, you need to take an agile approach—small but committed steps with open communication and feedback loops at each step of the journey. Ensure that you have a well supported executive leadership team that owns the sustainable change and helps steer change across the business. It all requires a combination of education at all levels, a clear roadmap for change and coordinated coaching, facilitation and change management.

I often reflect on how the agile community (the agile of the Agile Manifesto, complete with values, principles, etc.) supports or even contradicts this theme. There is a need for some semblance of consistency for these large enterprises—oh no, did I just tell you we need a framework? How very unagile of you!—a topic for another time perhaps.

The interesting thing here is that everyone in the market—customers, communities, consultants, vendors and partners—wants the same outcome. Improving the way organisations work to ultimately enhance our way of life as a society: eliminating waste and responding to change quickly and confidently (well, at least that’s what my team and I want).

So, one can only live hoping that’s why we're all here—to continue toward autonomy, mastery and purpose and in turn help enterprises do the same. We all want to embrace, educate and coach great outcomes for the people who work in these enterprises. Who doesn’t want to get up and be excited about the day of work ahead and help people improve their capabilities to ultimately create a better society?

It’s obvious we have a great opportunity ahead of us to perhaps even leapfrog other countries with agility. To learn from their failures (failing fast and learning is good, BTW) and reconnect Australia as a place of free thinking and collaborative learning toward a better, more agile society. As John F. Kennedy once said about improving economic reform, “A rising tide lifts all boats.” If we all pull together, we can help our enterprises and our government become more agile, increase our economic impact, grow and develop better talent and truly declare that yes, Australia is the agile land down under!  


Nat Tanner

Top 100 Agile Web Sites

All About Agile - Thu, 03/03/2016 - 06:23

Oikosofy have written this list of the top 100 agile blogs or web sites: I think this is a really useful resource for people hence why i’m posting it here. I was very pleased to be on the list and proud to be found at number 11 :) Enjoy! Kelly.

“Because Our Competitors Are” is No Reason to Become an Agile Organization

All About Agile - Wed, 02/17/2016 - 04:32

Companies are starting to fall into a trap, and it goes something like this, “Our partners/competitors/… are Agile, so we need to be Agile.” Becoming Agile without a valid reason will harm your organization. I can’t state that any simpler. In the ‘80s and ‘90s, rival manufacturers often visited Toyota plants, and Toyota was delighted to welcome them, because Toyota understood that even if their competition copied company practices, practices change. What competitors weren’t copying was the culture that created the practices in the first place, and that’s where the real value was. Thus we had Cargo Cult Lean at many North American manufacturers, and it didn’t produce the results that companies were hoping for. We’re seeing that again with Agile. It’s not enough to become Agile and to copy Agile practices simply because your competitors are. Unless you develop a culture that creates its own practices, this will lead only to Cargo Cult Agile, and not a true Agile Organization. What competitors weren’t copying was the culture that created the practices in the first place, and that’s where the real value was. So what are some valid reasons to become Agile? One of the primary ones is to be able to readily adapt to a changing environment. Other reasons include: Resilience; Predictability; Risk Reduction; Morale and Retention; Early ROI; Predictability; Customer Satisfaction and Simplicity. Consider how Blockbuster adapted to online video, or how the taxi industry is responding to Uber/Lyft. Control-focused organizations struggle to adapt rapidly enough to survive, compared to their competitors who embrace change. Traditional/hierarchical organizations work well when problems are clear and solutions are repeatable but, unfortunately, those that thrive in those conditions are fragile when the situation changes and they can’t adapt. The structure of traditional organizations is one which evolved in a world where the pace of innovation and change was much slower. Changes could be spotted years out, and a response could be crafted and the organization would do well. That world no longer exists. Whole industries die in only few years if their response to change isn’t rapid and flexible. Which is where Cynefin can come in to the conversation. Cynefin Cynefin is a way of understanding the problem domains in which we find ourselves, and identifying which tools would be appropriate in response. At first blush it can look a little daunting, but bear with me and you’ll see that it doesn’t have to be. It’s merely a matter of “cause and effect”, and how simple or complicated that plays out within the context of your organization. The Cynefin Framework breaks down into 5 different domains to describe different types of relationships between cause and effect – from straight-forward, to complicated, to non-existent. The first of these is, well, Obvious. Obvious (formerly called Simple) is just as the name suggests. These contexts are clear to all involved. If X, then Y. At any stage in a process, it is clear what the next steps are. Examples are aspects of banking (interest calculations), insurance (calculation of premiums), etc., Organizations in this realm gain value from a degree of structure to ensure that people follow the rules. Standard practices apply here. A simpler example? Let’s talk about growing things. Develop your green thumb. In an Obvious system, we have a sponge. If you apply water to it, it will swell and grow. Cause and Effect in its simplest form. Sponge + Water = Bigger Sponge. That’s Obvious. The next domain is a little less so. Complicated is where the relationship between cause and effect is harder to see. It requires analysis and, often, expertise to find and understand the relationship(s). Once understood, “best practices” can be developed in this domain. To return to the growing analogy, this is the system where we’re growing one plant in a pot, which is considerably more complicated than growing a sponge, but there is still logical cause and effect involved. Seed + Soil + Water + Sun + Food = Plant. In this world, there are rules of thumb (green or otherwise) and best practices. It’s important to note that one of the risks of a Complicated Domain is that we listen only to the experts. It’s vital that we also factor in our own observations and environment. The next domain is more Complex and, in these contexts, cause and effect relationships are only understood in hindsight. Given the unpredictability of this domain, we’re better off probing, sensing and responding instead of trying to control or plan. Instead of looking for complex solutions, seek simple rules or heuristics to help work well in this environment. Trying to help grow our kids is an example of the Complex Domain. We ask them to do something (probe), they respond (sense) in an unexpected way. It’s only in retrospect that we can see why they responded that way. Next time, we adapt (our response), changing the phrasing/tone based on our new understanding of them. Complex domains require many diverse viewpoints to help solve. Although challenging, they’re still much easier to navigate than Chaotic. In Chaotic Domains, there is no relationship between cause and effect. Emergency/disasters are examples of the Chaotic domain. In these cases, the goal is simply to try and bring them back from Chaos to the world of the merely Complex. We don’t often see this domain in the business world, so we’re not exploring it here. And the fifth and final domain is Disorder, which exists when it hasn’t yet been determined what the cause and effect relationship is.  It’s in this state that people are most apt to make decisions based on their own comfort zone. These days, businesses are usually working in Complex Domains, which means that traditional, old-school approaches aren’t realistic. We can’t afford to have the DNA of Simple organizations persist, if organizations want to thrive in this new, rapidly-evolving world. So we need to create organizations that can adapt – and even thrive – in a Complex world, and help Simple and Complicated […]

The Top 10 Pitfalls of Agile Capitalization

All About Agile - Tue, 02/16/2016 - 13:00

 (all photos via Flickr, Creative Commons)

As part of your agile transformation, have you engaged with your finance and accounting friends to include agile in their accounting practices? Maybe you read the Why Agilists Should Care About Agile Capitalization article and you’re trying to help your finance group make sense of agile.

If your organization capitalizes software development, chances are Finance and Accounting are struggling to make sense of capitalizing agile software and you may run into one of two risks: either Finance conservatively expenses all agile labor costs, short-changing your organization from its true valuation, or Finance obstructs agile adoption because they’re comfortable capitalizing waterfall development but not agile development.

In a world where business is being rewritten by software, agile capitalization is becoming a major financial concern for organizations growing their agile practices, to the point of becoming material to profitability.

Because capitalization guidelines captured in the Accounting Standards Executive Committee (AcSEC) Statement of Position (SOP 98-1) were written in 1998, when waterfall development was prevalent, these guidelines are challenging to interpret for agile development. As a result, financial conservatism leads many organizations to expense all agile development work. With the labor costs associated with agile development growing exponentially, finance groups are starting to ask:

Is there a way to interpret the SOP 98-1 guidance to effectively (and defensibly) capitalize labor costs on assets being created using agile practices?  

Not only the answer is a resounding YES, but the potential for effective expense management is higher with agile practices than with waterfall practices. Because of agile’s strong focus on value, agile teams create more financial assets. Smart companies are realizing that agile capitalization can indeed be a big contributor to greater business value.

At its core, agile is about increasing value and delighting customers. You can delight customers without reporting on and depreciating the software assets delivered by agile (through capitalizing project labor costs), but if you expense all the agile labor costs you could be capitalizing, not only do you not gain the financial benefits of agile, your company could appear less profitable than it really is: that’s what has companies paying a lot of attention to this topic.

Over the past several months, as part of our continued research connecting agile and finances, I had the privilege to spend quality time with Pat Reed, director of the Agile Alliance Agile Accounting standard initiative. Not being a financial or accounting person, I marveled at how clearly Pat explains what many consider a complex and boring topic. Low and behold, I found myself getting excited about agile capitalization! (I know, how can anyone possibly get excited about capitalization?) Well, there’s a huge opportunity to help organizations avoid waste while promoting best agile practices. Here are the key ideas to keep in mind:

  • The WHY. Remembering the original intent of the Generally Accepted Accounting Principles (GAAP) is key to companies creating accurate, consistent and defensible capitalization solutions. Broader International Financial Reporting Standards add that financial reporting should be useful to investors, helpful for making decisions and helpful in improving the performance of the business.
  • The WHAT NOT TO DO. As companies look at updating their capitalization policies to more accurately account for labor costs independent of the development method AND improve performance of the business they need to watch out for pitfalls that can lead to unnecessary wasteful activities (and, ironically, are contrary to the intent of the accounting standards.) Little guidance is published and the little published is creating confusion and misunderstanding. Teams I work with know my motto: “just because you can does not mean you should,” which has served me well as a product manager. How often and how strongly can you say “No” to focus on the right thing? Agile capitalization reminds me to bring back this motto: just because you can over-engineer capitalization policies by, for instance, computing cost per story point, does't mean this is the right thing to do.

In this blog I want to share what I’ve learned from Pat so that you can benefit from her practical and proven experiences. Let’s go over the pitfalls to avoid.

#1: Expecting Technical Team Members to Know About Capitalization

The idea that engineers should know which bucket (CapEx or OpEx) their stories fall under is a form of waste as disruptive as asking them to track their time. Agile teams should be buffered from any CapEx/Opex categorization. Their role is to focus on delivering value fast, and anything that gets in the way of meeting this goal should be eliminated. ScrumMasters, however, have a very important role in implementing their company capitalization policy: building transparency and trust with Accounting. By focusing the teams on value delivery and removing impediments getting in the way of that goal, they are the “guardians” of capitalizable software assets. A good ScrumMaster helps teams focus on delivering their feature commitments AND on continuously learning and improving, so they reduce the cost of value (e.g. software “asset.”) ScrumMasters are closest to identifying the teamwork that may fall under Opex because work was aborted (for good reason). All developers should know is whether they work on feature work or fixing production defects; capitalization should not require any developer expertise beyond that.

#2: Assuming Time Tracking Is Required

Time tracking is prevalent in the industry because it provides a (false) sense of security to finance groups. The fallacy is to assume that if you track labor costs by hours, you must collect accurate labor costs. We all know how timesheets are filled out: at the end of the week, with little remembrance of what it was we worked on at the beginning of the week. There goes your accuracy.  

When funding value streams (dedicated teams) instead of individual projects, your labor costs are much easier to calculate. When you switch focus from cost tracking to value delivery, put in place development practices to increase software quality (resulting in fewer defects), flow work through dedicated teams (instead of moving FTEs to projects) and deliver value incrementally on a regular basis (instead of focusing on maintenance work correcting a plethora of defects), labor costs are easily tracked from the burdened rates of dedicated teams.

I’m not saying time tracking is evil, as there are valid use of time tracking: in cases when time is a traceable element for paying employees—especially in unionized, specialized industries such as the movie industry or the oil and energy industry, where the type of work an employee does directly impacts how much they are paid (ex: time-and-a-half.) But in most industries, time tracking is an antiquated process that disrupts busy knowledge workers creating innovative solutions. Agile practices simplify financial reporting with a greater degree of accuracy, transparency and traceability than time tracking.

#3: Concluding That Agile Development Cannot Fit in the SOP 98-1 Phases

The irony of this pitfall is that it conflicts with the original intent of SOP 98-1. If you want to capitalize agile software, then you have to adhere to the GAAP Consistency principle, by definition of which capitalization policies must be consistent across waterfall and agile practices (throughout your organization and across industries.)

To maintain investor confidence—the SOP 98-1 “raison d’être”—and respect the GAAP Consistency principle, capitalization policies need to interpret both agile and waterfall development in a consistent way.

A common argument is that with requirements emerging continuously, and with continuous delivery, agile development cannot fit in the SOP 98-1 preliminary, development and post-implementation phases. Agile development can absolutely fit in the three phases. These phases simply need to be interpreted for agile development.

  • The Preliminary phase is about feasibility before deciding to invest further. Agile is not precluded from approval decisions, nor are features produced by agile teams worked on forever. Just because you adopt agile does not mean you get automatic approval to obtain all the investment funding you want. Market analysis, creating a lightweight business case and Enterprise Lean Startup MVP (before reaching the product-market fit pivot) all fit in the Preliminary phase. Think of this phase as the WHAT that’s being articulated before the investment decision can be made.
  • The Development phase captures all activities related to creating the asset (the WHAT approved in the Preliminary phase) that represent HOW we will deliver the value expected out of the approved investment.
  • The Post-implementation phase is where defect corrections, post-production deployment and ongoing maintenance of the asset fit in.

image: Pat Reed Agile Capitalization presentation at CA World 2015


#4: Forgetting Why the GAAP Were Created

The Generally Accepted Accounting Principles (GAAP) follow rigorous principles to ensure accuracy and consistency across industries and maintain investor confidence. Staying true to the GAAP’s four constraint principles—Objectivity, Materiality, Conservatism and Consistency—is the key to keeping the capitalization rules simple and defensible, and avoid falling for an over-engineered solution driven by excessive fear-based controls, or fear of auditors finding skeleton in your labor costs closet. These fear-based behaviors can actually block rather than enhance business performance. A good capitalization policy (one that is “auditor-friendly”)  is consistent with the company respect for Objectivity, Materiality, Conservatism and Consistency.

#5: Forgetting Who Owns Creating an “Auditor-friendly” Capitalization Policy

Technical accountants (not agilists) are on the line to defend the capitalization policy to auditors. They’re the designers (and among the final decision makers) of how and what when it comes to  capitalization. They have a responsibility to defend the policy to internal auditors. This is not the agilists’ place to prescribe what falls under Capex vs. Opex. The key to an “auditor-friendly” solution is to co-create policies with technical accountants and IT leaders as equal stakeholders: explaining our respective worlds to create a policy defensible by accounting and traceable to agile work.

Everyone benefits directly or indirectly from the business outcomes linked to agile capitalization: higher profitability, better company valuation and more hiring power to increase our capacity to deliver more customer value. We all win when auditors don’t find significant findings that put our company in the news or at risk of having to restate earnings.

#6: Treating Capitalization as a Technical Problem

As professional engineers we are naturally drawn to do things we can do, at the risk of forgetting to assess whether we should do those things. Capitalization has a bit of a technical challenge to it: is it Capex or is Opex? Can I programmatically code that decision? What we forget is that the answer is not black and white, and may not be the same from one organization to the next. That’s because each organization has a different tolerance for Objectivity, Materiality, Conservatism and Consistency. You probably can think of some companies more conservative than others.

More importantly, what makes agile capitalization not a technical problem is its complex adaptive nature. After so many years working in this domain, Pat has yet to find two customers who are solving for identical problems. Although the outcomes of each will need to be consistent within the organization and adhere to GAAP, each organization needs to work through a unique and complex set of challenges that have evolved based on culture, practices, tools and methods. Complex adaptive problems are best solved by creating a strong collaboration between all parties—in this case technical accounting and lead agilists (and possibly financial reporting, portfolio management and audit and compliance)—to co-create a solution that leverages and honors the respective expertise.

This pitfall is accentuated when friction or animosity has built up over years between Finance/Accounting and agilists. The first step is to help expose and work through that friction by empathizing for the respective roles, as we simply cannot, as technologists, be the ones prescribing the capitalization solution to our company (or pretending to have all the answers) when accounting is on the line to defend the policy. The agilist’s role is to help Finance and Accounting understand how agile development works and collaboratively determine what needs to be reported to provide the transparency that builds trust.

#7: Over-engineering the Solution

Over-engineered solutions—many around leveraging user story points—are often rooted in fear and outdated beliefs that more controls are better. Over-engineered solutions focus on handling any and all impairments, which creates unnecessary waste. To remove that fear and limit the waste, we must build a trusted relationship with those actually dealing with the auditors. Technical accountants have a working relationship with internal auditors to create “audit-friendly” solutions.

The KISS (“Keep It Simple, Stupid”) principle reminds us that a simple solution is actually more defensible than an over-engineered one. Capitalization is amazingly not that complicated in nature (at least considering what agilists need to understand.) With “software eating the world,” software is becoming a major financial asset. Finance simply needs to understand which assets are being released. Do we release stories? No! We implement stories but we release features. Features (or bundles of released features) are the financial assets. Feature releases are deployed to customers, creating natural, capitalizable bundles. Finance does not like “stories”figuratively and figuratively : ) Finance does not like estimates, either, and story points are an estimate of effort.

A defensible solution requires actuals, not estimates. Very few agile teams really track their actualized story points, which would be considered a form of waste since that activity does not contribute to delivering value. Capitalization solutions relying on calculating cost per story point are not only over-engineered and wasteful, they run the risk of creating capitalization rules that are too complex to manage, as they force accounting into putting financial controls at too low a level of granularity. Remember the Consistency principle at the heart of the solution? Many agile teams don’t even use story points (for example, Kanban teams,) so the Consistency audit test would likely fail.

Over-engineered capitalization policies often have their roots in poor agile practices. Good agile practices lead to features predictably delivered in a release, where all release-related labor costs can be considered for Capex. Occasionally stories not completed for a feature release are identified and labor costs associated with their efforts should be reported as Opex, but good agile practices would make that an exception (and an opportunity for learning and improving.) Ideally the effort would be recognized early enough to limit labor costs to a point of non-materiality.  

Important to agilists is this: the stronger your agile practices, the simpler your capitalization policy can be. Strong agile practices focus on delivering valuable, high-quality features that translate into financial assets with limited production fixes and minimal overhead “expense.” Past the feasibility (investment approval) phase, most of the agile work can be considered for Capex. Exceptions, such as stories not completed for a release, can simply be reported by ScrumMasters to technical Accounting for a materiality assessment before deciding on Opex. Favoring conversations over tools and processes, you can trust ScrumMasters to have the conversation instead of wastefully automating story-level tracking.

Bottom line: a simple and defensible capitalization policy leverages strong agile practices and has provisions to handle the exceptions.

#8: Bending Agile Practices to Fit in Waterfall-based Phases

Organizations familiar with waterfall software capitalization and new to agile have a tendency to fall into this pitfall. Instead of fitting good agile development practices into the (designed-for-waterfall) SOP 98-1 phases, they bend their agile practices to make the mapping of agile labor costs similar to waterfall phases. For instance, they may create Design stories, Implementation stories and Test stories, then apply the labor cost of each story to the respective GAAP buckets, expensing Design and Test stories and capitalizing the Implementation stories. As described in the previous pitfall, when adopting good agile practices you should not have to track Capex/Opex at the story level. Once the feasibility phase is achieved, all development activities that can reasonably be traced to delivering features—the capitalizable financial assets—fall into the Capex bucket, including ScrumMaster efforts to remove impediments and as agile ceremonies like standups and release planning.

#9: Assuming One Size Fits All

Wouldn’t this be easier? As we mentioned in #6, capitalization is a complex, adaptive problem. A successful solution in one company would not pass Finance’s muster in another. Every company needs to create its own capitalization policy. That’s because every company has it own culture and strategy around adherence to GAAP principles: different levels of comfort regarding Conservatism and a different threshold for Materiality, as well as asset management and depreciation. Copying another organization’s policy won’t create a solution for your organization. The key to creating a simple and defensible solution that works for your organization is to involve the right stakeholders from the get-go—Finance, technical accountants and agile leaders—and have them co-create a no-waste, defensible solution that both sides (Finance and agilists) understand,can implement, and that will leverage agility to enhance the performance of the business.

#10: Approaching the Problem in a Non-agile Way

Agile and Lean are mindsets. A practical interpretation of an agile vs. fixed mindset includes the realization that estimates are increasingly flawed in conditions of extreme change and uncertainty. Applying agile techniques to craft your agile capitalization policy is a great example of taking agile beyond engineering. The objective of Lean accounting is to eliminate waste, free up capacity, speed up the process, eliminate errors and defects and make the process clear and understandable. Instead of creating a tomb to document your capitalization rules, or creating heavy processes to track every corner for an audit-sniffer, start with a Minimal Viable Process approach (and include a “test” for your capitalization practices and policy.) Bring Finance and IT stakeholders to the table to validate and iterate on the MVP. Favor individuals and interactions over processes and tools. Establish trust and collaboration. Provide transparency and traceability. Focus on continuously learning and improving to the benefit of effective expense management and optimized business performance. You’ll be amazed at what satisfies Finance stakeholders once they understand the difference between agile development and waterfall development. They may become your biggest agile supporter!

So where do you go from here? As a start, reach across the aisle and take your technical accountant friends to lunch to initiate the partnership:

  • Understand their viewpoints on Objectivity, Materiality, Conservatism and Consistency.
  • Educate them on how agile focuses on value delivery, to create more fiscal responsibility in expense management than waterfall development.
  • Share these excellent resources with them:

Agile Capitalization for Greater Business Value

Project Labor Cost Accounting for Agile Projects

This blog :)

Most importantly, as you read the growing number of published articles and guidance on agile capitalization, remember to use your pitfall detector!

This year we expect to see more and more companies looking for ways to accurately and defensibly capitalize agile software development, and consequently there’ll be more and more agilist advice on how to implement agile capitalization without the accounting considerations discussed in this blog. There’s urgency to ensure companies striving to increase their business agility don’t create waste updating their capitalization policies with over-engineered solutions, just because they can..

I sincerely hope this blog will prevent your organization from wasting time falling into any of the 10 pitfalls. If, after reading this blog, you need help kickstarting your agile capitalization initiative to a co-create simple and defensible capitalization policy, please contact us. We can help you establish the Finance/Accounting mental models to capitalize on the financial benefits agile delivers.

Catherine Connor