Matt Wynne

As AI accelerates software development, I see something emerging that I think needs a name. Excuse me for getting fancy, but I propose we call it Lean Software Production.

Or maybe Lean Software Manufacturing? 🤷🏼

Lean Software Production acknowledges that software is no longer a craft, and that mass production is too rigid, inflexible, and inhumane. It combines:

1. Lean: Industry-standard in modern manufacturing, lean thinking means managing the production system using human-centric continuous improvement, systems thinking, pull-based flow approaches.

2. Software: The robust software engineering disciplines of Extreme Programming (XP) that keep the software malleable.

3. Production: Agentic orchestration or dark factory patterns, where LLMs generate large amounts of code unattended.

Let’s dig into these three elements to understand why they matter and how they fit together.

Why Lean?

When comparing the way the Americans approached manufacturing in the 1960s compared to the Japanese lean pioneers, W. Edwards Demming said:

Let’s make toast: I’ll burn it, you scrape it

Many people are working with LLMs like this today: letting the generate code and then trying to inspect the quality in through code review. By adopting the mindset of kaizen (continuous improvement) and practicing defect prevention, we can learn from the system’s mistakes and improve it.

Lean thinking revolutionized the manufacturing of physical goods in the 1960s and 70s, and was fundamental in inspiring the Agile Software development movement in the early 2000s. The Toyota Production System views the production line as a socio-technical system, an elaborate dance between humans and machines.

As machines begin to play an ever-increasing role in the production of software, the pace of delivery accelerates, and the role of humans in this process changes rapidly, I think these ideas are crucial for us to re-visit.

Some ideas and tools from lean, such as Kanban boards, have become a ubiquitous part of the software industry culture. Kanban is rooted in the idea of just-in-time (JIT) production or pull-based flow, popularized as The Theory of Constraints in Eli Goldratt’s The Goal. This idea is also the basis of a Minimum Viable Product (MVP) from Eric Ries’ The Lean Startup.

But there’s so much more in lean that we’ve yet to really embrace. I believe it can really help us in this moment.

In Lean Software Production, instead of spending time crafting every line of code, we focus our attention on crafting the system we use to produce reliable, well-engineered software at scale. By working with the system, continuously improving it, we’re following the lean discipline of Jidoka: building quality in.

What does this look like in practice? For example:

• if you notice your agent is making mistakes and generating code that you have to correct, don’t blame the model: Instead, look to how you could have improved the context you gave the model so it would make a better decision next time. Try capturing architectural decision records (ADRs) or design heuristics in your git repo where the agents can study them before writing code.
• if you’re confounded by walls of text or code coming out of these models, try asking them to build you a slide deck, or write an HTML file summarizing the key points that you need to understand and consider. Have the agent present or receive the information in a medium that works for you.

This culture of continuous improvement and just-in-time work has created great manufacturing systems, and I believe it’s key to creating great software production systems too.

Why Extreme Programming?

When a single engineer can generate the volume of output that once required a team, the costs of problem ambiguity, architectural weakness, slow or unreliable tests and defects don’t just cause friction, they set things on fire.

In this light, the robust software engineering practices of XP finally start to look like standard industrial safety equipment:

• Pervasive automated testing, like double-entry bookkeeping for your code
• Continuous integration, so you get fast feedback about whether your changes integrate with everyone else’s
• Relentless refactoring and a commitment to high-quality code, keeping the software soft and malleable.
• Pairing on decision-making, so that the team keeps a shared mental model of where the system is going and why, through conversations.

If you’re fearful of LLMs producing slop, or building a system that nobody understands, these are the techniques that the best software engineering teams have used for decades to mitigate that risk with humans.

Now, two things have changed: you need these techniques more than ever, and it’s cheaper than it’s ever been to implement them. There’s really no excuse.

For example:

• Ask a robot to introduce mutation tests into your CI pipeline.
• Build a review/fix loop that takes on Sandi Metz or Martin Fowler’s persona, identifies flaws in your code and fixes them, autonomously
• Leave an agent in a loop reviewing your test suite for slow tests and optimizing them

To be clear, I’m not just talking about getting your agent to use test-driven development while it generates code for you. I think that problem has largely been solved. I’m talking about taking the attitude, the values of extreme programming and applying them to this agentic moment. I’ve already written about how pair programming is changing, and I recognize

