You are hereFeed aggregator
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.
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 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: http://www.forbes.com/sites/benkepes/2013/12/17/avons-failed-sap-implementation-a-perfect-example-of-enterprise-it-revolution Image attribution: http://photodune.net/
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 →
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
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 ...
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!* https://www.rallydev.com/resource/business-agility-survival-guide
All About Agile - Thu, 03/03/2016 - 06:23
Oikosofy have written this list of the top 100 agile blogs or web sites: http://blog.oikosofy.com/100-top-agile-blogs-from-2015/ 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.
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 […]
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.
#7: Over-engineering the Solution
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.
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:
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
All About Agile - Tue, 02/02/2016 - 12:00
I want a number, a metric, that tells me how productive our teams are”
challenged my former Head of IT, some years ago. Certainly, it’s a reasonable request to ask how productive a team (or a whole system) is.
But first let’s look at the why behind the question. Why do we measure productivity? Because we should? Because we can? For transparency? Accountability? To drive behaviors and influence culture? Should we measure it at all?
There are three simple, impactful metrics (for Agile or Waterfall workplaces) that I informally collect (through conversations is a good start) to quickly gauge productivity and how healthy and high-performing an organization is.Lead Time
Lead time is the queen of metrics. Lead time tells me how long it takes work to travel through the whole system, from concept to cash:
How quickly is value delivered to customers? Long lead times indicate waste. Lean experts Mary and Tom Poppendieck describe how over 80 percent of time-to-market can be “waste” in the form of delays and non-value-added work. That quickly snowballs into a double-pronged, multi-million dollar cost of delay that directly hits a company’s profits via the delay in value delivered to customers and thousands of wasted person hours.
What do long lead times look like in the real world?
This week I’m working with the largest company of its type in this state. It regularly takes up to six months to get a business case approved, and another 12 months to deliver a project. That’s an 18-month lead time to deliver value to customers. Given that requirements change at an average rate of around 2 percent per month (based on Capers Jones’ empirical research in the 20th century, and it’s probably higher in 2016,) this means a project that goes live today is delivering requirements that were signed off on 12 months ago and have changed (degraded?) by over 24 percent.
This company’s volume of work is expected to increase at least 30 percent in the near future (with no headcount increase.) What happens when we add 30 percent greater volume to an already chockablock freeway? It reduces our speed by an order of magnitude.
This company is adding risk to its portfolio by having such long lead times. Are the teams productive? Not nearly as productive they could be. What actions should they take to reduce lead times? Just reducing the batch size of work (e.g. from 12-month projects into small, discrete features) and setting work in progress (WiP) limits will often double throughput (i.e. halve lead time) as described by Lean management guru Don Reinertsen. These are things you can start doing sooner rather than later.
But, by itself, lead time doesn’t tell me how productive a team is.Predictability
Predictability complements lead time and has an equal seat at the head of the table as the king of metrics. Not only do I want a short lead time, I want to reliably know when work will be done and when value will be delivered to customers. Predictability is not boring—it’s the new black. And it’s sure better than 50 shades of grey, so to speak, in terms of guessing when something might be delivered.
The city I’m working in suffered floods not so long ago. I asked my client, whose offices overlook the river, whether the council knows the volume of water in the river and its rate of flow, i.e. how much water flows into the nearby sea every day. “Of course,” he replied. “So, what about your portfolio? What volume of work can it handle and how quickly will that work flow out to customers?” My client didn’t even pause.We don’t know. We don’t really know what our capacity is at the portfolio level or how quickly we can deliver work.”
That’s not unusual in this type of organization. It would be unusual in manufacturing, where every widget is a physical item and easily traceable. But where work is less tangible it’s easy for “invisible waste” to significantly erode capacity.
Predictable delivery not only increases profits and reduces bottlenecks, it has a more important outcome: it creates trust, trust that teams will deliver on time and that the portfolio can and will deliver the number of features (or requirements) promised. I give my business to companies I can trust—that deliver when they say they will—over companies that don’t deliver when they say they will.
What actions can you take to increase predictability? You need to know the capacity and velocity of your portfolio. Once your requirements are logically grouped into features (see above,) use relative sizing (starting with a small-ish and well-understood feature) to quickly get a view of how much work is in-flight and in the pipeline.
T-shirt sizing is fine if your stakeholders are new to story points (which you can later map over the t-shirt sizes.) It will probably be “way too much” work, which is where prioritization comes in (a topic for another time.) Then, populate “just enough” features to be assigned to the next program increment (say, 12 weeks.) And do this activity with the people close to the work, not far-removed stakeholders.
When I find a company (or a team) with short lead times and high predictability, it’s a good indication that it is productive (although it doesn’t tell me that they are delivering the right things—another topic for another time.) But there’s one other metric that trumps both lead times and predictability.Happiness
Happiness is the most important metric because in a knowledge economy, talented people are the competitive advantage. Are our people (and customers) happy? Simplistically, happy employees deliver good products, which lead to happy customers and good profits. And, the reverse is usually true: an unhappy employee is more likely to deliver a poorer product, leading to unhappy customers and poorer profits. "People, products and profits—in that order,” as our own CA Agile Business Unit GM, Angela Tucci, reiterates. I want to know if my employees are happy or unhappy and why, because it’s closely linked to motivation. As Dan Pink’s now cult classic video explains, give your people autonomy, mastery and purpose and they will be motivated to change the world.
How do we find out whether our people are happy? Ask. Not (just) via an anonymous, annual, online tick box survey. Ask via team retrospectives. Ask via one-on-one or small group sessions. Use a simple 1-5 Likert scale if you want an easy way to quantify the qualitative data. Ask what’s making people happy and unhappy. Frequently improving what’s making people and teams unhappy improves our other two metrics: lead time and predictability.
For example, my client is generally happy but is anxious because the organisation needs to pull 30 percent more work through the “system” as part of its growth objectives. My client’s teams perform reasonably well but are frustrated because there are bottlenecks around key roles and these delays generate significant non-value-added workarounds. Improving these problems would make these people happier and improve lead times and predictability, and lead to happier customers and greater profits.
Let’s return to my former Head of IT and the quest for a single metric for productivity: this may be a holy grail for another explorer. But, armed with metrics for lead time, predictability and happiness, I can reasonably and efficiently infer sustainable productivity—not only at a team level, but at a portfolio and company level.
And so can you.Suzanne Nottage
All About Agile - Mon, 01/18/2016 - 15:46
Over the last 30 years at work, I have observed many re-structures. Some I was part of. Some I created. Some worked. Some didn’t. And some created only marginal benefits. Others – in more recent years – were truly transformational and catapulted team performance to a whole new level. I have always been fascinated by […]
All About Agile - Fri, 01/15/2016 - 12:45
Enterprise tipping is NOT the corporate version of cow tipping, although it is fun to play with the analogy. ;)
Consider rewriting the following description of cow tipping (Wikipedia) replacing “cattle” and “cows” with “business units.”
"The urban legend of cow tipping relies upon the presumption that cattle are slow-moving, dim-witted, and weak-legged, thus easily pushed over without much force. Some versions of the legend suggest that because cows sleep standing up, it is possible to approach them and push them over without the animals reacting. However, cows only sleep lightly while standing up, and they are easily awoken from this state. Furthermore, numerous sources have questioned the practice's feasibility, since most cows weigh over half a ton, and easily resist any lesser force."
We often approach agile adoptions in large enterprises as if it’s possible to “approach them and push them over without the animals reacting.” For example, I often run into an enterprise agile adoption objective of transitioning 90 percent of the enterprise to agile development in 12 months. The reality is more involved; more like a sports or dance team getting great at what they do, as described by Peter Senge1:
“At some time or another, most of us have been a member of a ‘great team.’ It might have been in sports, or the performing arts, or perhaps in our work. Regardless of the setting, we probably remember the trust, the relationships, the acceptance, the synergy—and the results that we achieved. But we often forget that great teams rarely start off as great. Usually, they start as a group of individuals. It takes time to develop the knowledge of working as a whole, just as it takes time to develop knowledge of walking or riding a bicycle. In other words, great teams are learning organizations—groups of people who, over time, enhance their capacity to create what they truly desire to create.”
As an agile transformation consultant, I’ve developed two rules of three to remind myself and my clients about the challenging, yet rewarding work of tipping the enterprise toward a new way of working.Muscle Memory Rule of Three
Scrum coaches are well aware of the muscle memory rule of three. It takes at least three iterations for a team to get comfortable with the rhythm of Scrum and its ceremonies, and develop a sustainable practice and velocity that allows it to plan and execute longer range. Think of Scrum as square dancing. It’s not enough to go through the dance moves just once; it takes multiple repetitions for the rhythm and coordination of the dance to sink in—the dancers need to develop muscle memory.
When scaling this iterative, incremental approach to a team of teams in frameworks such as the Scaled Agile Framework® (SAFe®), this same muscle memory rule of three applies. The team of teams needs to experience the rhythm and coordination of SAFe at the program level to get familiar with it.
Think of SAFe at the program level as a troupe of square dance teams that needs to dance together with moves between the teams (e.g., passing bandanas or cowboy hats). The planning event is where the dance of the upcoming program increment and the moves between teams are discussed. Like square dancing at the team level, it takes multiple passes at dancing at the team of teams level for the troupe to develop good coordination. In other words, it takes multiple program increments for the team of teams to get good at coordinated development and at handling dependencies between teams.
Here at CA, Agility Services has developed an approach to launching a program (a team of teams) called Ready > Sync > Go. During the Sync phase, each team gets good at dancing as a team while the program-level folks plan the coordinated dance of the team of teams. Once the teams and the coordinated dance plan are ready, the program holds its first planning event to launch the coordinated development of the team of teams. CA Agile consultants make sure the client organization builds its muscle memory for this coordinated dance by applying the rule of three.
Before moving on, I want to make a caveat. The muscle memory rule of three is not sufficient for a team or a team of teams to get great at the dance; merely good enough to improve on their own. I do believe in Malcolm Gladwell’s assertion (from his book “Outliers”) that it takes roughly 10,000 hours of practice to achieve mastery in a field. Finally, mastering agile development involves more than the iterative, incremental process pattern of Scrum and SAFe.Organizational Learning Rule of Three
Personal change is hard; changing how we work as an organization is harder. As a transformation consultant, I frequently hear comments like, “We’ve been doing development this way all of my career, what’s wrong with it?” I’ve learned through experience that this reaction is not a request for the rationale behind a new way of developing, it’s a request for empathy. Organizational change is threatening. No amount of rational argument on my part, as an external consultant, is going to ease that discomfort.
I developed the organizational rule of three while addressing this resistance to organizational change. There’s a progression to overcoming this resistance even in the face of successfully launching programs, and here’s what it often looks like:
With the successful launch of the first program, I hear, “Well, we got lucky, we picked a good set of teams and an application area that is well-suited to agile development.”
The second successful program launch helps dispel the “we got lucky” rationale.
With the third successful program launch, the organization starts to own the process and make it part of its DNA.
Only when we reach this point has the organization reached the tipping point, that is, the point of no return. In his book “Tipping Point,” Malcom Gladwell describes it as:
“The tipping point is that magic moment when an idea, trend, or social behavior crosses a threshold, tips, and spreads like wildfire.”
When I work with an organization’s Agile Center of Excellence (COE), I describe this tipping point as the moment when the center stops pushing agile development and the organization starts pulling the center’s coaching services.
I don’t believe in big-bang transformations. In an enterprise with multiple business units, tipping the enterprise entails tipping individual business units. And like the progression of overcoming organizational resistance with respect to successful program launches, you have to tip multiple business units to tip the enterprise as a whole.
In this figure, the red down arrow represents the tipping point for that organizational unit and reaching that tipping point entails the rule of three with respect to the subunits.Implications of the Rules of Three
The principal implication is that the urban legend of cow tipping is a bad mental model for enterprise tipping. We should dispel the myth that this is a simple, quick methodology change.
Enterprise tipping (truly changing the way an organization works) requires patience, focused effort and leadership.
It’s why John Kotter’s 8-Step Process for leading such a change starts with:
1. Create a sense of urgency
2. Build a guiding coalition
3. Form strategic vision and initiative
And ends with:
6. Generate short term wins
7. Sustain acceleration
8. Institute change
An Agile COE can help focus an enterprise’s agile adoption tipping initiative. I’ll talk more about them in the next blog post in this series. Stay tuned.
1. Senge, Peter M., The Fifth Discipline Fieldbook: Strategies and Tools for Building a Learning Organization, The Crown Publishing Group, 2014.Jim Tremlett
All About Agile - Thu, 01/14/2016 - 06:00
I did a post last week called ‘Are People Really Afraid To Change’. If you have a minute, go check it out before you read on… we’ll wait… I’ve never been skydiving. Almost went in my early 20’s, but when the time came to go, I didn’t have any money so I had to stay […]
All About Agile - Mon, 01/11/2016 - 06:00
Thought Exercise One Let’s say for the moment that I am the CIO of a mid-sized company. I have a team of 100 or so people building software. Let’s also say that those 100 people are largely dedicated to 10-15 smaller products, there are few dependencies between those products, and we are currently using traditional […]