Archive

Requirements

Ready – Book Review

August 13, 2025
Article, Book Review, Needs, Requirements
Leave a comment

Ready – Book Review

Ready: Why Most Software Projects Fail and How to Fix It by Luniel de Beer and Max Guernsey, III

A Tale of Two Ambitions

‘Ready’ presents itself as a solution to software project delivery struggles, and it delivers precisely that—masterful process engineering that may however be optimising the wrong thing.

The authors’ central thesis—that premature implementation causes most software development waste—leads to Requirements Maturation Flow (RMF), a three-part framework creating explicit gates around implementation readiness. Think Design by Contract for work items rather than code methods: preconditions (Definition of Ready), postconditions (Definition of Done), and invariants (responsibility rules).

What RMF Actually Delivers

The book’s opening case study at ‘The Bank’ is compelling: teams transforming from delivering nothing to shipping working software after adopting systematic readiness practices. The detailed progression from chaos to flow is vividly illustrated with workflow diagrams and specific examples.

RMF creates mechanisms for:

  • Explicit collaboration before implementation starts
  • Documented shared understanding via bespoke Definitions of Done and Ready
  • Workflow gates that prevent premature starts and closures
  • Visible tracking of readiness work
  • Contract-like responsibility transfers between Product and Engineering

The practical guidance is outstanding—detailed templates, adoption strategies, common objections with responses, and integration patterns for Scrum/Kanban make implementation genuinely feasible.

The ‘Software Last’ Context

When viewed through Seddon’s ‘Software Last’ principle—understand the work first, then design solutions to support that work—RMF operates at a specific layer of the problem stack.

RMF doesn’t address whether teams should build what they’re asked to build—it focuses entirely on the handoff: ‘Given that we’ve decided to build X, let’s make sure we build X correctly.’ Questions about whether X is the right solution are explicitly outside the book’s scope.

The authors acknowledge this limitation directly: ‘The techniques in this book don’t tell you what to build, why to build it, or how to find out whether it’s the right thing to build.’ This honest scope disclaimer might help reduce false expectations.

The Bank example illustrates this perfectly. After RMF, they successfully built a loan repayment portal that satisfied all stakeholders. But the book never asks: Did customers actually need a portal? What work were customers trying to accomplish, and what prevented them from doing it well? RMF enhances confidence in execution without addressing purpose.

The Gall Warning: When Solutions Become Systems

Gall’s Systemantics provides a devastating critique of RMF’s approach. His principles predict exactly how this kind of designed system will behave in practice.

‘A Complex System Designed from Scratch Never Works’: RMF is precisely what Gall warned against—an elaborate, architected solution with three interconnected habits, multiple behaviours, templates, gates, and responsibility transfers. The book presents this as a complete framework without showing how simpler practices might work first.

‘Systems Tend to Oppose Their Own Proper Function’: RMF aims to help teams build the right things correctly, but Gall would predict it will oppose itself. Teams may become obsessed with satisfying DoD/DoR criteria rather than delivering value. Readiness work becomes an end in itself. Process compliance replaces judgement—’The DoR is satisfied, so we must start’ even when common sense says wait.

‘The System Always Kicks Back’: Gall would predict RMF creates new problems it wasn’t designed to solve. Teams learn to game DoDs that are easy to satisfy rather than meaningful. Collaboration meetings consume increasing time. Elaborate DoRs give an illusion of control whilst missing real sources of uncertainty.

‘Systems Serve Themselves’: Most damning—who benefits most from RMF? Process consultants, teams that prefer meetings to building, and managers who want visible ‘readiness progress.’ Meanwhile, customers waiting for working software see longer delays as teams perfect their readiness processes.

The Upstream Questions (Deliberately Out of Scope)

RMF creates elaborate processes to ensure teams build exactly what Product Management requests. The framework’s collaboration meetings are structured around ‘How do we build X correctly?’ rather than ‘Should we build X at all?’

This is by design—the authors explicitly position RMF as addressing execution mechanics, not strategic direction or stakeholder identification. Questions about whether Product Management is listening to the right people or solving the right problems are upstream challenges that RMF doesn’t claim to adress or solve.

The Ethical Question (Also Out of Scope)

This raises an interesting question: Do development teams have a professional responsibility to question whether they’re building the right things for the right reasons? RMF’s focus on execution efficacy doesn’t address this question—and the authors don’t claim it should.

However, it’s worth noting that teams focused intensely on execution mechanics without corresponding frameworks for questioning purpose might inadvertently become more efficient at building things nobody needs. This isn’t a flaw in RMF per se, but rather a reminder that execution excellence requires complementary disciplines around strategy and purpose.

What Works Within Its Scope

Despite these caveats, RMF offers genuine value for teams suffering from implementation chaos:

  • Framework agnostic: Enhances existing methodologies rather than replacing them
  • Incremental adoption: Start with RMF 1, see benefits, then expand
  • Practical mechanics: Detailed templates and guidance make implementation feasible
  • Process discipline: Contract-like nature of DoD/DoR creates healthy constraints
  • Collaboration structure: Systematic approach to shared understanding addresses real coordination problems
  • Honest positioning: The authors clearly state what the book doesn’t solve

