How many times, in modern engineering, have you heard someone say: "This delivery will generate value for the business"? And how many times, in practice, what was celebrated was merely the completion of a module or an entire system, without operations, user experience, or company strategy actually changing? When value is tied to the "complete system" milestone, the cost appears as wasted time, locked investment, and missed opportunities. This article explores what value means in an agile context, how to decompose it into types and flows, and how to identify and deliver it before the final product.
1. The myth of "value = complete delivery"
When value is conditioned on the "system or feature complete" milestone, the team waits for the entire payment module, the ERP integration API, or the complete operations dashboard. Meanwhile, the business keeps losing money on manual processes, delayed decisions, and bottlenecks that no one sees in the backlog. The Agile Manifesto already pointed in the opposite direction:
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." — Principles behind the Agile Manifesto (2001)
"Early and continuous" presupposes that valuable software can appear in usable slices, not only on go-live day. An internal API that allows the support team to check order status in real time reduces rework and customer response time even without the final product interface. A technical increment that automates staging environment deployment shortens the feedback cycle and operational cost, even if the end user never sees that pipeline. An endpoint that exposes consolidated data for a management report can enable strategic decisions before the "complete" BI system. In all these cases, value lies in what is already in use and generating effect.
Don Reinertsen, in The Principles of Product Development Flow, formalizes the consequence of delaying value: the cost of delay. Each day that a usable delivery is blocked behind "incomplete" work has a measurable economic cost: lost opportunity, deferred revenue, accumulated risk. When the team treats "value" as something that only exists at the "complete system" milestone, this cost extends until go-live. The economics of delay is relentless: value delivered today is worth more than the same value delivered six months from now, due to time discounting and uncertainty reduction. Frameworks like WSJF (Weighted Shortest Job First), used in SAFe and lean contexts, make this explicit: prioritize by cost of delay divided by job duration, favoring deliveries that generate value sooner, even if "incomplete" in terms of total scope.
In cognitive psychology, completion bias leads people and teams to overvalue the "finished" state of a task compared to intermediate usable states. The brain prefers marking something as "100% done" rather than recognizing that a well-chosen 30% already generates impact. In product management and engineering, this bias translates into backlogs that only consider "delivered" the entire epic, the closed module, the complete system. Breaking this pattern requires making explicit that value can be partial and usable: a thin vertical slice that crosses stack and business and that someone (user, operations, another team) already consumes.
Little's Law, from queuing theory, relates WIP (work in progress), throughput, and lead time: in steady state, lead time = WIP / throughput. When WIP grows because the team accumulates work until the "complete system," the lead time to the first delivered value skyrockets. Reducing batch size (the unit of "complete delivery" that is required) reduces effective WIP per initiative and allows value to flow in smaller intervals. The myth of "value = complete delivery" ignores this dynamic and concentrates risk and return at a single point in time, instead of distributing both along the flow.
2. Types of value in agility and software engineering
In software engineering and agility, value appears in various forms: financial, strategic, experiential, operational, technical, learning, reputational, compliance. Each of these facets can be delivered in increments, and each type requires different metrics and "done" criteria. Organizing value by type helps prioritize and negotiate with the business what really counts in each delivery.
| Value type | How it can be delivered incrementally |
|---|---|
| Financial / ROI | Process optimization, feature that increases conversion or reduces cost per transaction, even at small scope. |
| Strategic / alignment | Deliveries that advance product or business goals, not just "complete" a module. |
| Operational cost reduction | Automations, rework correction, elimination of manual steps. |
| Time-to-market / speed | Partial deliveries that allow testing hypotheses or capturing opportunities before competitors. |
| User experience (UX) | A minimal improvement in a critical flow already generates perceived value. |
| Customer satisfaction | Tests and validations with real users in small increments. |
| Reliability / availability | Stability and monitoring improvements independent of the "complete" system. |
| Software quality | Fewer bugs, less rework, less risk in future changes. |
| Maintainability / technical debt | Refactorings and patterns that enable the team to deliver faster going forward. |
| Value stream efficiency | Fewer bottlenecks, less WIP, fewer dependencies between teams. |
| Collaboration and communication | Tools, conventions, and integrations that align teams and reduce rework. |
| Learning and innovation | Experiments, prototypes, and fast feedback that generate applicable knowledge. |
| Data governance / reliability | Critical data corrected or standardized before the "complete data lake." |
| Compliance / regulatory | Punctual adjustments or validated processes that reduce risk of fines and non-compliance. |
| Reputation / trust | Small improvements that increase customer or market perception. |
| Performance and scalability | Punctual optimizations that eliminate bottlenecks without rewriting the system. |
| Security | Incremental fixes and hardening that reduce attack surface. |
The distinction between outcome and output, popularized by Josh Seiden and Jeff Gothelf in Outcomes Over Outputs, cuts to the same nerve: output is what is delivered (features, modules, systems); outcome is the change in behavior or condition in the user, business, or market. Value, in a strong sense, lies in the outcome. A delivery "complete" in output terms can generate zero outcome if no one changes behavior or if the success metric is just "we delivered the module." Prioritization frameworks like RICE (Reach, Impact, Confidence, Effort) or ICE (Impact, Confidence, Ease) try to capture multiple dimensions of value; the risk is reducing everything to a number and losing the nuance that impact on satisfaction, learning, or compliance doesn't compare directly with revenue impact without explicit trade-off criteria.
The Kano model (Noriaki Kano), from quality and product, classifies attributes as basic, performance, and delight. Basic attributes don't generate satisfaction when present but generate dissatisfaction when absent; delight attributes can generate disproportionate value with small investment. The implication for incremental value: a minimal improvement in a delight attribute or in a performance bottleneck can deliver more perceived value than a "complete" module in a basic attribute. Those who prioritize only by "completing scope" ignore this asymmetry.
OKRs (Objectives and Key Results) force the definition of measurable results linked to strategic objectives. The danger lies in confusing key results with deliveries: "launch system X" is output; "reduce average ticket resolution time by 40%" is outcome. When the organization treats value as multifaceted, key results can mix financial, experiential, operational, and learning results, each with its time scale and measurement method. The agile principle below reinforces that the frequency and time scale of delivery matter as much as the content:
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." — Principles behind the Agile Manifesto (2001)
Preference for the shorter timescale implies decomposing value into partial deliveries that can be put into use and evaluated frequently, rather than accumulating work until a distant "complete." Each type of value in the table above can be sliced into increments that generate observable outcome, not just accumulated output.
3. Quantitative vs qualitative value
Revenue, cost, ROI, and cycle time appear in the P&L (profit and loss statement) and dashboards; experiential value, flow efficiency, or frustration reduction rarely enter the spreadsheet in the same quarter. Still, these factors affect retention, productivity, and innovation capacity. An example helps fix the idea: a team reduces the time of an operational task from ten to two minutes, maintaining the same functionality. The gain is both qualitative (less friction, fewer human errors) and quantitative (fewer hours paid per task). Organizations that only look at "new revenue" or "new feature launched" may leave this type of gain out of the prioritization conversation, even though it's real value.
The Balanced Scorecard (Kaplan and Norton) was created precisely to balance views: financial, customer, internal processes, and learning and growth. The thesis is that purely financial indicators are lagging (delayed): they reflect what already happened. Process, experience, and capability indicators are leading (early): they anticipate financial results. In software development, deployment speed, cycle time, failure rate, and team satisfaction are leading; revenue and cost per feature are lagging. Those who prioritize only by lagging metrics tend to make decisions when the damage or opportunity has already materialized. Qualitative value (smoother flow, less rework, better climate) often manifests first in leading indicators; ignoring them impoverishes the notion of value.
Goodhart's Law ("When a measure becomes a target, it ceases to be a good measure") warns of the perverse effect of reducing value to a single number. If "value" becomes synonymous with "quarterly revenue" or "number of features launched," agents optimize for the number, not for the phenomenon the number was meant to represent. Qualitative value (customer trust, innovation capacity, operational resilience) resists reduction to a single KPI; it requires dashboards with multiple dimensions and acceptance that part of what matters is narrative, qualitative evidence, and tacit learning.
In product and UX, metrics like NPS (Net Promoter Score) or CSAT (Customer Satisfaction) capture only a slice of experience; Jobs-to-be-Done (JTBD) and qualitative research reveal why people use the product and where frustration or delight appear. An improvement that eliminates a critical pain point may not move NPS in the short term and still increase retention and LTV (lifetime value). Experiential value, therefore, doesn't always convert immediately into a number on the dashboard; those who demand that "everything be measurable in dollars this quarter" tend to underinvest in improvements that pay off in the medium and long term.
The Agile Manifesto offers an objective criterion:
"Working software is the primary measure of progress." — Principles behind the Agile Manifesto (2001)
Progress, in this reading, lies in what is already in use and generating effect; completing the backlog scope may come later. "Working software" can be measured (deploy, usage, stability), but the value of that software can be quantitative (revenue, cost) or qualitative (learning, trust, future capability). Those who can distinguish and name both forms can prioritize deliveries that generate impact even when traditional metrics don't yet reflect it.
4. Internal vs external value
The end customer consumes value when using the product; within the company, other actors also consume value: teams that depend on APIs, operations that benefit from automations, management that decides based on dashboards, and integrations that unify data. These deliveries impact business, experience, and strategy indirectly but measurably. A stable and documented API for the partners team can unlock integrations that generate revenue, sometimes with more effect than a new screen in the product. A CI/CD pipeline that reduces deployment time from hours to minutes delivers operational and speed value (lower lead time, faster feedback), even if the end user never sees the word "deploy."
The notion of internal developer platform (IDP) or platform engineering positions the internal developer as a value consumer. The platform team delivers APIs, tools, environments, and patterns that reduce the time and cognitive cost for product teams to put software in production. The value generated is internal: less time wasted on repetitive tasks, fewer configuration errors, greater consistency. Metrics like average time to first deploy, environment provisioning time, or adoption of observability patterns are proxies for internal value. When the organization treats "value" only as what the end customer sees, platform investment becomes "cost" and tends to be cut in times of pressure, with delayed effect: future delivery capacity drops.
Conway's Law (system architecture tends to mirror the organization's communication structure) has a useful reverse: if internal teams consume value via well-defined APIs and contracts, the organization tends to produce more modular and interoperable systems. Internal value, in this sense, is not "secondary"; it's a condition for external value to scale. A company that delivers many features to the end customer but maintains chaotic dependencies between teams and fragile internal systems is accumulating risk; short-term external value can mask the fragility of internal value.
Frameworks like Team Topologies (Skelton and Pais) distinguish team types by who consumes their work: stream-aligned teams deliver value directly to the user; platform teams deliver value to other teams; enabling teams help other teams evolve capability. The platform's "customer" is internal; the value it generates propagates indirectly to the end user via greater speed and quality of stream team deliveries. Treating internal value as secondary breaks this logic and leads to prioritizing only what's visible in the interface, underinvesting in foundations that multiply future delivery capacity.
5. The impact of scope on value perception
The larger the work batch before delivery, the more impact is delayed: everything remains "in development" until go-live, and value and risk concentrate at a single moment. Smaller batches (reduced batch size) allow harvesting real value earlier, adjusting course based on usage and feedback, and reducing the risk of building something no one uses. Instead of "delivering the order system" as a single block, it can be decomposed into steps: manual order creation, then inventory integration, then notifications, then reports. Each step can generate value in a segment of the journey (operational, strategic, compliance) without depending on the complete system.
Reinertsen dedicates much of The Principles of Product Development Flow to batch size. In product development, large batch size increases lead time, delays feedback, concentrates risk, and makes dynamic prioritization difficult. Reducing the batch (delivering in smaller and more frequent slices) reduces time to first value, exposes flow problems earlier, and allows the organization to "bet" on multiple increments instead of a single large delivery. Real options theory, applied to product and project, reinforces: keeping options open has value; committing early to a large scope closes options and increases the cost of changing course. Small deliveries maintain the option to pivot or stop investing in a line that hasn't proven valuable.
The concept of minimum viable product (MVP) and its variants (minimum viable increment, minimum viable feature) operationalizes the idea of minimum scope that still generates value or learning. The debate about "viable" is precisely about what counts as value: it's not "minimum complete product," but rather the smallest set of deliveries that allows testing a hypothesis, enabling a flow, or generating an observable outcome. In Inspired, Marty Cagan talks about slice the cake: instead of delivering horizontal layers (all UI, then all logic, then all integration), deliver vertical slices that cross the stack and bring a usable end-to-end flow. Each slice can be smaller in scope and greater in perceived value because someone already uses it completely, even if limited.
The agile principle below dialogues directly with this idea:
"Simplicity (the art of maximizing the amount of work not done) is essential." — Principles behind the Agile Manifesto (2001)
Maximizing work not done implies doing only what's necessary for the next usable increment; large scope tends to create the illusion that "it only counts when finished," while smaller scope makes explicit that value is incremental and contextual. Set-based design (development that maintains multiple alternatives in parallel until evidence allows discarding) and the lean principle of decide as late as possible (defer commitment) reinforce: fixed and large scope, defined early, tends to waste effort on things that could have been discarded or simplified with more information.
6. When the model is already committed: multi-year scope and the illusion of agility
A project contract with fixed scope for three years, funding tied to delivery milestones defined at the start, and governance that demands plan conformance leaves little room to pivot, reduce batch, or prioritize by value discovered along the way. In this scenario, "adopting agile" usually means putting ceremonies (daily, retrospective, planning) on top of a model that has already eliminated the premises on which agility is sustained: continuous value delivery, adaptation to change, working software as the measure of progress. The team does sprints, but the steering committee demands that the three-year roadmap be fulfilled; the retrospective suggests abandoning an epic that hasn't proven valuable, and the contract or business case doesn't allow it. The blame falls on agile ("agile didn't work here"), when what failed was trying agile values within an arrangement that had already committed, from the start, to the opposite.
In The Principles of Product Development Flow, Reinertsen discusses the cost of early commitment: when scope, deadline, and cost are fixed early, the organization loses the option to redirect investment based on learning. Fixed scope / fixed price contracts are common in bids and projects with external funding; the problem isn't the contract itself, but the expectation that "agile" will operate within it as if there were freedom to change course. The Agile Manifesto places "Responding to change" above "Following a plan"; a model that requires following a three-year plan renders this preference inoperative. It's not about saying that every long project is wrong, but about recognizing that, in these contexts, what can be done is mitigate damage (partial deliveries within contracted scope, internal feedback, technical quality), not fulfill the complete promise of agility.
Typical cases: system integration projects where scope was defined in the proposal phase and any deviation requires a change request; digital transformation initiatives where the board approved a three-year business case and any pivot is seen as planning failure; outsourcing contracts where the vendor is paid by milestone and the milestone is "complete module," not "value in use." In all of them, the tension is the same: agile values presuppose that what matters can be discovered and reprioritized over time; the early commitment model presupposes that what matters is already defined. When both coexist without the organization naming the contradiction, agile becomes the scapegoat. The lesson isn't "agile only works in startups," but "agility requires a commitment and governance model that allows changing course; where this model doesn't exist, saying you're doing agile hides an incompatibility that needs to be addressed with clarity."
7. Mapping value: from perception to flow
Defining value allows designing flows and journeys, locating bottlenecks, excesses, and waste. In lean literature, value stream mapping works with two drawings: the current state, which shows how work flows today, where there are queues, rework, and dependencies, and where value for the customer or business is actually generated; and the future state, which projects the flow after incremental changes, with fewer steps, less WIP (work in progress), and smaller and more frequent deliveries. The Lean Enterprise Institute defines the object of this mapping thus:
"All the actions, both value-creating and non-value-creating, required to bring a product from concept to launch." — Lean Enterprise Institute, Lexicon
There are two families of value stream in the lean tradition: the development value stream (from conception to product or capability launch) and the operational value stream (from order or trigger to delivery to customer). In software engineering, the development value stream includes ideation, refinement, development, testing, deploy, and release; each step can be measured in processing time (touch time) and wait time. The ratio between value-added time and total lead time is usually tiny: most of the time is waiting, queueing, rework. Mapping makes visible where value is being created and where it's being consumed by activities that don't transform the product or information usefully for the next step.
The seven wastes of lean (transportation, inventory, motion, waiting, over-processing, defects, underutilization of people) have correspondence in software: excessive handoffs between teams, high WIP, rework from ambiguous requirements or late changes, waiting for environments or approvals, features no one uses, bugs and rework, talent stuck in tasks that don't leverage capability. The value stream map helps locate these wastes in the flow and design a future state where value deliveries happen at intermediate points, not just at the end. Metrics like process cycle efficiency (PCE), value-added time divided by total lead time, quantify how much of the flow is actually value creation; in many development flows, PCE is single-digit percentage, which reinforces that concentrating "value" at the "complete system" milestone hides most of the time spent on non-value.
In frameworks like SAFe, the value stream is an explicit entity: a sequence of steps that transforms a trigger (order, idea, event) into a result for the customer or business. Mapping allows identifying where there's excess capacity, where there's bottleneck, and where partial deliveries could already generate value. By making explicit the actions that create and don't create value, mapping shows that value can be distributed along the flow, instead of concentrated on go-live day. Deliveries that eliminate a bottleneck or allow early validation already count as value deliveries; mapping helps prioritize what generates real impact instead of what merely completes a scope defined on paper.
8. Technical value as strategic value
Quality, maintainability, performance, security, and automation accelerate future deliveries, reduce incident risk, allow scaling without collapse, and protect reputation and operations. The Agile Manifesto already treated this as part of agility:
"Continuous attention to technical excellence and good design enhances agility." — Principles behind the Agile Manifesto (2001)
When technical investment is treated as "not value" or "second-class value," the result is usually growing technical debt, fragile systems, and, in the medium term, loss of capacity to respond to the market. A refactoring that allows launching new features in half the time generates value; a set of automated tests that prevents regressions in production does too; a security adjustment that closes a critical vulnerability likewise.
DORA metrics (Deployment Frequency, Lead Time for Changes, Time to Restore Service, Change Failure Rate), the result of years of research by Google Cloud and DevOps Research and Assessment, correlate technical capability with business results: teams with good DORA performance tend to have better organizational performance. The SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency), by Forsgren and collaborators, broadens the view to well-being, productivity, and collaboration, reminding that "technical value" includes the sustainability of the team and flow, not just code health. In Building Evolutionary Architectures, Rebecca Parsons and collaborators introduce fitness functions: automated tests that verify whether the architecture remains within acceptable limits of modularity, latency, or coupling. The value delivered is the preservation of the ability to evolve without collapse; it's strategic value that doesn't appear in any feature launched in the quarter.
Technical debt, when well named and prioritized, can be treated as an option: pay interest (difficult maintenance, bugs) until deciding to "pay off" (refactor) at the moment when the cost of paying off is less than the cost of continuing to pay. Wardley Mapping and component evolution strategy (commodity vs product vs custom) help decide where to invest in technical excellence: in parts of the system that are competitive differentiators, technical investment tends to have direct return in business value; in commodity parts, "good enough" may be rational. The central point remains: technical value supports business value. Without continuous attention to technical excellence, the capacity to deliver functional value in the future degrades, and the organization comes to depend on heroism and rework to maintain the illusion of progress.
9. Learning and innovation as value delivery
Experimentation, prototyping, and fast feedback generate value even when there's no final product in production yet. Eric Ries, in The Lean Startup, distinguishes what counts as progress in manufacturing and in uncertainty contexts:
"Progress in manufacturing is measured by the production of high-quality physical goods. Progress in startups is measured by validated learning." — Eric Ries, The Lean Startup (2011)
Validated learning is empirical evidence that the team discovered something useful about the business or product. An experiment that invalidates an expensive hypothesis before building the complete system avoids waste; a prototype that reveals that the user doesn't understand the flow redirects the solution design.
The Build-Measure-Learn cycle of Lean Startup makes explicit that "Learn" is value output: what is learned informs the next iteration and reduces uncertainty. In The Startup Way, Ries extends the logic to large companies: innovation units can have validated learning as their main "delivery," not the launched product. In Continuous Discovery Habits, Teresa Torres proposes that discovery (opportunity discovery and user validation) be continuous and parallel to delivery; the value of a discovery cycle is the learning that changes what will be built or discarded. Design thinking, double-diamond, and discovery approaches emphasize the exploration phase as a generator of informational value that avoids building the wrong thing.
Chris Argyris distinguishes single-loop learning (adjusting actions within the same frame of reference) from double-loop learning (questioning the frame itself). In product and engineering, deliveries that only "complete scope" tend to reinforce single-loop: the question is "did we deliver what was asked?" Double-loop asks: "does what we asked still make sense? What did we learn that should change the request?" Value as learning requires willingness for the second loop: evidence that invalidates a hypothesis or reprioritizes a roadmap is value, even if it hasn't generated a line of code in production. The OODA cycle (Observe, Orient, Decide, Act), by John Boyd, used in strategy and agility, positions the speed of learning and reorientation as competitive advantage; teams that learn fast and correct course tend to deliver more aggregate value than teams that accumulate work for months and only validate at "complete delivery."
In uncertainty environments, value lies both in what is put into production and in what is learned along the way and used to make better decisions. Treating "value" only as delivered output underestimates the role of learning as an asset that reduces risk and increases the probability that next deliveries will hit the target.
10. Why "agile is dead" (and why the problem isn't agile)
Dave Thomas, one of the Agile Manifesto signatories, published in 2014 the text "Agile Is Dead (Long Live Agility)." The central thesis is that the word "agile" has been emptied: it became a brand, became a noun ("doing agile"), became an offering from consultants and vendors. He writes:
"The word 'agile' has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products." — Dave Thomas, "Agile Is Dead (Long Live Agility)", 2014
And further:
"Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words like eco and natural are. And a word that is abused in this way becomes useless: it stops having meaning as it transitions into a brand." — Dave Thomas, "Agile Is Dead (Long Live Agility)", 2014
Thomas doesn't reject the Manifesto values; he rejects what was done with the label. He proposes abandoning "agile" as a noun and recovering "agility" as a way of working: "You aren't an agile programmer: you are a programmer who programs with agility." The closing of the text is explicit:
"We've lost the word agile. Let's try to hold onto agility. Let's keep it meaningful, and protect it from those who would take the soul of our ideas in order to sell it back to us." — Dave Thomas, "Agile Is Dead (Long Live Agility)", 2014
The "agile is dead" discourse makes sense when what died is framework agile: Scrum, SAFe, or any method applied as a checklist, with velocity and Story Points as ends, without explicit connection to value, outcome, or learning. What Thomas advocates is that agility (continuous delivery, response to change, working software as measure of progress) remains valid; what's not valid is confusing this agility with buying a process. This article doesn't advocate "more agile" in the sense of more ceremonies or more certifications; it advocates more clarity about value: naming types of value, measuring flow, designing deliveries that materialize value before the "complete system." This clarity is compatible with the Manifesto values and with what Thomas calls developing with agility; it's incompatible with using "agile" as a noun that you buy or implement without changing the commitment model and the question "what generates value in this delivery?"
11. Conclusion
The thread of this article is one: value in agility is not to be confused with complete delivery of system or functionality. Value appears in types (financial, strategic, experiential, operational, technical, learning, reputational, compliance), in dimensions (quantitative and qualitative, internal and external), and in dynamics (flow, batch size, cost of delay, validated learning). Those who name these forms and ask "what generates value in this delivery?" tend to prioritize usable deliveries before the "all done" milestone and measure results by impact, not by scope closed on paper.
Two risks were treated explicitly. The first: committing early to multi-year scope and governance that demands plan conformance, and on top of that "adopting agile." The model has already eliminated the possibility of pivoting and prioritizing by value discovered along the way; the frustration that follows is usually attributed to agile, when the incompatibility lies in the commitment arrangement. The second: reducing agility to framework, ceremonies, and output metrics (velocity, points), until the word "agile" loses meaning and someone declares that "agile is dead." What died was the label used as a brand; what remains is the need to deliver value continuously, respond to change, and use working software as the measure of progress.
Deep thinking about value in agility involves operational questions: what to build next, for whom, with what "done" criteria, and when to stop to measure what matters. The complete system may be an eventual result; the question about value should be constant.
Bibliography
ARGYRIS, Chris. Knowledge for Action: A Guide to Overcoming Barriers to Organizational Change. San Francisco: Jossey-Bass, 1993.
BOYD, John. "The OODA Loop". In: The Essence of Winning and Losing. 1995. Available at: https://www.danford.net/boyd/essence.htm.
BECK, Kent et al. Manifesto for Agile Software Development. 2001. Available at: https://agilemanifesto.org/. Principles: https://agilemanifesto.org/principles.html.
CAGAN, Marty. Inspired: How to Create Tech Products Customers Love. 2nd ed. Hoboken: Wiley, 2017.
FORSGREN, Nicole et al. Accelerate: The Science of Lean Software and DevOps. Portland: IT Revolution Press, 2018.
FORSGREN, Nicole et al. "The SPACE of Developer Productivity". ACM Queue, 2021. Available at: https://queue.acm.org/detail.cfm?id=3454124.
GOODHART, Charles. "Problems of Monetary Management: The UK Experience". In: Monetary Theory and Practice. London: Macmillan, 1984.
GOTHELF, Jeff; SEIDEN, Josh. Outcomes Over Outputs: Why Customer Behavior Is the Key Metric for Business Success. Burlingame: Sense & Respond Press, 2019.
KANO, Noriaki. "Attractive Quality and Must-be Quality". The Journal of the Japanese Society for Quality Control, v. 14, n. 2, p. 39-48, 1984.
KAPLAN, Robert S.; NORTON, David P. The Balanced Scorecard: Translating Strategy into Action. Boston: Harvard Business School Press, 1996.
Lean Enterprise Institute. Value Stream. Lexicon. Available at: https://www.lean.org/lexicon-terms/value-stream/.
PARSONS, Rebecca et al. Building Evolutionary Architectures: Support Constant Change. 2nd ed. Sebastopol: O'Reilly, 2017.
REINERTSEN, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach: Celeritas Publishing, 2009.
RIES, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Business, 2011.
RIES, Eric. The Startup Way: How Modern Companies Use Entrepreneurial Management to Transform Culture and Drive Long-Term Growth. New York: Currency, 2017.
SKELTON, Matthew; PAIS, Manuel. Team Topologies: Organizing Business and Technology Teams for Fast Flow. Portland: IT Revolution Press, 2019.
THOMAS, Dave. "Agile Is Dead (Long Live Agility)". PragDave, Mar 4, 2014. Available at: https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html.
TORRES, Teresa. Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value. Richmond: Product Talk LLC, 2021.
WARDLEY, Simon. Wardley Mapping. Available at: https://wardley-maps.com/.