Instead of cramming in more features, spend the extra time you’re gifted by these LLMs to improve your working environment, to improve the flow of your software factory.

Towards the Lean Software Factory

Earlier this year I was fortunate enough to spend a week in a workshop with Justin McCarthy, co-founder and former CTO of StrongDM, who pioneered the idea of a dark factory for software development.

Justin’s team set themselves a rule:

Code must not be written by humans

Code must not be reviewed by humans

This sounds scary at first, but like many challenging ideas, it forces you to really think about what would need to be true for you to do it.

If you can’t review the code, how do you know whether it’s good? You have to build yourself systems that can judge that goodness for you, and you have to be able to tell them what good looks like. Good in all its forms: architecturally sound, secure, performant, user experience, to name just a few.

I think many people trying to adopt AI coding tools right now are stuck in a kind of half-way house: they use LLMs to generate code, but they don’t think about how else they can use it to modernize and automate their entire software delivery pipeline. In that way they just end up making things worse.

Annie Vella uses “middle loop” to describe a layer of work where engineers supervise AI doing what they used to do by hand. Her research shows that a lot of folks are getting mixed results with this right now, and I think that’s understandable: there just isn’t a lot of good literature or patterns in our industry for how to do it well. Birgitta Böckeler has written about harness engineering, where engineers focus less on engineering the code itself, and more on engineering the system that produces the code.

Once you’ve experienced “hands off” software development, where you neither write nor read the code, there’s no going back. The pace that you can solve real problems for people is exhilarating.

As the models get better and better, the question increasingly becomes: what can’t the agents do? By asking ourselves this continuously, and using their power to automate away tasks that are mundane and error-prone, we elevate our own work to something I consider to be much more interesting: deciding what problems to solve, and how to judge that they were solved to our satisfaction.

The product is still working software, but now the work is engineering the system that produces it.

—

If this sounds interesting to you, I am teaching a public course starting July 16th: Build a Software Factory: Hands-off agentic coding for experienced engineers.

This blog post was entirely organically written by my human hands and brain. I want to thank several people who gave feedback on earlier iterations: Jeremy Lightsmith, Rob Bowley, Chris Parsons, Emily Bache, Dave Farley.

A few months ago our boss challenged us to adopt the Dark Factory pattern for agentic software development. Inspired by the work of Justin McCarthy at StrongDM, where they committed to producing software where humans neither read or wrote the code, we started to explore this exciting and daunting technique.

I'm someone who's always taken pride and enjoyment in crafting solutions in software. I remember reading Mary and Tom Popendick's book, Lean Software Development, where they talked about conceptual integrity and how the internal design quality of a piece of software is reflected in its usability and ultimately its value to its users. If the code is shit, that leaks out. You can feel it when you use it.

When I first started at Mechanical Orchard, in February 2024, I'd barely even used AI. At that time the best you could do was copy and paste a snippet of code into a ChatGPT window and roll the dice to see whether what you got back was just a hallucination, or something useful. At the time I was pretty sceptical and just kind of buried my head in the sand and hoped that it would all go away.

A year or so later though, it was clear that it wasn't going anywhere. I started to turn towards this technology, really try to understand it and figure out how to make it useful to me.

As the models got better and the tools like Claude Code came out, my confidence in using them increased, and I really started to enjoy it. I played with Ralph Loops and eventually built a tool for myself using a language I'd never read or written before. I’ve still never read the code, but I use that tool every day.

But how can non-deterministic coding agents possibly be trusted to produce entire systems where nobody has read the code? Won’t it be garbage? I think a lot of my friends in the agile/XP community still feel like this, and I understand why. Friends, this post is for you!

Let’s get into what a dark software factory actually is, and why you shouldn’t be afraid of it.

At its heart, any dark software factory is just a really simple loop.

Each of the nodes is an agent session. By putting them into a loop like this, with a well-designed validation harness, and a good quality seed as input, you facilitate these non-deterministic agents to naturally converge on the solution you want.

Now it's important to consider scale here. We're not talking about a factory where metal comes in and cars come out. Not necessarily anyway. We're talking about automating mundane, repetitive processes that would normally need a human in the loop, but where the desired outcomes can be judged by clear heuristics.