The Real Innovation

RMF’s core insight is bringing the rigour of Design by Contract to human collaboration and work handoffs. Instead of code method contracts, teams get collaboratively negotiated work item contracts with clear preconditions, postconditions, and responsibility transfers.

This is genuinely sophisticated process engineering. The problem is the assumption that better process engineering addresses root causes of software project struggles—though the authors are now explicit that this isn’t their claim.

Who Should Read This

Definitely read if:

  • Your teams struggle with constant rework and implementation chaos
  • Requirements frequently change mid-implementation
  • ‘Almost done’ work items plague your sprints
  • You want systematic approaches to collaboration and handoffs

Read with caution if:

  • Your organisation tends toward process bureaucracy
  • You suspect you’re building wrong things (regardless of execution quality)

Don’t read if:

  • You need help identifying what to build or for whom
  • Your problems are primarily market timing, funding, or strategic direction

Verdict

‘Ready’ succeeds brilliantly at what it explicitly attempts—providing systematic relief for teams drowning in implementation chaos. The framework offers concrete mechanisms where many teams have only informal practices. The authors’ honest acknowledgement of scope limitations prevents false expectations about strategic guidance.

However, readers should watch for Gall’s predicted pathologies: RMF serving itself rather than its purpose, readiness work expanding beyond necessity, and process compliance replacing judgement about value creation.

The book positions RMF appropriately within the larger Synapse Framework, acknowledging it doesn’t replace product strategy or vision work. This contextual honesty significantly strengthens the overall package.

Bottom line: If your problem is delivery mechanics, this will likely help—and the authors are clear about what problems it doesn’t solve. The combination of sophisticated process engineering and honest scope positioning makes this a valuable resource for teams struggling with implementation chaos.

Teams struggling with implementation chaos will find systematic, practical relief. The book is explicit about not solving upstream strategy or vision problems—which makes it trustworthy rather than overselling its scope.

‘Ready: Why Most Software Projects Fail and How to Fix It’ is available at https://leanpub.com/ready

Further Reading

De Beer, L., & Guernsey, M., III. (2025). Ready: Why most software projects fail and how to fix it. Leanpub.

Gall, J. (2003). The systems bible: The beginner’s guide to systems large and small (3rd ed.). General Systemantics Press.

Jones, C. (1994). Assessment and control of software risks. Prentice Hall.

Meyer, B. (1997). Object-oriented software construction (2nd ed.). Prentice Hall.

Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK guide) (7th ed.). Project Management Institute.

Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.

Seddon, J. (2003). Freedom from command and control: A better way to make the work work. Vanguard Press.

Sutherland, J., & Schwaber, K. (2020). The Scrum guide: The definitive guide to Scrum (2020 ed.). Scrum.org.

What Makes a Great User Story?

May 16, 2025
Antimatter principle, Article, Attendants, Feedback, Learning, Needs, Organisational effectiveness, Paradigm shifts, Prod•gnosis, Product development, Quantification, Quintessence, Requirements, Story
Leave a comment

What Makes a Great User Story?

A great user story accurately pinpoints what people truly need from your product and translates those needs into guidance that development teams can easily understand and act upon. It’s worth noting that “user story” is actually a misnomer – these might better be called “Folks That Matter™ stories” since they centre on real people with real needs, not just abstract “users” of a system.

Core Components

While there are many formats for writing these stories, the essential components remain consistent: identifying the Folks That Matter™, their needs, and the benefits they’ll receive. The story should clearly communicate who needs the feature, what they need, and most importantly, why they need it.

The Living Nature of Stories

Folks That Matter™ stories aren’t static artefacts – they evolve, morph, and grow across numerous iterations. Like elements in a Needsscape (the visualisation of all the folks that matter and their changing needs), stories adapt as we gain deeper understanding of people’s requirements. What begins as a simple narrative might develop into a complex web of interconnected needs as teams learn more through development cycles, feedback loops and product deployments.

Essential Qualities

Great Folks That Matter™ stories share several important characteristics:

  • They can be developed independently from other stories
  • Their details remain open to discussion and refinement
  • They deliver clear value to the folks that matter™
  • Teams can reasonably estimate the effort required
  • They’re focused enough to complete in a single iteration
  • They include clear criteria for testing and validation

Focus on Needs

The most effective Folks That Matter™ stories focus on identifying and attending to needs rather than implementing specific solutions. They describe outcomes and the results foilks gain, not the technical implementation. This gives development teams space to find the best technical approaches.

Clear Acceptance Criteria

Each Folks That Matter™ story includes explicit acceptance criteria that define when the story is complete and needs have been met. Such criteria will be testable, quantified (Cf. Gilb), and agreed upon by all the Folks That Matter™.

Summary

Effective Folks That Matter™ stories serve as bridges between human needs and technical solutions. They identify the Folks That Matter™, articulate their genuine needs, and provide development teams with clear guidance – while leaving room for creativity in implementation. Rather than static requirements documents, they function as living artefacts that evolve through conversation and iteration and feedback. By focusing on outcomes rather than specifications, and by including clear, quantified acceptance criteria, these stories help teams build products that truly meet people’s needs—the essence of successful product development and the cornerstone of navigating the broader Needsscape of any organisation.

