Agile works, and the combination of agile and DevOps works extraordinarily well, initially. But as agile teams grow and mature, they often run up against a roadblock that limits further improvements. This obstacle comes in the form of the project cost accounting organization. Luckily, it doesn't have to be this way. An alternative approach, lean accounting, can help.
The sad fact is that cost accounting, which limits agility, is still very common. The situation isn't accounting's fault. The department uses a model inherited from the early 1900s that runs in direct opposition to agile. It hails from the era of labor-intensive mass manufacturing. It's guided by the command-and-control managerial philosophy of Taylorism, which strives to plan every detail of an operation up front, expects managers to direct and monitor workers to do the work as planned, and views workers as interchangeable cogs. This produces large chunks of preplanned work and measures success by conformance to the plan.
By contrast, agile seeks to connect and nurture cross-functional teams to deliver value in the form of products and services delivered to customers as quickly as possible. It produces small chunks of minimally defined work for rapid iteration and feedback, to ensure continuous improvement. Agile practitioners measure success by the value delivered to?and feedback received from?customers. Agile orchestrates work activities into value streams that cut across organizational boundaries and optimize for overall quality and cycle times.
In most organizations, the introduction of agile practices in IT forces these two models to work together, yet the difference between them is stark: agile collects data and feedback on continuous processes and uses it to guide the overall effectiveness of activities, while cost accounting measures the silos. Ironically, traditional cost accounting firmly ties agile projects to its waterfall model, the very thing from which agile is supposed to help organizations to escape.
What's needed is a gradual transition to lean accounting. Agile development organizations can play a key role in this transition by helping the organization see the benefits of this alternative practice. But first everyone needs to understand why the old system is broken.
How things go wrong
The first thing that happens in the traditional cost accounting scenario is that the definition of success slowly changes from "rapidly deliver customer value and get feedback" to "complete the work according to schedule." The shift in emphasis moves away from the agile goal of delivering value to the customer.
The second thing that goes wrong is that the volume and nature of up front planning expands in order to secure the funding for the project, resulting in large projects with long time frames and massive backlogs.
The third thing that goes wrong is what I call creeping Taylorism: as perceived productivity slows or varies unexpectedly, management introduces more structure, ceremony, and measurement to manage agile activities.
Eventually, the team loses its connection to creating customer value entirely, and questionable metrics of productivity, such as story points completed per iteration, replace useful measures of actual customer value delivered.
This isn't an intentional sabotaging of agile efforts, and it doesn't happen overnight. It's the unintended consequence of two incompatible models pushing against each other. Since accounting controls the money, it's no surprise which model, if left unchecked, will ultimately win.
All organizations eventually reach a tipping point: either they make the organizational changes necessary to move forward in support of agile teams, or they choose not to and begin to lose their agile team members, sliding back into the waterfall approach.
When that happens, scrum becomes a painful path from waterfall to waterfall. When you know how many story points you completed during each iteration but don't know what value you delivered to customers, you're back to waterfall. You might as well turn your backlog sideways and call it a Gantt chart. If you want to kill your company's agile initiatives, this is the way to do it. So how do you fix it?
Releasing developers and managers from the trap
Both software developers and managers have become victims of this systemic problem. Unfortunately, in most cases, they don't have the authority to fix it themselves. Because the symptoms of this agile illness are subtle, easy to misdiagnose, and occur slowly, even recognizing the problem can be difficult. Often, people only wake up to this after receiving an outside perspective that cuts through the "this is normal" illusion.
When this happens, understand that the problem isn't a failure of agile practices or technical talent or anything IT can control but of more general organizational structures. These structures must change before you can continue to improve delivery.
Lean project management can resolve this conflict by freeing agile from the quicksand of institutional Taylorism. If you're the CFO or the CIO, you can go ahead and make things happen. But if you're working with an agile development team, how can you get this transition started?
Conducting a short, successful experiment is critical to acceptance. You can start by citing companies that have successfully transitioned to lean project management and that are now outperforming their peers. However, management may ignore these stories, arguing that your business or industry is different. You need to prove your case by creating a success story within your own organization, no matter how small.
Get accounting involved
The project cost accounting model must change, but the solution has to be mutual, and the results must serve the interests of everyone who reads those accounting reports. The first step is to shift the focus from tracking costs by department to modeling costs per value stream. But don't worry, you don't have to convince accounting to shift everything at once.
Instead, find a friendly accountant and discuss how you might use a lean accounting model as an addition to the current system, just for the scope of a small experiment lasting a few weeks at most. A small application or desirable feature that has strong revenue potential is best, even if it's only hypothetical. The point here is to start having the conversations necessary to begin to shift accounting viewpoints in the direction of lean.
Show your accountant a value stream model for the experiment and discuss the cost and revenue points. The new model must measure the value delivered, which might be revenue, but could also be something more abstract, but still quantifiable, such as user engagement. There should be only one such measure, the "one metric that matters" for your organization.
Take baby steps, but move fast
Proceed in the execution of the experiment by taking the smallest possible steps at each iteration. Slice the stories as thinly as possible and iterate as quickly as possible to produce value; this might be considerably less work per iteration than even a minimum viable product (MVP) approach. You want to produce something that will move the needle on the one metric that matters as soon as possible.
If the metric moves in a positive direction, continue the experiment with the next thin slice. It's okay to iterate on one story multiple times, especially if each time you produce an improvement in value delivered. The point isn't to finish the story or to complete the initial plan or anything related to the execution of the process. The point is to learn how to improve the value delivered. If the expected value isn't being delivered, figure out why and adjust, changing the definition and measure of success if necessary.
Assuming that you achieve at least a modicum of success, your next step is to compare the value delivered with the cost of delivering it. Did the needle move enough to justify continuing the experiment? Look at the costs involved. Are they predictable? Chances are that they're not only predictable but stable, and possibly even fixed. If it took your team two days to produce the first iteration, the cost was two days of your team's time. If the value delivered is worth more than that, the experiment should continue. If not, and if you don't think the next experiment is likely to do better, then stop and try a different experiment.
The overhead associated with starting and stopping this experimental value stream should be negligible, so deciding to cancel a particular experiment isn't a failure?it's the fiscally responsible thing to do. Accounting should like that.
Expand the practice and go viral
If the experiment produces the expected value, celebrate and do more experiments. If it fails to produce the expected value, celebrate that too and proceed with different experiments. The success or failure of the particular thing built and delivered isn't important, although a successful result is easier to evangelize. What you're really concerned about is the success of the lean accounting model. The experiment and experience should be sufficient to get people more interested in lean accounting models and practices. If you continue and expand these experiments over time, people will eventually come to accept the idea that much, if not all, of the old accounting model is no longer necessary or helpful, that a project doesn't have to be a five-year mission to be worthy of funding, and that value streams offer a more efficient and informative model for operational accounting.
Do this and the barrier will be broken, your agile processes will be free to continue improving, and your organization may even be ready to continue and complete its transition to a lean enterprise in which everyone is truly agile.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