The better and braver you get at this, the more ambitious you can be about the scale of those processes, or composing them together. But it's perfectly fine to start with something small and boring.

For example, on the yaks project, I have a series of ADRs, architectural decision records, that describe the architectural structure I want the application to have. Periodically, I run an architectural review where I ask an agent to compare the actual code with those ADRs and notice where they are incoherent. It comes back with a list of recommendations, and we pass that list of recommendations to another agent to implement the first one. We run our automated tests of course, but we’re not valid until all those recommendations have been addressed. So we loop.

I can leave this thing grinding for an hour or more and when I come back the integrity of the code has been improved according to my design heuristics, with me barely having to lift a finger.

So we don't just have to use dark factories to generate even more implementation code. We can use them to perform maintenance tasks that actually improve the quality and integrity of the code we're writing, provided that we know how to provide that harness that will guide the agents towards what good looks like.

You can still write the production code by hand, if you like! Then have a factory grind on mitigating the security vulnerabilities, or merging dependency upgrades, or running and triaging mutation tests.

Of course you absolutely can have a factory that writes production features for you too, but that’s only one way of using this pattern.

This is where the whole thing starts to remind me of learning test-driven development. When you first start to learn TDD, it's hard when you're used to starting from the implementation to have to think about where you want to go before you go there. It's hard to describe in a test what you want because you have to think about what you want without having had the chance to explore the path towards it.

In the same way, designing a dark factory is challenging because you have to create this validation harness, and that forces you to think about what you want, before you have it. This still feels a lot like TDD to me, just on a bigger scale.

No tokens were spilled in the writing of this post. This is entirely hand-crafted, artisanal writing.

I’m funemployed as of this week, but I do need to start thinking about earning some income again.

I’ve spent the last two years on an absolute rollercoaster learning an incredible amount. I’m now fluent in Elixir, in awe of the BEAM, not afraid of nix or kubernetes, and I can even read and write a little COBOL. But mostly for the past few months I’ve been experiencing the scale of what we can do when we apply advanced agentic coding practices like dark factories together with industry best-practice software engineering techniques.

My current interests are around:

• How to leverage dark factories for maximum impact, creating feedback loops to allow LLMs to converge on the solutions we want while keeping humans in the loop at the right moments.
• How the agentic moment is changing our work cultures, and how we organize ourselves and collaborate as humans as the pace of delivery accelerates, and the legibility of our work increases.

If these ideas are interesting to you too, or you’d like some help bringing them into your company, please get in touch.

If you’re responsible for a budget that pays programmers or other knowledge workers, you probably care a great deal about getting good value for money from them.

This post describes a model of the burdens we place on these teams and the results we expect from them, called Cognitive Load. It’s a great thinking tool to help us manage capacity to achieve quality results without burning people out.

Cognitive load

If you’ve ever been a programmer yourself, you probably have some sense of what Matthew Skelton and Manuel Pais mean when they talk about the cognitive load on a software team.

The total amount of mental effort a team uses to understand, operate and maintain their designated systems or tasks.

— https://teamtopologies.com/book

Cognitive Load Theory comes from education, and it’s important to be aware that it has not been studied in the context of day-to-day programming work. However, my experience is that programmers spend all day learning: about their problem domain, their codebase, their tools and programming environment, their production environment, their team-mates and themselves, and so the application of this theory to knowledge work feels instinctively right to me. The authors of Team Topologies have made a great case for it.

The theory breaks down cognitive load into three types:

• intrinsic: the (lack of) ability of each individual learner to pick up the new concepts
• extraneous: how hard we make it for the learning to happen
• germane: the difficulty of the task itself

I find these original names a bit abstract and difficult to grasp. I propose some new names that I think better express what they mean, at least the context of knowledge work:

• Cognitive strength (of the individual or team)
• Cognitive friction (from the environment)
• Cognitive weight (of the task or problem)

The total cognitive load on any given team or individual is some function of these three elements. A team with high cognitive strength, working in an environment with low cognitive friction, performing tasks of low cognitive weight, will experience a cognitive load that’s well within their capacity. On the other hand, a team with low cognitive strength, working in an environment with high cognitive friction, attempting tasks of high cognitive weight, will struggle and become overwhelmed.