The Budget-First Revolution: What Most Product Development Teams Don’t Know

February 12, 2025
Article, Financial, Honesty, NoEstimates, Organisational effectiveness, Paradigm shifts, Product development, Requirements, Software Delivery
Leave a comment

The Budget-First Revolution: What Most Product Development Teams Don’t Know

In the world of product development, there are two fundamental approaches to budgeting: the cost-first approach (“How much will it cost?”) and the budget-first approach (“What can we get for our notional budget limit?”). Despite these being equally valid options, most organisations default to cost-first estimation simply because they’re unaware that budget-first is a legitimate alternative. This unconscious limitation of choice often leads teams down a path of unnecessary estimation complexity when a simpler approach might better serve their needs.

The Cost-First Approach: The Traditional Path and Its Pitfalls

The cost-first approach begins with a vision of what needs to be built and works backwards to determine the necessary budget. Whilst familiar to many organisations, this traditional estimation-based method comes with significant challenges and drawbacks:

The Estimation Fallacy

Studies consistently show that development estimates are notoriously inaccurate. The Cone of Uncertainty suggests that initial estimates can be off by a factor of 4x – or more – in either direction. Even with experienced teams, complex projects routinely exceed their estimated budgets by 50% or more.

Hidden Costs of Estimation

The process of creating detailed estimates consumes significant time and resources. Teams often spend weeks in estimation meetings, agreeing requirements, preparing documentation, and defending their numbers – time that could be spent actually building and delivering value.

The Planning Fallacy

Humans consistently display optimism bias in planning, underestimating the time and effort required for complex tasks. This psychological tendency, combined with pressure to provide “acceptable” estimates, leads to systematic underestimation.

Requirements Instability

The cost-first approach assumes requirements can be accurately defined upfront. In reality, requirements often change significantly during development as understanding evolves and market conditions shift. This makes initial estimates increasingly irrelevant as the project progresses.

Perverse Incentives

When estimates become commitments, teams face pressure to cut corners to meet arbitrary deadlines. This can lead to technical debt, reduced quality, and increased long-term costs. Additionally, teams may pad estimates defensively, reducing trust and transparency.

The #NoEstimates Movement

In response to these challenges, the #NoEstimates movement has emerged as a critique of traditional estimation practices. Pioneered by practitioners like Woody Zuill and Neil Killick, the movement questions the value of detailed upfront estimation in product development.

Core Principles of #NoEstimates:

  • Focus on delivering small, valuable increments rather than predicting future costs
  • Use historical data and throughput metrics instead of speculative estimates
  • Make decisions based on value and capacity rather than detailed predictions
  • Embrace uncertainty and adaptation rather than trying to eliminate them through planning

Alternative Metrics

Instead of detailed estimates, #NoEstimates advocates suggest focusing on:

  • Cycle time: How long it takes to complete work items
  • Throughput: How many items are completed per time period
  • Value metrics: Direct measures of business impact
  • Running tested features: Working software in production

The Budget-First Approach: Starting with Notional Limits

The budget-first approach flips the traditional model by starting with a notional budget limit and determining what can be delivered within those constraints. Whilst this approach has gained popularity with the rise of agile development and lean startup principles, it remains surprisingly underutilised. Many teams continue with tortuous estimation processes simply because they don’t realise they have a choice.

Understanding Notional Budget Limits

The term “notional budget limit” is crucial here – it represents the realistic financial boundaries within which the team must operate. This isn’t about arbitrary restrictions, but rather about acknowledging the actual financial constraints that exist in most organisations. These limits might come from:

  • Annual departmental budgets
  • Quarterly funding allocations
  • Project portfolio constraints
  • Market-driven price points for the final product

Working Within Known Constraints

Rather than spending time estimating costs that may or may not fit within available budgets, teams start with the known financial constraints and work backwards. This creates a more focused conversation about:

  • What features provide the most value within the budget limit
  • How to phase delivery to match funding cycles
  • Where to make strategic trade-offs
  • How to maximise return on the available investment

Prioritisation is Key

Rather than exhaustively documenting all possible features, teams focus on identifying and prioritising the most crucial functionality. This often leads to better-focused products that deliver core value more efficiently.

MVP Definition

Teams work backwards from the notional budget limit to define a Minimum Viable Product (MVP) that fits within financial constraints whilst delivering essential functionality. This forces tough but valuable conversations about what features are truly necessary versus nice-to-have.

Innovation Through Clear Constraints

Understanding the notional budget limit upfront often drives more creative solutions. Teams focus their innovation efforts within known parameters rather than generating ideas that may prove financially unfeasible.

Why Teams Don’t Choose Budget-First

Understanding why budget-first remains underutilised can help organisations make more conscious choices about their approach:

Cultural Inertia

Many organisations have deeply ingrained practices around estimation and budgeting that are rarely questioned. The very idea that there might be an alternative to detailed estimation often comes as a surprise.

Misunderstanding of Control

There’s a common misconception that detailed estimates provide more control over development outcomes. In reality, budget-first approaches often provide better control by forcing early decisions about priorities and trade-offs.

