Management summary

Why agile? How agile vanishes hidden costs.

Agile has a kind of haze around it. For many companies, it seems to work well, given the adoption of Scrum by millions worldwide. Many embarked on an agile transformation. First in IT, but now also in the business side of companies and other branches. This article elaborates on how Agile strengthens your bottom line. In short, Agile keeps potential hidden costs like sunk costs and switching costs low at the team level. And likewise, at the company level. With an agile way of working, shifting your focus to other initiatives is much cheaper. With less sunk cost, costs of delay, switching costs, and onboarding costs, you can easily live up to the statement of Jeff Sutherland (founder of Scrum) and writer of the book:

“Twice as much work done in half the time.”

At least, that’s how it feels. Because you have done the same amount of work but have managed to spend the time and energy on the essential work, yielding the most value compared to the effort it takes. And you gain insight into whether your assumptions about effort and value are valid and act upon them.

Moreover, it fosters employee engagement by providing a sustainable pace, focus, and relevant work, while getting from and giving feedback to the organization to optimize value while considering the feasibility of the tactics. And understanding the strategic goals via the Product Owner.

Agile has a kind of haze around it. For many companies, it seems to work well, given the adoption of Scrum by millions worldwide. First in IT, but now also in the business side of companies and other branches. Many embarked on an agile transformation. How does it improve their performance?

Agile might be of your interest if:

You are frustrated that illuminating ideas seem to take so long before being put into execution.
You feel that many projects halfway and beyond do not meet their expectations about effort or value.
Your people are so busy; some are exhausted, and retaining talent is tough.

A primary benefit of agile is that it vanishes hidden costs. So, you become more effective and get more impact with the same people:

These hidden costs are:

Sunk costs
Costs of delay
Switching costs
HR: Recruitment/onboarding costs and dropouts.

We elaborate on how an Agile organization vanishes the four types of costs. And as a bonus, it diminishes your recruitment and onboarding costs.

Agile reduces the risk of sunk costs.

Projects start with expectations of revenue and costs. With a classic project approach, while approaching the end, it becomes clear whether the needed investments or value were proper estimates. The balance is often disappointing. And a major part of invested money cannot be recovered (the simple definition of sunk cost).

The Standish Group research about projects proves the success of agile. Especially with larger projects, success rates increase with an Agile approach and trump Waterfall projects. The Standish Group “Modern” definition of success includes the following six individual attributes of success:

On Time
On Budget
On Target (scope)
On Goal
Value
User Satisfaction

Visuals derived from https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/

Agile = Testing assumptions and adjusting on the go

Agile projects also start with expectations of revenues and costs. If appealing, a multidisciplinary team allies that work out these assumptions and stay together. A great Product Owner will let the team focus on testing critical hypotheses at an early stage. So, it becomes clear whether value and effort are in appropriate balance. And better or worse than expected.

If the balance of value and effort is different, we can adjust by:

Other solutions to the same problem
Pivot to other customer segments.
If it is more laborious, change tactics that potentially increase feasibility.
Leave the initiative for now. And use your time and people for other ideas.

These adjustments can be directly embedded in nearby future time spent, especially if things are slightly different.

A good Product Owner regularly ensures that it is possible to receive feedback and that there is room to change course if necessary. A completed product is frequently delivered, where the stakeholders and customers see and experience how it works (in reality). If applying the agile framework of Scrum, this is inherent in the process by a Sprint Review ((c) Scrum Guides.org 2020). After the creation of a completed version, there should be room to say:

We will continue the same path (with some minor improvements)
We shift our course [make a block about this with examples?]
We stop further development in this initiative. Either because it’s good enough this way, or our assumptions seem too detached from reality, so we must reflect.

Sunk costs in projects

"A sunk cost is a cost that has already been incurred and cannot be recovered" (Wikipedia, 2023). The time and effort you put into a project cannot be recovered or are limited. And what’s yielded can be disappointing. The longer you put in time and money without validating whether your assumption about value is correct, the greater the risk that your sunk costs will put you in a tricky situation.

Agile working keeps the height of sunk cost low.

Agile embraces the uncertainty that reality can be different than expectations. Therefore, in the process, it is set up to inspect and adapt regularly. Each iteration ends with an organized review to explore the output and outcomes. And keeps the option open to shift focus. So, frequently one can consciously inspect a completed intermediate version. If there are any red flags, the team can shift its focus to other initiatives or a pivoted version of the original idea for reasonable costs. So, the process inherits to make transparent whether your expectations and assumptions seem plausible.

If the accomplishments disappoint, you can shift the teams’ focus (or) to other initiatives with reasonable costs. And new initiatives can take precedence over continuing existing initiatives. Or it might be that the new idea should wait a little longer because continuing the existing one seems more sensible. At least the process regularly creates a clean slate. Consequently, an actual conscious consideration is there of which initiatives deserve to get acquainted.