So for people paying for programmers, thinking about cognitive load is important. If you want quality results, you need to keep the cognitive load on the team within their capacity.

You want the cognitive load on the team to be coming from the hard problems they’re solving for your organization (cognitive weight), not from their environment (cognitive friction); and you want them to have the capacity (cognitive strength) to be able to carry the load you need them to.

Cognitive strength

If we can talk about cognitive load on a team, it’s also reasonable for us to talk about their cognitive strength: the amount of mental effort any individual or team has available to apply to their work on any given day.

In my experience, cognitive strength fluctuates: some days I feel sharp and I can tackle tough problems with relative ease and clear focus; other days, I just seem to get stuck and frustrated. This is also the concept of “gumption” from Zen and the Art of Motorcycle Maintenance:

Gumption is the psychic gasoline that keeps the whole thing going. If you haven't got it there's no way the motorcycle can possibly be fixed. But if you have got it and know how to keep it there's absolutely no way in this whole world that motorcycle can keep from getting fixed.

This is also similar to the (much debated) concept of decision fatigue or ego depletion. Famously, former US president Barack Obama only had two colours of suit:

You’ll see I wear only gray or blue suits,” [Obama] said. “I’m trying to pare down decisions. I don’t want to make decisions about what I’m eating or wearing. Because I have too many other decisions to make.

Cognitive strength also comes from experience. Knowledge of the problem domain, the specific programming language and frameworks, and the codebases used by the team, are all important indicators.

The more cognitive strength your team has available, the more cognitive weight they can carry.

Unless, of course they’re subjected to too much cognitive friction.

Cognitive Friction

Cognitive friction comes from the environment around a team, for example:

• How often are they interrupted by context-switching?
• Do they have great equipment and tools?
• Are repetitive processes automated?
• Do the team like each other? Do they feel psychologically safe around one another?
• Does the team practice Test-Driven Development (TDD) /Behaviour-Driven Development (BDD) or work in more of a code-and-fix mode? Do they do test automation at all?
• Is the codebase well architected and pleasant to navigate, or is it a confusing mess?

This friction contributes to the cognitive load on the team by amplifying the cognitive weight that the team is trying to carry. A relatively simple task can be made challenging by a high-friction environment, while difficult tasks become much easier when you have the right environment to support you.

Cognitive weight

When thinking about capacity, I like the metaphor of carrying weight for the work we do as programmers.

Some of the problems we solve are small and light, and even the most junior person on the team would have the cognitive strength to pick them up and solve them.

Working on problems that are a bit of a stretch builds cognitive muscle, and increases your strength for next time.

Some problems are big and heavy, and require a great deal of cognitive strength to tackle them.

Working on problems that are too big will crush you. Sometimes the cognitive load of a particular problem is just too great for any one individual to bear alone. It’s hard to sum it up any better than this comic from @vincentdnl:

Sure, you might have one powerful genius on the team who, through some fortunate combination of coffee, context and confidence is able to summon the cognitive strength to solve the problem on their own. But will anyone else on the team ever be able to touch that code again? Will this heavy block of cognitive load get carried gently to its destination, or is our solo hero, straining every mental sinew, likely to give it some bumps and scrapes along the way, leaving complexity and bugs in the code?

This is why we need ensembles, but more on that another time.

Capacity

Just like lifting weights in the gym, we will get the most out of a team if they’re operating at around their cognitive capacity, but not exceeding it.

This is an art, not a science, and involves working respectfully with the team, rather than throwing work at them.

All three elements of cognitive load on a team are things you can control, to some extent:

• You can create space, provide resources or coaching for teams and individuals to study and practice to increase their cognitive strength. You can add individuals with the right context and experience to increase the team’s collective cognitive strength. You can encourage them to work in ensembles, which multiply the cognitive strength of a group.
• You can facilitate continuous improvement processes, and encourage teams to take ownership of and solve problems that cause them friction. You can invest in these solutions to make it clear how important it is.
• You can take care not to overwhelm teams with problems that are beyond their capacity, breaking down problems or even entire monolithic systems, so that the team have the possibility to wrap their heads right around the work.

