In Agile, what do you call the costs of building infrastructure for the first release?

Question

Stakeholders who are new to agile are expecting thin slices of value per each release, so when we start new projects they are confused when we need large infrastructure costs.

We minimise the infrastructure costs to those enabling that first customer feature, but in some large enterprise projects, the infrastructure costs are significantly larger than the first feature.

Stakeholders will usually go through the same thought process, along the lines of

• This is not a thin slice, so its not agile.
• Can we start with the second feature? (nice try)
• Can you make it smaller? (let's assume we cannot go smaller, for the sake of this question)

I've read about classifying the infrastructure costs as business value rather than customer value, but this question is more related to the initial (large) cost of the business value and how we can describe that.

Is there an industry agile-friendly term to describe this initial cost?

Answer 1

TL;DR

Some frameworks have a distinct name for the type of work you're asking about, but some don't. To understand why, a short preface is in order.

Work is work. While it's sometimes necessary to differentiate different types of work for cost-accounting or political reasons, treat this as an opportunity to educate your organization and your stakeholders that there's no such thing as a free lunch. In agile frameworks, all work should be fully visible as a cost to the project.

There may also be a more fundamental concern than differentiating types of work. The scale of upfront architectural and infrastructure work in your diagram suggests that you may be violating a core agile principle:

Simplicity--the art of maximizing the amount of work not done--is essential.

Your team and your organization should certainly evaluate the minimum amount of planning, infrastructure, and engineering (collectively resources) necessary to carry out the near-term increments. In a successful agile implementation, your infrastructure and design will evolve iteratively along with your product.

Don't Overly Constraint Your Definition of "Value"

In general, effective agile implementations don't separate out user-facing value from work that's valuable (and frequently essential) to the process as a whole. The idea that all "value" must be customer-facing value is not correct.

In the most commonly-used user story format, the who in the story is a consumer of value, but that viewpoint character need not be an end user or customer, and the value may be anything that the Product Owner, sponsor, or stakeholders are willing to spend project resources on.

That said, the goal is to avoid "big, upfront design." So, a logical question to ask during each planning session is: What are the mininum resources or architectural/technical choices necessary to deliver a slice of value this iteration?

SAFe, Architectural Runway, and Enablers

SAFe calls this minimum necessary infrastructure the architectural runway.

The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay....Since the development of new features and capabilities consumes the architectural runway, continual investment must be made to extend it by implementing Enablers.

It further explains Enablers this way:

Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development...Primarily, enablers are used for exploration, evolving the architecture, Compliance, and to improve the infrastructure.

However, this is not permission to dive into big, upfront design and infrastructure investment. SAFe, like most agile frameworks, is based on principles of emergent design and just-in-time architecture, and delays investment in infrastructure until the last responsible moment. This is sometimes referred to as YAGNI.

But Enablers aren't really a special kind of work, even though SAFe insists on giving it a special name.

[Since Enablers] reflect the real work (and sometimes plenty of it), they cannot remain invisible. Rather, they’re treated like all other value-added development activities—subject to estimating, visibility and tracking, Work in Process (WIP) limits, feedback, and presentation of results.

In short, such tasks are value-added work that should be treated just like any other work necessary to develop the increment during an iteration. SAFe spills a lot of ink unpacking this concept, while other frameworks tuck it away in the notion of "vertical slices" or just-in-time resource planning.

Answer 2

There are a few points to consider on this.

1) Scrum uses PBIs. Product Backlog Items are all the things that make up the product backlog. Any item that you have to do can be an item in the product backlog. You can use user stories and spikes, and all kinds of other special techniques in doing your work, but there is nothing that says "Walk the dog" isn't a perfectly valid PBI (or more realistically, deploy "35 application servers").

2) Minimum Viable Product, Minimum Marketable Feature, Prototyping, User Stories, and about a dozen other techniques commonly used in Agile practices encourage you to wrap this work into other work that either produces customer value or creates validated learning. This idea actually comes from Lean and is mostly about eliminating waste. Let's say I want to deploy an robust infrastructure environment with load balancing, mirrored database servers spread out across the country, multiple domain controllers, etc, etc, etc. Now, I'm just starting development and I have a small customer team who uses the application and maybe I need two servers to support that. Well building and maintaining the rest of those servers is just waste, so by only doing the "back-end" work I have to do in order to deliver on the value, then add in the mirroring, load balancing, and the rest of it as I need it.

3) Ironically, only delivering the back-end work you need is sometimes exactly what creates the need for PBIs that read "deploy the other 14 servers". C'est la vie.

4) Please, let's not make up new terms just to sound more agile. I've seen a lot of this over the past decade (I'm looking at you "Technical User Stories"). There are some practices like User Stories and Spikes where you are doing something distinctly different. Those deserve their own term because it helps indicate that you are using that specific technique. If you are doing the exact same thing as you have in the past, feel free to use the same name you always have. It doesn't make you any less agile.

Answer 3

Agile is all about (sometimes brutal) transparency.

If the initial feature release requires a lot of expense and effort then that is what should be reflected.

The release of Customer Facing Feature 1 has involved a lot of time, effort and cost

A good agile organisation will question this. Perhaps they will ask:

• Is this really the minimum viable release?
• Is there anything we can do to reduce setup costs (automation, provisioning, cloud computing, etc)

It may be they conclude that it is worth a large investment to create a rapid infrastructure bootstrap process.

Answer 4

Some of that initial infrastructure can be demo'd to customers at sprint reviews to help educate them on why and how it is delivering things that are of value to them. For example, CI/CD:

• "Look, my tests will run every time I commit/merge something! And if I commit something wrong... (do so)... look, it tells me right away! This buys us both quality and efficiency in developer time. Wooohoo!"

• "Look, the entire deployment process is automated. With just one command (or whatever), the whole system rolls off the repository and into production. Woohoo! This will let us do releases quickly and cheaply, and save expensive developer time for adding features."

You get the idea. Basically, break that giant initial infrastructure block into small pieces, and show them off as you do each one.

You don't have to (and probably shouldn't) go into technical detail, but bringing the customer "behind the curtain" with your team as you're doing this initial investment work will help them understand going forward that not all work is visible.

Edited to add: I did not answer your question as posed, but the underlying question seems to be "how do I communicate about the initial infrastructure to my customers so that they won't be confused".

Answer 5

It's worth noting that architecture and requirements emerge throughout a project. Emergence of requirements is a focal point of empiricism. Architecture should be negotiated and designed during planning and refinement based upon what you can build this sprint that will provide value to your stakeholders. If you need all of this in order to meet your sprint goal, then that should be conveyed to stakeholders in a transparent manner. Using your product and sprint backlogs to drive the conversation and convey these dependencies is a good place to start as they are clear visualizations of what you need to meet your goal.

To answer your question: those are simply dependencies your team needs to meet their sprint goal, assuming your sprint goal is to be ready for release 1 by the end of the sprint. If your sprint goal is something other than to be ready for release 1, then it's possible the work can be broken up, thus breaking up the need for all those upfront dependencies until they're needed to meet a sprint goal.

Answer 6

The plain answer to your question is: No, there is no scrum term for initial costs. Those costs are table stakes required regardless of methodology.

Some scrum orgs do this work for the customer (the business) in a Sprint Zero, which sets the table for all future work. Size Sprint Zero investments (time/$/people/etc) as you see fit. Work for additional customers, based on Sprint Zero's output, is delivered starting in Sprint 1.

Maybe framing your situation this way would satisfy your stakeholders?