Fear of Commitment (Lack of Trust)

Some organisations avoid stating budgets upfront, believing it will lead to teams consuming the entire budget regardless of need. This fear often leads to the more wasteful practice of extensive estimation exercises.

Procurement and Governance Requirements

Many organisations believe their governance processes require detailed estimates. In reality, most governance requirements can be satisfied through budget-first approaches with appropriate documentation of assumptions and priorities.

Choosing the Right Approach

The choice between cost-first and budget-first approaches often depends on several factors:

When to Use Cost-First

  • Regulatory compliance projects with non-negotiable requirements
  • Mission-critical systems where functionality cannot be compromised
  • Projects with well-understood requirements and clear technical paths
  • Organisations with flexible budgets and focus on comprehensive solutions

When to Use Budget-First

  • Startups and new product initiatives with limited funding
  • Innovation projects where learning and adaptation are crucial
  • Organisations with strict budget cycles or financial constraints
  • Projects where time-to-market is a primary concern

Making the Choice Conscious

To move towards more effective budgeting approaches, organisations might choose to:

Question Default Practices

Before automatically responding to the question “How much will it cost?”, teams might choose to explicitly consider whether a budget-first approach might be more appropriate.

Educate Stakeholders

Help decision-makers understand that budget-first is a valid and often more effective approach. This includes explaining how it can lead to better outcomes and more efficient use of resources (i.e. lower costs, quicker time to market).

Start Small

Consider piloting budget-first approaches on smaller projects where the stakes are lower and resistance to change may be less intense.

Success Factors for All Approaches

Regardless of the chosen methodology, certain factors are crucial for success:

Clear Communication

All approaches require transparent communication about constraints, whether they’re financial or functional. All stakeholders may choose to understand and agree to the chosen approach and its implications.

Realistic Expectations

Teams may choose to be honest about what can be achieved, whether working within a fixed budget or estimating costs. Over-optimism in either approach leads to disappointed stakeholders and stressed teams.

Regular Review and Adjustment

All approaches benefit from regular checkpoints to assess progress, adjust plans, and ensure alignment with business objectives Cf. Tom Gilb’s Mountain Goat principle). This includes being willing to make tough decisions about scope, quality, or additional funding when necessary.

Conclusion

Whilst the cost-first approach remains common in many organisations, this is often due to habit rather than conscious choice. The emergence of budget-first thinking, which starts with notional budget limits, reflects a broader shift toward more adaptive, value-focused approaches to development.

The key is not just to choose between approaches, but to make that choice consciously rather than defaulting to traditional estimation methods out of habit. By acknowledging that working within notional budget limits is a valid starting point, organisations can make better choices about how they approach budgeting and delivery.

Success in modern development invites questioning of traditional practices and being willing to adopt approaches that might initially feel uncomfortable. Whether through budget-first methods, #NoEstimates practices, or hybrid approaches, organisations have more options than they often realise for moving beyond the limitations of traditional cost-first estimation.

Needs, Wants and Human Flourishing

December 26, 2024
Antimatter principle, Article, Attendants, Business, Conflict, Culture change, Ethics, Lamentation, Needs, Nonviolent Communication, Paradigm shifts, Product development, Requirements
Leave a comment

Needs, Wants and Human Flourishing

Wants are innumerable, needs are numerable.

The Foundation: What Are Needs?

We often blur the lines between what we truly need and what we simply want. Yet, at its core, human needs remain remarkably constant and countable. These fundamental requirements for survival and basic well-being form a finite set of essentials that, when fulfilled, provide the foundation for human flourishing. This understanding was powerfully articulated by Abraham Maslow in his theory of human motivation, which demonstrated how basic needs must be satisfied before higher-level growth can occur. Marshall Rosenberg later expanded this understanding, emphasising that universal human needs—such as sustenance, safety, connection, understanding, and meaning—are shared across all cultures and form the basis for human connection and conflict resolution. His work showed how recognising and articulating these fundamental needs can transform interpersonal dynamics and societal structures.

The Finite Nature of Numerable Needs

Our basic needs constitute a clear, quantifiable list. Consider shelter—we require protection from the elements, but this needn’t manifest as a sprawling mansion. Similarly, whilst we need sustenance, this translates to a calculable number of calories and nutrients, not endless varieties of gourmet cuisine. Maslow’s hierarchy elegantly arranges these needs from physiological requirements through to safety, belonging, esteem, and self-actualisation.

The Infinite Realm of Innumerable Wants

Whilst our needs remain steadfast and countable, our wants represent an ever-expanding universe of desires. In the digital age, this phenomenon has accelerated dramatically. Yesterday’s cutting-edge mobile phone becomes today’s outdated technology, spawning fresh desires for the latest model. Fashion trends shift like desert sands, creating endless cycles of want and acquisition.

The Marketing Machine: Manufacturing Desires

Modern advertising has mastered the art of transforming simple wants into perceived needs. Through clever psychological manipulation, marketers convince us that the latest trainers or the newest gadgets aren’t merely desirable—they’re essential. This commercial alchemy turns mere wants into seemingly compelling needs.