If you like the ideas in this post, you can hire me to work with your team or organization. I’m available!

In this post I want to talk about feminism: why I have personally embraced it, why I encourage you to, and — since you may be reading this because you’re somehow involved in the agile software development scene — how it can explain why your “agile transformation” is probably going to fail.

Last summer, I had a few days to myself, doing a road trip through the beautiful Columbia Basin, camping, hiking and mountain biking. Just me and the dog.

With a few hours to spend behind the wheel, I picked an audiobook from my wish-list, almost at random. A few days later, I was so rapt, I was sitting by the campfire in the evening with my headphones on so that I could finish it before the end of my trip.

I started to glimpse an insight about agile that had been nagging and frustrating me for years.

What was the book? The Gender Knot by Allan G. Johnson.

I recommend this book to anyone, but especially to men.

I thought I knew about feminism, and understood about the patriarchy, but this book brought me to a whole new level of comprehension.

I realized that patriarchy is the root cause of so much of what scares and saddens me about the world: fascism, colonialism, slavery, war, industrial capitalism, environmental destruction, racism, homophobia, transphobia, misogyny, men’s violence against women, men’s violence towards each other.

Johnson characterizes our relationship with patriarchy like a fish’s relationship to water: So ubiquitous as to be almost impossible to perceive.

Patriarchy is everywhere, and yet we almost never talk about it.

So what is patriarchy?

The patriarchy is not some big conspiracy. It’s a kind of “stable state” that our complex social system has settled into, and it’s very good at reinforcing itself. It can be found everywhere people interact, from social norms, our language, to our literature, TV and movies.

Johnson says that patriarchy's defining elements are its male-dominated, male-identified, and male-centered nature. Let’s break that down:

• Male-dominated: patriarchy is a hierarchical social system that puts some people, generally men, at the top in positions of power and others, generally women, in lower, subordinate roles. Men tend to dominate others in this system.
• Male-identified: patriarchy’s culture tells us the traits that are desirable and normal in a person are traits that are also associated with its ideal version of masculinity. Being strong, aggressive, self-controlled and competitive are celebrated, while “feminine” traits such as sensitivity, collaboration, caregiving and kindness are looked down on as inferior, weak. Men who display these traits are often subject to ridicule. Women who try to break out of their stereotype and exhibit masculine traits are similarly ridiculed.
• Male-centred: in patriarchy, the world revolves around men. They are the stars in our TV shows and movies, the famous inventors, heroes and leaders in our history books. Patriarchy emphasizes the achievements of men, while ignoring or minimizing the contributions of women.

And because patriarchy puts men at the top of its power dynamic, without us nothing can really change.

Yet despite the very real privileges it gives us, men suffer from the patriarchal system too. Patriarchy’s idea of masculinity leaves no room for fallibility, vulnerability, or intimacy.

As bell hooks said, Feminism Is for Everybody.

OK, but what does this have to do with agile software development?

Lightbulbs were going off for me all over the place as I read this book, but the insight that’s relevant to agile software development centres around this:

Patriarchy is a social system of dominance, control and fear.

Patriarchy reinforces its grip on our social systems by encouraging those at the top to maintain their dominance through control and fear.

Does this sound familiar?

When I read this, my mind kept returning to the way we talk about “command-and-control cultures” — the miserable way so many people are treated, and treat each other, at work.

It strikes me that what I would regard as the true essence of agile software development — the self-organizing, transparent team that works in a trusting, collaborative relationship with its stakeholders — is an example of feminist principles in action.

It turns out I’m not the only person who thinks this.

Why your agile transformation will eventually fail

Over and over again, I have experienced the same frustrating problem at different companies all around the world:

Eventually, at some point, any movement towards agility within an organization seems to come up against an invisible barrier. A force that, without careful, deliberate and ongoing attention to protect and nurture that movement, will undermine and ultimately destroy it.

What is that force? What makes it so powerful? Why do I keep coming up against it again and again in different organizations all over the world?

If we accept the premise that our entire society operates on this undercurrent of dominance, control and fear then it stands to reason that our workplaces will have same background hum. The invisible force.

It’s no wonder that agile transformations so often fail: they’re coming up against the patriarchy.