Agile tends to keep projects small.

When you work with Agile portfolio management (Agile scaling), making your initiative small is part of your process. The elaboration of your new idea will initially be as extensive as a quarter utmost. During the next quarterly planning, you will see what has become of it. In review sessions, you see the creations and are invited to share thoughts about perceived value, improvement points, or praise. You can share these directly with the professionals who put their best capabilities into it.

For any small item: you should be coupled to the correct Product Owner within a few redirects. He has the autonomy (note) to decide whether your suggestion is valuable enough to be accomplished by his team. Consequently, easy improvements integrate with minor overhead. And with continuously wise consideration of value relative to the effort. You can find smart solutions when the system facilitates directly negotiating the problem/idea owner with the professionals. Thus, you can pick low-hanging fruit all year!

In contrast, this low-hanging fruit often is squeezed in classic project organizations. The minor frustrations of a backend department need to be more critical to discuss by the management and harness a project. Therefore, it is often not reaching the people who can make it happen. While in agile organizations, all services and products reside in some team, which improves and maintains them. And have a clear person to turn to: the Product Owner. So, with minor overhead, problems can be considered interesting enough to be tackled.

Affordable and conscious costs of delay

At every company, new ideas regularly emerge on how to improve things and how we should solve problems or take advantage of opportunities. Especially while waiting for solutions, costs rise, or benefits evaporate. These are the costs of delay (Wikipedia, 2023). With an excellent agile ecosystem, the next Sprint might contain changes and be readily available in the next released software or product, especially if the effort is minor. Then, delay costs are limited by a few weeks, sometimes even days!

In the case of more extensive urgent changes, it may be more appropriate to consider whether the new idea is more important than the current workload. By the Product Owners or their upper management during the quarter. Or during the quarterly planning, if it can wait or when it is near in time. In any case, it leads to the discussion about which initiatives seem to have the best value-for-effort ratio. And it prevents teams from becoming overloaded so that everything will go slowly.

Contrary to classic project management, new initiatives often superimpose existing ones. And people will divide their time over multiple projects, which will incur more switching costs. And everything is going slowly—or at least not the most crucial thing as the fastest.

In that reality, the discussion often blames people’s performance. It does not make it visible that the organization has to decide which work has priority and what the company can afford. Or one chooses to vacate another project quickly but not in a steady state. As a result, the value is suboptimal in the meantime. And if the work continues later, people must find out where they left the project and how they can start contributing again. So, incurring high switching costs for this vacated project.

How observable are your switching costs?

So, in a classic project management environment, shifting your focus to other initiatives or pivoting the approach often comprise sunk costs, switching costs, and costs of delay. However, these costs take wisdom to observe and are tough to quantify. There are not noted in Excel sheets or your ERP system. Therefore, these are hidden costs. And often, these costs are neglected.

You see what you have spent (sunk costs) in those accounting systems and your expectations about the value. How valid are these still? Most people can see that the yield is minimal when one vacates a project. Therefore, they tend to prolong these projects to get the result. They fall into the sunk cost fallacy. On top, they superimpose the new ones. Consequently, all projects are slow, and hidden costs are high.

In contrast, an agile environment prepares you to shift your investments to other ventures. It splits the work into versions with regularly a steady state. One can inspect and adapt to whether expectations are coming true. And if disappointing, it is not too expensive to change course. This keeps the potential height of sunk costs low, creates low switching costs, and limits delay costs. On top, it’s easy to integrate the low-hanging fruit improvements because all products and services have a team ready to update these. Moreover, it provides a healthy work environment for your professionals working on feasible tactics to reach goals and get feedback on their work. Naturally, this ecosystem spends more on finishing and aligning. But they can focus their efforts on the most valuable work.

Switching costs on various levels

Switching costs on the task level

If you look at any data from lead times: Lead time is the time that passes from when a new work item is requested to the point completed. [see Kanbanize.com for more info]. In most enterprises, much work in progress is primarily stagnant, waiting for the next team/person to start working on it. Taking the waiting time out leads to a much shorter lead time: from the start of processing to delivery. That’s the trick you need to organize!

There are three principal tactics to limit switching costs: First, bring the people who need to complement each other together in a team to deliver the work smoothly. In agile, we call these multidisciplinary or cross-functional teams. Second, limit the work in progress to ensure the work flows through the team. Once the work starts, it’s predictable when it is finished. "We are working on it" means something: it predicts that deliveries will occur within a specific time range in 95% of the cases. In the agile framework Kanban, we call this cycle time.