Finding Balance in a Consumer Society

I invite you to consider how the key to navigating this landscape lies in understanding the crucial distinction between needs and wants. Whilst there’s nothing inherently wrong with pursuing wants—indeed, they can add colour and joy to life—we might choose to maintain perspective. By recognising that needs are finite whilst wants are infinite, we can make more conscious choices about resource allocation, both personally and societally.

The Commercial Dilemma: Profit versus Purpose

Perhaps the most challenging aspect of the needs-wants distinction lies in its commercial implications. Businesses face a stark reality: fulfilling basic needs often yields but modest profits, whilst catering to endless wants can generate substantial returns. Consider the pharmaceutical industry—developing essential medicines for widespread diseases in developing nations typically offers lower profit margins than creating lifestyle drugs for affluent markets. Similarly, construction companies often find luxury developments more lucrative than affordable housing projects.

This creates a profound ethical tension with cascading consequences. Should businesses prioritise addressing fundamental needs, potentially at the cost of their own survival? The dilemma is particularly acute because an organisation that fails while pursuing a needs-based mission ultimately serves no one—those needs then go unmet, and often no other enterprise steps in to fill the void. Yet focusing primarily on profitable wants may ensure organisational survival and provide employment, but at the cost of diverting resources and talent away from addressing essential needs. This dilemma extends beyond individual companies to shape entire economies and societies, creating a troubling paradox where the very attempt to prioritise fundamental needs might lead to their continued neglect through business failure. Maybe business (capitalism) isn’t the answer to best addressing folks’ needs at all?

The Ethical Balance

The resolution perhaps lies not in choosing one path exclusively, but in finding innovative ways to address both. Some organisations have pioneered hybrid models—using profits from want-based products to subsidise need-based initiatives. Others have found ways to make serving basic needs commercially viable through technological innovation and scale. The European model places governments much more centrally in the role of attending to society’s needs. Yet the fundamental tension remains, challenging us to reconsider how we structure our economic systems and incentives.

The Environmental Imperative

In an era of climate crisis, distinguishing between needs and wants takes on new urgency. Our planet’s resources are finite, yet our wants seem to expand exponentially. Understanding this dichotomy becomes crucial for sustainable living and responsible consumption.

Practical Applications for Daily Life

The recognition that needs are numerable whilst wants are innumerable offers practical guidance for:

  • Budgeting and financial planning
  • Product development
  • Environmental decision-making
  • Mental well-being and contentment
  • Social policy and resource allocation

Looking Forward

As we face unprecedented global challenges, this fundamental distinction between needs and wants becomes increasingly relevant. By understanding and embracing this concept, we can work towards a more sustainable and equitable future, ensuring that everyone’s needs are met whilst managing our infinite wants more wisely.

Further Reading

For a deeper understanding of human flourishing, well-being, and the nature of human needs, consider:

Maslow, A. H. (1970). Motivation and personality (2nd ed.). Harper & Row.

Rosenberg, M. B. (2015). Nonviolent communication: A language of life (3rd ed.). PuddleDancer Press.

Seligman, M. E. P. (2011). Flourish: A new understanding of happiness and well-being – and how to achieve them. Nicholas Brealey Publishing.

These seminal works explore the complex interplay between basic human needs and the achievement of our full potential, offering valuable insights into the journey from mere survival to true flourishing.

The “Good Enough” Sweet Spot

April 30, 2024
Actionable Insights, Alien tech, Antimatter principle, Article, Business, Culture change, Engineering, Organisational effectiveness, Quantification, Quintessence, Requirements, Software development
Leave a comment

The “Good Enough” Sweet Spot

[Tl;Dr: “Good enough” means optimising for best meeting all the needs of the Folks That Matter™]

The Perils of Over-Engineering

In our quest for excellence, it’s tempting to over-engineer solutions, pouring needless resources into perfecting every tiny detail. However, this pursuit of flawlessness often comes at a steep price. Over-engineering can lead to diminishing returns, where the marginal benefits of additional effort become negligible. It can also result in unnecessary complexity, making systems harder to maintain and adapt.

The Pitfalls of Under-Engineering

On the flip side, under-engineering can be equally detrimental. Cutting corners or settling for subpar solutions may seem like a shortcut to efficiency, but it often leads to technical debt, compromised quality, and long-term sustainability issues. Under-engineered products or processes are more prone to failure, necessitating costly reworks or replacements down the line.

Striking the “Good Enough” Balance

Between these two extremes lies the “good enough” sweet spot – a delicate balance that maximises value while minimising waste. Embracing the “good enough” mindset means understanding when to invest resources and when to call it a day. It’s about recognising that perfection is an asymptote that can never be reached, and that diminishing returns inevitably set in.

The “Good Enough” Approach

Adopting a “good enough” approach involves setting realistic goals and prioritising the most critical aspects of a project or product. It means focusing on core functionality and user needs, rather than getting bogged down in superfluous features or tiny optimisations. By identifying the minimum viable product (MVP) and iterating from there, teams can meet folks’ needs faster and adapt more readily to changing requirements.

Quantifying the “Good Enough” Threshold