I have a problem with acceptance criteria, for two reasons.

First of all, their definition in the literature is hazy, which frequently means they're awful. They're either too vague and have gaps, or they're too detailed and still have gaps!

Second of all, user stories were always meant to be a token for a conversation.

A token. For a conversation.

What I see people do, time and time again, is use acceptance criteria as a substitute for a conversation. They add the story into their Jira backlog, and they add some acceptance criteria, and then they throw it over the wall to the developers to code it up, no questions asked.

This is not how it's supposed to work.

A token for a conversation

Let's start by going back to 2001, when Ron Jeffries, one of the originators of eXtreme Programming (XP) wrote a seminal article describing the “three critical aspects” or “three Cs” of User Stories: Card, Conversation, Confirmation. Since User Stories originated in XP, and Ron is one of the three people who invented that methodology, it seems important to listen to what Ron has to say here.

Bear in mind we're talking about the late 1990s, the pre-Jira times. Everyone sat in the same room, and the planning tools were analogue.

User stories are written on cards.

I spent most of the 1990s in nightclubs and ski-towns, but I'm old enough to remember a time when we kept our agile team’s plans on physical index cards on the wall of our team room. One advantage of an index card is that there's only so much room to write on. No comment fields. You can't go into too much detail.

The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is.

And, crucially,

The card is a token

So the card represents the need for a future conversation. It's a way to defer work, to allow you to focus on the detail of what you're doing now and next, without forgetting what you'll need to be doing after that.

Even though we rarely use physical cards to represent user stories these days, this metaphor is still important. There is no point in going into too much detail too soon. It's wasteful and potentially even counter-productive.

The second “C” comes when it's almost time to do that work, when you do need those details:

The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings.

I can't emphasise this enough, but I'll try: The requirement is communicated from customer to programmers through conversation.

Why conversation? What's wrong with just writing down the details of the requirement, telling the user's story, in the Jira ticket? We're no longer limited by physical cards, so what's the problem?

Gaps

Let's assume, for a moment, that the project you're working on is actually significant. That it adds something fresh, does something innovative. Something that's never been done before.

If that's the case, then I would argue that the most important part of your work is discovering all the things you don't know yet. The gaps. The unknown unknowns.

The rest is easy.

Yet time and again, we see product owners spending inordinate amounts of time on the easy bit: writing down everything they already know about the problem as acceptance criteria in their Jira tickets, and paying scant attention to trying to deliberately discover the unknown unknowns lurking in their backlog.

This is one huge reason a conversation is so important. Although the product owner naturally has the best grasp of the user's problem, there's no way they can have thought through everything. Even if they could, how can they know by simply writing some words in a Jira ticket, that their understanding has been perfectly transmitted to the minds of the people who will actually be writing the code.

Waste

By having a direct conversation with the developers, the product owner gets two benefits: firstly, many minds scrutinize their emerging mental model of the problem to be solved, giving the team the best chance of discovering as many of those unknown unknowns as possible. Secondly, they get an opportunity to check for understanding, to make sure the developers see the same thing as they do. Software is made of thoughts, and to build anything useful we need to make sure those thoughts are at least roughly aligned.

But let's be clear: working software is the goal; everything else is waste.

The game here is to try and do just enough planning, just in time. The beauty of a well-timed conversation is that we barely need to write anything down at all. The programmers carry the understanding that emerged from that conversation straight into the codebase.

Often it does make sense to take down some notes so that we can remember the details of what we decided in the conversation. So what's the best way to do that?

How can we make our acceptance criteria awesome?

Rules and Examples

Not to pick on anyone in particular, but a significant detail that was missing from the descriptions of acceptance criteria in books I read as an impressionable young scrum-master was the distinction between rules and examples.

Acceptance criteria, or conditions of satisfaction as Mike Cohn calls them, would usually look something like this:

Story: As a new user, I want to sign up for an account using my email address and password, so that the system will remember my details for my next visit.

Acceptance criteria:

• Password must be a strong password
• Can't create two accounts with the same email address
• Email address must be confirmed

These look fine, right? And that's precisely the problem. They are hiding the gaps.