The third tactic is one channel of work (Backlog) managed by a Product Owner. The potential work is transparent in a Backlog system (Jira, Azure DevOps, or others). And the Product Owner takes care to focus the efforts on the team on the most valuable work. And a good one ensures to validation of hypotheses early. Next, he acknowledges the team’s capabilities, so the professionals do not enter a situation with too much work. Many professionals like that situation, where it’s clear which work they can focus on and why it’s essential! Also, it makes transparent that the pace is an initiative that can progress and creates a sustainable pace for the professionals in the teams.

In contrast – in classic project management – people tend to be part of multiple projects. This allocation of people often results in periods where they have more work than they can accomplish. As a result, they must switch often. Let go of a task and get back to work on it later. When you start working on it again, you must figure out first: Where had I gone? What was the intention? Has something changed in the meantime? So that it may no longer apply or need to be changed? The switching costs increase with the time that it has been idle. And if you take over from someone else, those switching costs are even higher. Even if you’ve logged the status, you should figure out what should be the next step?

So, this indivertible stop-start pattern makes each professional face switching costs on the task level.

Switching costs on the initiative (project) level.

Additionally, how are the various projects weighted to each other in priority? Naturally, each project manager shall say their project is most important or pressure people to work on their project! This competition of time puts the consideration of priority on the shoulders of the individual professional. So, all people in the organization are then busy with figuring out what should get focused on daily bases. This imposes stress. Then they must decide which work to accomplish without oversight, what matters the most—or spending time on an individual level to get that oversight and align. What are the chances of doing it right?

On a project level, the stop-starting pattern results in most projects going slow. Each project goes as fast as the bottleneck (The Goal- Goldratt): The person or department most overburdened with work determines the pace. Especially if it collides with multiple projects at the time needing the same resource, this is asked for especially if deadlines for various projects are set for the end of the year, for example. The resources required at the last phases of projects tend to make this pattern most visible (final editing, testing). They are often in the most pinched. And as a result, quality is squeezed.

So, the classical project organization tends to incur switching costs on the task and project levels. This situation makes it plausible that professionals often do not work on the most critical or valuable work. While work is becoming obsolete, waiting in queues and switching costs are rising.

In agile, the queues are transparent Backlogs and are continuously ordered in priority and managed by Product Owners. The Work in Progress is kept low. As a result, the switching costs are kept low, and cycle times are predictable. The permanent team learns how much work they can do together in a particular unit of time. So that they do not overload themselves. They organize themselves with focus, a core value of Scrum. So, switching costs can never become high. This makes it straightforward for the professionals what work gets focused on and makes lead times short, which should and at least make the cycle time predictable. This approach lowers switching costs and prevents half-done work gets obsolete. So, the time of the professionals is spent effectively.

Diminish recruitment and onboarding costs.

On top of it, agile working creates engaged employees by having relevant, focused goals with feasible tactics and a sustainable pace. They get fast feedback from their professional peers and stakeholders, including praise. People in agile organizations feel they are taken seriously as a human and a professional. Not being forced into arduous positions. Therefore, the chance that your retention will increase, especially from your best people. As a result, you spend less on recruiting and onboarding people.

Proofed by my Xebian colleagues [best in class engineers and consultants]. They prefer an environment where they at least claim to be agile. They are neutral or supportive of an agile way of working, but none of them disagrees.

Clarity and focus for professionals

Professionals in an excellent agile ecosystem know which work to tackle first. Most individuals no longer have to consider which initiative they will work on today and be accountable to several project leaders. One Product Owner coordinates the priorities for them. The most urgent work is understood at the beginning of each iteration (Sprint). Within the iteration, the team members are allowed to organize themselves so that the best result is achieved at the end of the iteration. And the outcome and output are reviewed to validate hypotheses about feasibility and value.

Within the Scrum framework, each professional resides in one agile team. And each team has a Product Owner who coordinates the matters to be picked up. We are continuously working on clarifying what is expected (Refinement). A professional, therefore, receives work from one channel with a face. Which is clear and responsive; this reduces stress and peak load.

Continuous consideration and learning about the effort value ratio

A good Product Owner always makes the assessment and negotiation: what is the value/effort ratio? And tries to get the value up and the effort down. The Scrum process inherits that after any accomplishment, feedback is gathered. This process fosters insight for stakeholders and professionals on the value/effort ratio. Stakeholders increasingly understand what requires a lot and what requires little effort. The professionals are getting insights into what is more and less valued by the stakeholders and customers.

Conclusion | Why agile? How agile vanishes hidden costs.

In short, Agile keeps potential hidden costs like sunk costs and switching costs low at the team level. And likewise, at the company level. With an agile way of working, shifting your focus to other initiatives is much cheaper. With less sunk cost, costs of delay, switching costs, and onboarding costs, you can easily live up to the statement of Jeff Sutherland (founder of Scrum) and writer of the book:

"Twice as much work done in half the time."

Irene is a senior agile consultant and Msc. Economics.
Do you have questions or feedback regarding this article? Please reach out to me!

Why agile? How agile vanishes hidden costs