Of course, to deliver just what’s good enough, we have to know what’s good enough. Choosing to quantify the qualitative aspects of deliverables can help (Cf. Gilb).

Quantifying the Qualitative

Defining “good enough” can be challenging, especially when dealing with qualitative aspects such as user experience, design aesthetics, or customer satisfaction. However, by quantifying these qualitative elements, teams can establish more objective criteria and benchmarks for what constitutes “good enough.”

Leveraging Data and Metrics

One approach is to leverage data and metrics to measure and track qualitative aspects. For example, user testing and feedback can provide numerical scores for usability, intuitiveness, and overall satisfaction. Analytics data can reveal user behavior patterns, highlighting areas of friction or success. Even design aesthetics can be quantified through techniques like preference testing or eye-tracking studies. (See also: Gilb: Competitive Engineering).

Defining Acceptance Criteria

Another powerful tool is setting clear acceptance criteria upfront. By collaborating with stakeholders and subject matter experts, teams can define specific, measurable criteria that must be met for a deliverable to be considered “good enough.” These criteria can encompass functional requirements, performance benchmarks, accessibility standards, and qualitative thresholds based on user feedback or industry best practices.

Prioritising and Iterating

Once acceptance criteria are established, teams can prioritize the most critical aspects and focus their efforts on meeting those thresholds. By adopting an iterative approach, they can continuously refine and enhance the deliverables, incorporating feedback and adapting to evolving needs while maintaining a “good enough” baseline.

Embracing a Quantification-Driven Approach

Quantifying qualitative aspects requires a data-driven mindset within the organisation. Teams must be equipped with the tools, skills, and processes to collect, analyse, and act upon relevant data. Additionally, fostering a culture of continuous learning and experimentation can help, allowing for ongoing refinement and optimisation based on empirical evidence.

By quantifying qualitative aspects and establishing objective criteria, teams can more effectively arrive at the “good enough” sweet spot. This approach ensures that resources are allocated judiciously, core needs are met, and a solid foundation is established for ongoing iteration and improvement.

Embracing Iteration and Continuous Improvement

The beauty of the “good enough” philosophy is that it doesn’t preclude ongoing improvement. In fact, it embraces iteration and continuous refinement. By shipping a “good enough” initial version and gathering real-world feedback, teams can identify areas for enhancement and prioritise future efforts accordingly. This approach allows for more efficient resource allocation and greater responsiveness to the evolving needs of all the Folks That Matter™.

Fostering a “Good Enough” Culture

Cultivating a “good enough” culture requires a shift in mindset – one that values pragmatism, efficiency, and attending to folks’ needs over perfection. It means fostering an environment where team members feel empowered to make trade-offs and prioritise based on business impact. Teams play a crucial role in setting the tone, celebrating progress, and encouraging a bias towards action over analysis paralysis. Good enough applies to not only the product(s) but to the way the work to produce and support them works, too.

In essence, the “good enough” sweet spot is about striking the right balance – investing enough effort to deliver quality solutions that meet core needs, while avoiding the pitfalls of over- or under-engineering. By embracing this mindset, teams can optimise their resources, better address folks’ needs (but no better than good enough!) and foster a culture of (good enough) continuous improvement and adaptation.

Note to self: Mention the Kano Model, the Taguchi Loss function, and e.g. muri, mura and muda.

Building Method: Creating Shared Understanding of How We Work

February 7, 2024
Antimatter principle, Article, Needs, Quintessence, Requirements, Software development
Leave a comment

Building Method: Creating Shared Understanding of How We Work

With today’s complex business landscapes and rapidly evolving technologies, having a well-defined “way of working” is crucial for software teams to execute effectively. Most organisations adopt processes, frameworks, and methods that they believe will deliver software projects successfully within their constraints.

But how often do teams step back and ask – how well does our method actually work for us? How much have we actively built and shaped it based on our own learning? How much of what we’ve learned about how to build software do we apply to building our method(s)?

The Reality

The reality is most teams inherit an existing software development method or cargo-cult the latest hype they read about. They don’t consciously architect the foundations defining the collective work. Much like constructing a building without an intentional blueprint – the result is disjointed work patterns built piecemeal over time.

This leads to confusion, frustration, and quarterbacking* when team members operate on conflicting assumptions and mental models of how work actually flows. People spin their wheels questioning why things happened when lacked shared reasoning of how decisions get made.

That’s why teams dedicated to continuous improvement migh choose to prioritise Building Method. This means deliberately designing an optimal way of working given your realities – then updating the blueprint as you learn from experience.

Key Steps

Key steps for Building Method include:

  • Surfacing the needs of all the Folks That Matter™ re: the Build Method (old skool: requirements analysis)
  • Facilitating deep conversations about current practices, the good and the bad, what to keep and what to reject
  • Mapping out flows – where value gets created and lost
  • Defining decision rights giving clarity yet freedom
  • Distilling guiding principles for tracking outcomes vs needs
  • Envisioning the ideal configuration of people, process, tools
  • Inspecting then rewiring suboptimal current conditions
  • Embedding rituals allowing reflection and adaptation
  • Surfacing and reflecting on governing shared assumptions and beliefs about how work should work