That's because they are rules. The problem with rules is that they lull you into a false sense of security, give you a feeling that everything is OK. Yet our experience should tells us that it's probably not: What exactly do we mean by a strong password? How exactly will the email address be confirmed?

This didn't become clear to me until I read Liz Keogh's blog post, acceptance criteria vs scenarios. Here's how Liz describes the importance of examples:

Talking through scenarios is, for me, the most important aspect of BDD. That’s how we discover whether we have a shared understanding or not; by using specific examples to illustrate our understanding or discover our ignorance.

Examples are great. They are vivid and real and they fire people's imaginations. This is exactly how you give yourselves the best chance of seeing the gaps.

But on their own, examples are like a photograph without a caption. They lack context. One of the worst examples of acceptance criteria I've seen is when a product owner takes it upon themselves to write reams of Given-When-Then scenarios into a Jira ticket.

What you need is rules and examples. This is where Example Mapping comes in.

Example Mapping

One problem with the conversation is that it can often lack structure. People generally hate long rambling meetings, and for good reason.

The beauty of example mapping is that it gives you a clear structure to the conversation, and visual feedback on what you're learning and deciding in real time as the conversation progresses.

Neither the rules or the examples have to be exhaustive, but they should reflect the conversation, and your shared understanding, back at you.

Example mapping adds one more element to our awesome acceptance criteria checklist: Questions.

Many people have told me that the explicit capturing of questions in example mapping has had a profound effect on their team's behaviour. This is where we capture the gaps, the things we are just starting to realise we still need to figure out.

I won't go into detail about example mapping in this post, so let's end with a recap about what we've learned so far about what makes for awesome acceptance criteria:

• Derived through conversation
• Include both rules and examples
• Include questions we couldn't answer yet

Coming back full circle to Ron's original post, the third “C” is Confirmation, and specifically the acceptance tests that the team will automate on the customer's behalf in order to know when the story is done. Examples are a great basis for these tests. Perhaps we'll write more on that another time.

—

If you want to learn more about example mapping, we’re teaching an online, cohort-based course. Sign up here.

As I consider my future, I’ve been thinking about what I want the next chapter of my working life to look like.

Here are the things that really matter to me, in rough priority order:

1. Provide a sustainable livelihood for my family

2. Enjoy a fulfilling, inclusive, creative and fun work environment

3. Solve an important problem for society

4. Contribute to the commons

5. Teach others what I know

#1 is a given. I realise I’m lucky to be able to expect this, but I do.

I’ll put up without #2 for the right price, but I won’t stick around for long unless I get the influence to create that kind of environment for me and everyone else.

I am really puzzled about #3. It seems like so much of the work available to me is simply making the engine of capitalism slightly more efficient. I’m OK with that – it’s the paradigm we live in, like it or not – but I deeply yearn to do something more political, to use the skills I have to actually improve society.

#4 matters to me a lot, but probably not quite as much as #3. I’m not really sure I believe in proprietary code at all anymore, and at the same time I’m really curious about how we can make open source software pay, to make it more sustainable instead of just relying on corporate philanthropy.

#5 gives me a great deal of pleasure, and I guess is really a part of #2.

If I could find a role with all five, I’d be very happy!

Back in 2010, David Chelimsky was re-writing RSpec, and had the idea to use Cucumber scenarios to drive the development. The RSpec website was not much at the time, and David’s intention was to generate user documentation automatically from those scenarios.

I was invested in the Cucumber open source project as a core team member, working as an independent consultant, and just starting to think about how we might be able to build revenue-generating tools around it.

So, together with an RSpec team member Justin Ko, I started work on Relish. Over time, Justin drifted away from the project, and my friend John Hardcastle got involved to help with the UX.

For a while, I was really into it. The service was growing, we had users who wanted to install it on-prem, and there was an active UserVoice forum (remember them?!) where people left their feedback on what else it should do.

In 2013 I started Cucumber Ltd with Aslak Hellesøy and Julien Biezmans, and Relish became part of the IP of that company. We did some lightweight maintenance on it, but our attention became focused elsewhere on building shiny new things – a collaborative editor for Gherkin based on CRDT, which we called Cucumber Pro – and building the training business that was bringing in the money.