While external benchmarks provide useful perspective, real transformation occurs when teams consciously architect agreements uniquely tailored for the Needsscape. By investing energy into Building Method you construct a living blueprint that evolves intentionally vs. accidentally over time.

Invitation to Contribute

What does your team’s current method look like – and how intentionally was it built? I welcome perspectives on elevating teams capabilities for effectively Building Method. Please share your experiences in the comments.

Aside

*Quarterbacking is when one person on a team takes on an overly directive role and excessively tells other members what to do, rather than allowing for collaborative decision-making and self-organisation.

The term comes from American football’s quarterback position – the player who calls out plays and commands the offense on each down. Calling someone a “quarterback” on a software team implies they are dominating discussions, assigning tasks, and tightly controlling the work in an ineffective way.

Quarterbacking can emerge when team members lack a shared understanding of role clarity, decision rights, working agreements, and processes. Without clear method or structure, an informal hierarchy forms with the most vocal directing others and disempowering the team.

The alternative is facilitating peer-to-peer collaboration where everyone has agency in creatively solving problems. Avoiding quarterbacking means intentionally designing team interactions that enable decentralised leadership, autonomy, and leverage collective intelligence.

So in summary, quarterbacking refers to overly directive and disempowering behaviour that stems from lack of clarity, structure, and self-organisation on a team. The solution is co-creating method that empowers the broader team.

Serving the Folks That Matter™: Hagakure Principles

September 18, 2023
Antimatter principle, Article, Attendants, Business, Quintessence, Requirements
Leave a comment

Serving the Folks That Matter™: Hagakure Principles

Commitment to the Folks That Matter™ Drives Satisfaction and Delight

Henry Ford once said,

It is not the employer who pays the wages; employers only handle the money. It is the customer who pays the wages.

This statement reinforces the Hagakure’s guidance on unwavering allegiance to one’s master. In modern product development, our true master becomes all the Folks That Matter™. Engaging fully with their needs and objectives doesn’t just improve the work; it also ensures outcomes align with the needs of those footing the bill.

Unwavering allegiance to one’s master is at the heart of Hagakure. In our setting, the Folks That Matter™ become the ‘master.’ To be truly committed means not just doing the work but understanding the why behind it. Are you meeting the needs  that matter to all the Folks That Matter™? Are you adding features that bring them value? Such targeted engagement ensures that your contributions align with the needs and objectives of those who actually pay your wage.

Loyalty: Team, Code, Customer?

Loyalty in the Hagakure transcends any transient obligation; it manifests as a lasting allegiance to your cause and your ‘master,’ in this case, The Folks That Matter™. How does this loyalty manifest in the workplace? It’s about becoming a reliable team member, adhering to standard work, and actively participating . This goes beyond your immediate team, extending to all the Folks That Matter™. After all, a robust and reliable product directly impacts folks’ satisfaction.

Courage: Risk for Reward?

Courage isn’t merely about overcoming fear; it’s a calculated action despite fear. The Hagakure praises the courage to make difficult but crucial decisions. In business, this courage manifests when facing hard choices. Maybe the current path for the product isn’t viable, or perhaps a much-loved feature doesn’t fit the broader objectives. Making these tough decisions serves the long-term interests of The Folks That Matter™, who, as Henry Ford pointed out, are the actual wage payers.

Honour: More Than a Virtue?

The notion of honour is deeply ingrained in the Hagakure’s teachings. This isn’t about an abstract moral high ground but about tangible actions that uphold your integrity and reputation. What does it look like in practice? Treating teammates with respect, attending to their needs, ensuring ethical working practices, and being transparent in all interactions. These actions don’t just impact internal team dynamics; they resonate with the needs of all the Folks That Matter™, thus fostering a level of trust and respect that builds long-term relationships.

Presence: A Cornerstone for Satisfaction?

Being present in every undertaking is a key lesson from the Hagakure. This principle isn’t just philosophical; it has practical implications. In a world filled with distractions, giving your complete attention to the task at hand might be more challenging but it’s also more rewarding. This focus allows you to tackle issues more effectively, craft better features, and ultimately provide a product that better serves the needs of the Folks That Matter™.

In summary, combining the ancient wisdom of the Hagakure with Henry Ford’s insights results in a fresh, yet rooted, approach to work. Embodying commitment, loyalty, courage, honour, and presence ensures a strong alignment with the needs and values of The Folks That Matter™, effectively reminding us who really pays the wages.

Crosby’s Four Absolutes of Quality Reframed

January 2, 2022
Antimatter principle, Compassion, Culture change, Needs, Organisational effectiveness, Product development, Quality, Quintessence, Requirements, Software development
Leave a comment

Crosby’s Four Absolutes of Quality Reframed

I recently posted a quickie repeating Phil Crosby’s Four Absolutes of Quality.

I accept that many folks find his choice of vocabulary less than clear. So, here’s a reframing of his four absolutes, reframed in the Antimatter Principle vocabulary (a reframing which you may or may not find more helpful).

  1. The definition of quality is meeting everyone’s needs, NOT “goodness”.
  2. The behaviour that causes quality to happen is paying attention to folks’ needs, NOT inspection.
  3. The performance standard for quality is “all needs met, for all the Folks that Matter™️”, NOT “that’s good enough”.
  4. The measurement of quality is the cost of focus, NOT indices.