To my frustration, each new iteration where we’ve tried to build a commercial tool for BDD practitioners (Cucumber Pro, Jam, CucumberStudio, Cucumber Reports) has never matched up to Relish for the basic use-case of publishing read-only documentation. We never quite got there before the project was shelved and we moved on to the next thing. So the RSpec project have remained its most loyal and biggest users.

Fast-forward twelve years, and the https://relishapp.com/rspec pages are still visited by hundreds of Ruby programmers every day.

Relish's IP and hosting is now owned by SmartBear, who acquired Cucumber Ltd in 2019.

Mostly, Relish has “just worked” and hasn’t caused us too many problems. There has been the occasional glitch that needed a touch of heroku run rails console but we’ve mostly been able to get away with paying it very little attention.

Until this week.

Unfortunately, I’m no longer in a position to be able to help. We have started some early conversations with SmartBear about releasing the IP for Cucumber, which I assume would include Relish’s codebase, but it’s early days.

My hope would be that we can open-source the code for Relish (in retrospect I wish we’d done this ages ago), find some sponsors for the hosting, and let it continue to serve as a platform for the RSpec team. At the very least they could salvage the rendering code to generate their own static documentation.

For the time being though, I’m afraid we’re a bit stuck.

Well, this is new.

After ten years building a company around the Cucumber open source project, I suddenly find myself out of a job.

I was laid off last Friday by SmartBear, who in June 2019 acquired the company I co-founded back in August 2013. It’s no secret that I had recently been involved in a research project to determine Cucumber’s future direction at SmartBear. As the last remaining employee lucky enough to be paid to work on the open source project full-time, I guess the powers that be had already made their minds up about what the outcome of that research would be.

I figured we might be in the end-game, but I hadn’t expected it to come around so suddenly.

Practicalities

I was actually on vacation, with no internet, while all this happened last week, so I was not prepared. I’ve lost access to my matt@cucumber.io email address, meaning there are various services (like Cucumber’s community Slack) that I can’t sign into with my normal account. My GitHub notifications for the Cucumber project were also going into that inbox too.

So if you’ve written to me at that email address, or you’ve pinged me in GitHub or Slack and haven’t got a response, that’s the reason why.

Wow. Are you OK?

Emotionally, I’m OK; thanks for asking 💖

While it’s been interesting, from an anthropological point of view, to spend so much time on the inside of a private-equity backed US company, the culture didn’t suit me well I am pretty relieved—even excited—to be out. I also did a lot of grieving around the time of the acquisition, and I have a lot less attachment to the Cucumber project or my role in it than I used to.

Still, I feel a sense of responsibility towards it, and I hold a great deal of respect and affection for the volunteer members of the community who put so much of their free time into nurturing the project.

I’m not taking this personally. SmartBear has grown significantly since we were acquired in 2019, and the scale of their ambitions has grown too. Although our research showed there is a market for commercial tools built for the Cucumber audience, that market probably just isn’t big enough for a company like SmartBear. There’s no compelling reason for them to continue sponsoring an open source project that doesn’t directly contribute to the bottom line.

I’m optimistic that SmartBear will have the good sense to avoid doing a Hudson, and I’ll do what I can to try and ensure that assets such as the domain, trademarks, training videos, reports service and so on will be transferred into community ownership in due course. I’ve had some positive conversations with senior SmartBear executives about this before I left, and have had some reassuring signals since as well. So I’m hopeful, but we’ll see.

Still, without a significant commercial sponsor, the future of the project is uncertain right now. Would your company like to step in and help?

What are you going to do now?

Almost fifteen years since my first commit to Cucumber, I want to take some space to consider what the next chapter of my work-life will look like; to figure out what’s important.

If you’ll indulge me, I may be using this new blog to think out loud about that a little. It uses the write.as service, which I rather like so far.

I’m going to try and keep the laptop closed as much as possible for the next few weeks, but I’d love to hear from you, whether you think you have an interesting work opportunity for me, or just want to say hi.

In the short term, I’m interested in providing remote coaching to teams in and around the Pacific timezone (I’m based on BC, Canada) who want to apply skills like ensemble programming, test-driven development (TDD), domain-driven design and continuous delivery to interesting and worthwhile problems.

If you want to chat, you can reach me at @mattwynne@hachyderm.io or grab some time in my calendar.