– Bob

Quintessence: Who Matters?

December 22, 2021
Antimatter principle, Article, Culture change, Needs, Organisational effectiveness, Product development, Quintessence, Requirements, Software development
1 Comment

Quintessence: Who Matters?

A sample chapter excerpted from my new book “Quintessence“ – book available now on Leanpub (free sample also available).

Note: Each of the eighty-odd chapters in Part II of the book takes a specific meme, and describes the collective beliefs and assumptions that quintessential organisations hold in regard to the meme. By taking all the memes in toto, we can understand the way quintessential software development organisations see the world of work – and what makes them so effective. This particular sample meme is about who matters.

Chapter 15. Who Matters

Quintessentially

Quintessential organisations regard the needs of their customers, staff, managers, investors, etc. as central to the way the work works. Collectively, these folks are sometimes called The Folks That Matter™️. These organisations invest much effort in:

  • Identifying the various constituencies and the people who belongs to these constituencies.
  • Tracking the set of constituencies, and the changing membership of these constituencies, over time. 

“Understand stakeholder symmetry: Find the appropriate balance of competing claims by various groups of stakeholders.”

~ Warren G. Bennis

The quintessential organisation exhibits the following (collective) attitudes and feelings towards the Folks That Matter™️:

  • A keen urge to understand and track the needs of all the Folks That Matter™️.
  • Inviting folks to come up with explicit policies for defining and tracking membership of the set of all Folks That Matter™️.
  • Practices to both discover and attend to these needs.
  • Defining organisational success in terms of needs met.

Quintessential organisations recognise the major costs and other risks arising from missing out key members from the set of all Folks That Matter™️. These risks receive their continuous scrutiny – both in terms of accurately identifying members and in terms of ensuring these members’ needs are attended to, and ultimately, met. All work of the organisation is geared towards meeting the needs of the Folks That Matter™️. Maximising the amount of work NOT done is achieved by cautious (risk-aware) exclusion of insignificant groups and individuals from the set of the Folks that Matter™️, whilst striving to drive towards zero the instances of omission of significant groups and individuals from the set of the Folks that Matter™️.

Stakeholders

Quintessential organisations recognise the distinction between stakeholders and The Folks That Matter™️. The needs of some stakeholders sometimes don’t much matter, and some of The Folks That Matter™️ aren’t actually seen as stakeholders (employees, for example).  Given these distinctions, choosing different terms helps communication and, more significantly perhaps, improves Cost of Focus.

Further Reading

Kleiner, A. (2003). Who Really Matters. Currency.

Quickie: Sabotaging Developers

September 1, 2021
Quickies, Requirements
Leave a comment

If I wanted to really sabotage software developers, I’d give them a requirements management tool heavily weighted towards unilateral stipulations, instead of conversations, experiments and mutual explorations.

Quickie: ZeeDee Invites Discussing Folks’ Needs

August 22, 2021
Quickies, Requirements
Leave a comment

ZeeDee invites folks to discuss each others’ needs, especially the needs of the customer.

Indeed, getting “requirements” straight necessitates such discussions.

 

Who’s Afraid of the Big Bad Wolf?

August 21, 2021
Article, Requirements
5 Comments

Who’s Afraid of the Big Bad Wolf?

The wolf in question for this post being “Requirements”. 

In a recent Quickie I presented Phil Crosby’s Four Absolutes of Quality. The first of these four absolutes being:

1. The definition of quality is: conformance to requirements.

Let’s unpack what Phil meant by “requirements”. His meaning was very different from developers’ and software folks’ typical understanding of the term.

Suppliers and Customers All Down the Line

In Phil Crosby’s world, everyone is both a supplier and a customer. “Upstream” folks supply parts, information or other things to their most immediate downstream customer(s). Each such supplier/customer relationship is mediated by a mutual understanding of, and agreement on, what the customer needs, and thus what the supplier recognises they must provide. Hence “Quality”.

And, by the way, reflecting the mental model of an organisation – stretching back upstream into the organisation’s supply chain, and downstream into its distributors and customers – as a “braided river” of value streams (see the image accompanying this post).

Mutually Agreed Interface Standards

It’s this mutual understanding that Phil calls “requirements”. Not some massive document with screeds of tedious detail. Not some specification of the supplier/customer “interface” written and imposed by some more-or-less clueless third party.

Fear

In my travels, I’ve seen folks of every stripe run a country mile from “requirements”.

Senior management don’t like the idea because they fear their freedom of action being constrained by such things. (Untrue, by the way).

Developers don’t like the idea because they fear being dumped-on by some requirements weenie who has a different – and often erroneous – idea of what the customer needs.

And most folks fear being corralled by a set of requirements that, even when accurately reflecting the needs of a customer, hem-in their freedom to supply what they like, rather than what’s needed. 

How do the folks in your organisation regard the idea of requirements? Do “requirements” in your organisation look anything like the Crosby definition?

– Bob