The Big One

Posted on April 17, 2023 by Liz

The latest IPCC reports slid into existence without much fanfare from the media.

We should be used to this by now – the whole premise of the film “Don’t Look Up” is based on it – but given the starkness of the news they contained, it should have made more headlines than it did. It should still be making headlines.

The IPCC have told us that if we exceed thresholds of 1.5C warming above pre-industrial temperatures, we will begin to hit tipping points which will result in positive feedback loops.

These have already begun to happen. Some of them are quite gradual, like the ice loss in the Arctic.

Others are faster. The Amazon rainforest started putting out more CO2 than it was absorbing back in 2021. The drought that swept across Europe this year will result in a swathe of tree deaths in the years to come, just like the ones from the 2018 drought. There’s a concern now that the loss of ice sheets in Greenland could actually destabilize faults beneath, releasing methane trapped in the shallows; a far more potent greenhouse gas than CO2. (Ordinarily we wouldn’t worry too much about methane since it degrades in 8 or 9 years, but we keep putting more in, and we don’t have 8 or 9 years left to act.)

The global south suffers more than the rest of us, but we’re already suffering too. The temperature hit 40C in the UK for the first time. Wildfires broke out in south London. Trees are dying in my local park.

The number of climate-related disasters has tripled in the last 30 years.

And we know that it’s us. Humans. Not solar activity. Not volcanos. Not a natural cycle. The speed at which greenhouse gas emissions have risen is unmatched in the history of the planet.

There are things we can do as individuals (buying green energy, making sure our savings and investments aren’t funding fossil fuels, reducing our meat consumption, particularly beef – there are more).

The vast majority of emissions, though, come from industry, power and transportation, and it takes government policies changing to make the biggest impact on those.

Last year, Australia’s largest coal producer scrapped plans for a new mine. This month, France chose to ban all short-haul flights that have a rail alternative. Even in the USA, green energy is overtaking coal.

Here in the UK though, our government is still increasingly backing fossil fuels. It’s trying to open a new coal mine for steel manufacture, despite both our largest steel producers saying they don’t need it. We had to beg and cajole our Prime Minister even to get him to turn up at COP27. And they just cut taxes on internal flights.

That’s why, on Friday, I will be joining thousands of other people in and around Westminster, to protest our government’s actions and inaction in the face of disaster.

“The Big One” is being led by Extinction Rebellion UK, but other organizations are also joining in – Friends of the Earth, Greenpeace, Green Christian, Quakers, and more. It will go on all weekend, with activities, entertainment and workshops for the whole family.

If you can make it, why not join us?

If you can’t… please talk about it, post about it, make your views on the Climate Crisis heard, and help stop our precious ecosystem and our most vulnerable communities from quietly disappearing.

It’s too late to save everything, but there’s still a lot to save.

Posted in climate | Leave a comment

A Really Common Problem

Posted on March 8, 2023 by Liz

I haven’t written in a while for various reasons, and will probably post more about the climate later (being an even bigger and more important problem), but today I wanted to write about a Really Common Problem that I keep encountering in teams doing Scrum.

It’s a manifestation of the usual problem (humans like predictability) combined with certain aspects of Scrum. Experienced Scrum folk will say that it’s not really Scrum, and I think they’re right, but it is really common. If this matches your team, don’t feel bad; it’s really common, and I’m going to follow with some hints and tips that might help you. If it doesn’t, congratulations; you get to sit smug because you avoided this really common trap.

Here’s how the problem manifests:

The product owner or team lead or manager wants to know what the team are going to deliver for the next sprint, to ensure that sufficient analysis has been done on the work that the team can pick it up or to do longer-scale planning.

To do that, the stories / tickets need to be fleshed out ahead of time, with clear enough scope and acceptance criteria that they can be estimated. (Even two weeks is enough to cause the problem to manifest, but I’ve seen backlogs fleshed out like this for months ahead or even year-long projects.)

The experts who know those areas best (often tech leads, sometimes the whole team) are asked to help elaborate those tickets, so they context-switch away from the work that they were originally doing in the current sprint to go look at the work for the next one. (Some teams even add estimates at this stage.)

By the next sprint of course, some unplanned work will have disrupted things, or discoveries will have slowed us down (which they tend to do more than they speed us up), so there are often outstanding stories / tickets left over. This can sometimes be a bit depressing, especially if the team works on the principle that doing the tickets = the sprint goal = the commitment.

So the devs get hyper-focused on estimates, probably with encouragement from managers who want that all-elusive predictability. In the worst manifestations, they push back on stories that are “unclear”, because they can’t estimate them easily. Those are the stories or tickets with the highest discoveries. If you’re really unlucky, they get pushed all the way to the end of the project or release so that the discoveries are all forced when you have no time to deal with them.

Then the stories / tickets that didn’t get done are moved to the next sprint, and that probably includes some which came in from the previous sprint too. Now not only are experts being context-switched away from their existing work, but the thing that they were context-switched away to look at is rusting in their heads and might never actually get done after all.

(For bonus negative points, use JIRA’s scrum boards so that this problem is hard to see since work that isn’t assigned to the sprint doesn’t show up.)

To try and ensure that as much of the work gets done as possible, team leads or managers will make sure that the people with the right skills are assigned to the right work. This usually manifests as people signed up to the work in JIRA, before the sprint’s even started.

So now you don’t have a Scrum team focused on the goal.

You have a bunch of individual developers assigned to individual tickets, based on their existing skills; and when they have done one ticket, they move it to “Ready to Test” (or just “In Test”) and grab the next one that’s assigned to them. They don’t have a conversation with the tester, because there’s a ticket waiting for them with their name on it and they’re already behind in the sprint.

So now if someone needs their help with a different ticket, or the tester comes back with a bug, they have to context-switch yet again. Context-switching is painful for devs. It can feel hard to get any work done.

Does this seem familiar?

If so, here are some hints and tips you can try to see if it makes things better.

Is it a deadline, or a sadline? External deadlines like Christmas or a Trade Show aren’t movable, and generally business stakeholders are pragmatic about getting things working to a good level of quality in time. When nobody and no project and no opportunity is going to die, but someone will be sad, generally reputation is on the line and that pragmatism seems to go out of the window in favour of being able to mark all the stories as “done”. I encourage everyone to spread around copies of “Commitment” liberally, and to have honest conversations about what promises have actually been made, where, and what might be movable.

Plan and estimate stuff at higher levels. I like capabilities as a way of breaking down big pieces of work; someone will be able to do something they couldn’t do before, or in a new way, or in a new context. (The newness is why there’s unpredictability.) To get that working they also need to be able to do some other stuff, or some other people do. This capability level feels like about the right size of granularity to be working out what the scope looks like and how long it might take. The capabilities work well with story mapping later on, too. You can flesh out the occasional story within that ahead of time if it’s useful, especially if it’s a proof of concept or a spike that will help surface new discoveries, but try to…

Keep the analysis as close to the work being done as possible. If it takes a couple of days to get a story fleshed out, do it a couple of days before a dev is likely to be free. One team I worked with had a “trigger” – the UI dev who generally led the way on new features – who knew when they were likely to finish, and would let the team know that it was time to kick off analysis on another feature. Limiting Work In Progress can also help with this, as long as you recognize that analysis is WIP.

I reckon that before the sprint starts (or the work is picked up if you’re doing Kanban) you want enough knowledge written down to have the conversations, but not so much that you’re replacing them. Keep an eye on cards which will take a long time to analyze; otherwise leave it as late as you can. Getting hold of test data or user research are good reasons to kick off analysis early. Be pragmatic about it.

Devs are great at writing stories. Once the problem is understood, devs usually have a pretty good idea of where the greatest unknowns are, and can slice off spikes or PoCs to handle technical difficulties, then weave disparate pieces of the system together to work with reduced or hard-coded contexts and minimal outcomes, with further contexts, rules and outcomes added in later. (Even if you don’t feel like releasing an MVP, I suggest coding it first regardless.)

Devs also tend to spot when there’s work to do that doesn’t easily fit into existing stories, including “technical stories” (stories that do actually have an impact on users, but devs know what the solution is so that’s what goes in the title). This is work that you want to have visible, even if it hasn’t been estimated. The harder it is for a dev to get work added to a tracker, the more likely it is that this work will end up in a hidden backlog somewhere else… possibly in multiple developers’ heads.

Letting devs carve stories out themselves also provides autonomy; clarify the purpose and keep the analysis out of the tickets, putting it either in docs in the codebase or on your intranet. JIRA and other trackers are terrible places to store long-term knowledge. So is email.

Keep stuff in the backlog unassigned and in priority order. The goal is to pick up the highest ticket; but if the dev who’s free doesn’t have the skills to pick up at least one of the top 3, go pair with the person who does on whatever they’re working on until they become free and can pair on the new ticket. Skills will gradually spread in the team until devs can reliably pick up high priority items and the whole team is focused, together, on solving the larger problem.

Brownies think of others before themselves and do a good deed every day. Before picking up a ticket, team members can look to see if anyone else needs help. This spreads skills too; but even better, it releases devs from the habit or need to quickly pick up the next ticket, which means refactoring and documentation stands a better chance of actually being done as part of the story instead of a big catch-up afterwards.

Commit to demo. The only real commitment that gets made in most sprints (meaning it’s external to the team and can’t be changed easily) is the calendar invite to get stakeholders to see what’s been developed. It also helps developers to focus on what other stuff might need to be done to get their work in a demoable state, which might end up with them reaching out for help or helping others, which is great for sharing skills.

If you can’t release, get feedback anyway. The Scrum guide says that an increment must be usable, and ideally you have a nice, finished piece of functionality that’s been released or is releasable, but not every team is there yet, and some have constraints that make it very hard to release (high transaction costs result in large batches; if you have to drive to a customer base with an encrypted USB stick you’re not going to be doing that several times a day). So if you can’t release, find a way at least to get feedback, even if it’s showcasing from a test environment. Don’t let the “definition of done” stop you from getting feedback. You can also look at ways to release in limited contexts earlier; to friends and family or early adopters or even to your product owner – bonus if you can leave the very boring and predictable “logging in” story until last!

Also if you’re using JIRA I suggest using Kanban boards instead of Scrum boards. You can still keep a 2-week (or however long) cadence, but it makes it much easier to see all the work in progress, and to stop treating Sprints like buckets, or, as Daniel Terhorst-North once put it, “You turned a Gantt chart on its side and called it a backlog.”

Posted in business value, complexity, scrum | 2 Comments

Out of Time

Posted on August 22, 2021 by Liz

A couple of years back, I wrote about the 2018 IPCC reports.

We were, at the time and as a species, doing pretty badly at safeguarding the planet which is our only home. CO2, methane and other greenhouse gas emissions were rising. The planet was visibly warming, with a 1C rise since pre-industrial times. Media outlets gave a disproportionate amount of time to climate change skeptics, compared to the vast number of scientists who were in consensus about the human nature of our crisis, and the urgency.

We were warned, in those reports, that we needed to keep warming below 1.5C, to avoid tipping points – feedback loops that build on each other and make the problem even worse. Those tipping points can escalate the problem to an unimaginable 3 or 4C; off the charts for any of the models available at the time.

Even at lower temperatures, we were told, dramatic changes would occur. We could expect more extreme hot events (droughts and wildfires) and more precipitation (storms and floods). At higher temperatures, we could expect to see areas of the globe become uninhabitable. The ice at the poles would melt. Sea levels would rise. Patterns of climate and current would be disrupted, possibly irreversibly.

So how did we do?

There’s a bit in “Apollo 13” where things have gone horribly wrong for the astronauts. They are ordered to shut down their fuel valves. Astronaut Jim Lovell, played by Tom Hanks, looks at the others, realizing that they will no longer be able to reach the target they so fiercely, desperately wanted. “We just lost the moon,” he says.

That was how I felt reading the IPCC reports this time round.

The IPCC reports this year summarize what they think will happen over the next decades, with five different scenarios depending on how we do with our GHG (Greenhouse Gas) emissions. They describe the likely temperature rise for each of the worst scenarios, finishing with the best possible future, where GHG emissions drop quickly to very low levels:

Global warming of 1.5°C relative to 1850-1900 … more likely than not to be reached under the very low GHG emissions scenario.

In other words, there is now no scenario in which global warming does not, at best estimate, hit 1.5C.

We just lost the moon.

We didn’t just lose it for the future generations. The previous reports talked about the overall rise in terms of decades. This current report says we’ll more than likely hit that figure in 20 years. For those of us who are intending to survive that long, we lost it for us. This is happening here, right now, across the world: in Germany and Belgium where 70 people died in flooding, in the droughts and wildfires of California, Greece and Turkey, even here in London.

There is not a place left on the surface of this planet which is not affected by our way of life.

For the children of future generations, some aspects of their future are now baked-in. The sea level is rising. Arctic ice is melting. The ocean is warming and becoming more acid. Species are dying. All of these things will continue to happen.

But… it isn’t all bleak. And at least we know, so we can do something about it.

We can change, dramatically, when we have to.

The pandemic of the last 2 years has shown us that we can indeed turn on a dime; and there is support for a leaner, fairer way of living. Polls in the UK show that only 6% of the public want to return to the pre-pandemic economy. We’ve realized we can manage with less.

Electric vehicles are becoming more commonplace, and the infrastructure to support them is growing. Green energy is more widely available. Pension funds are beginning to divest from fossil fuel. More people are switching to plant-based diets (and if you haven’t, at least consider giving up beef).

The changes are good. We need more of them. The IPCC reports now suggest that we will come to equilibrium at 3C above industrial levels, no matter what we do; but they have very much more certainty about that than they did in 2018. And 3C would be appalling, even compared to the chaos that we are experiencing now.

We need to make changes.

We need to find a way to deal with the ISDS laws, which oil companies are using to sue governments introducing environmental policies.

We need to change the way we heat our homes.

We need to travel less. Consume less. Reuse more, including buildings. And stop cutting down trees.

We are out of time.

There is a third part to the IPCC report, due out next year, but it’s already been leaked. It shows that we need to see emissions peak, and then fall, by 2025, to stand any chance of staying at the lowest-impact scenario. And it is worth staying there, because if we can, then the temperature towards the end of the century begins to fall again, dropping back to 1.4C.

This is a unique moment in the history of humankind.

We are already too late to stop some of the irreversible effects of climate change, the impacts of which will affect every generation to come hereafter.

We can no longer save everything.

There is still so much left to save.

Every single fraction of a degree matters. Every tipping point we avoid is a thousand species; millions (possibly billions) of human lives; millenia less for our beautiful and fragile ecosystem to recover.

The tipping points are already happening.

The Amazon is no longer absorbing carbon, but emitting CO2.

Rain in Greenland is melting the ice sheet (which reveals darker rock and water, which absorbs more heat).

Wildfires in Siberia are releasing huge quantities of CO2, and methane is thawing from the permafrost.

The Gulf Stream current, which keeps the UK and parts of Europe warm, is showing signs of collapse.

If we do not constrain ourselves, nature will do it for us; and it will not do it fairly. We know that the impoverished Global South will bear the worst of it; but those of us in wealthier nations will suffer too.

In the last 2 years since I last wrote about the IPCC reports, our politicians have done almost nothing. The UK government has spent almost £4bn of public money on funding fossil fuels. Biden has approved a record 2,100 permits for drilling for oil and gas.

Our media focused on the IPCC reports on the day they came out. The next day, the front pages were mostly empty of anything about the greatest crisis our species has ever faced.

A friend said, “Politicians aren’t leaders. They’re followers.” They cannot afford to carry out what they perceive as unpopular acts, lest they be voted out.

Policies are often created before the actual summits that enact them. When our politicians go to COP26 in Glasgow at the end of October, we need them to see, to know, that this is what we want. That we are willing to do the hard work, pay the taxes, give up bad habits, and save the planet. Whatever it costs, it will be less than doing nothing; which will cost us everything left.

All we need is their help.

That’s why I’ll be in Trafalgar Square tomorrow morning: to renew the focus on what must be done.

Maybe I’ll see you there too.

Posted in Uncategorized | 1 Comment

5 Rules of Coaching

Posted on June 11, 2021 by Liz

These rules have nothing to do with any methodology (except maybe complexity thinking, because human.)

I have found it useful to bear these in mind while I coach. I’ve passed them on in various forms to people who are learning how to be better leaders, and suggest that leaders pass them on too.

These are contextual, which means… well, they’re not actually rules. They’re heuristics or guidelines; there are situations in which you’ll want to do something different. Having said that, they’re applicable in a lot of contexts, and they seem to be things that are easy to forget when we get stressed or low on energy.

So I call them rules because that seems to help them stick in my head better and make them my default responses to situations where context doesn’t suggest anything better. And a fair few have said that they found them useful, so… here they are.

5. Say Thank You.

This used to be “Make thank you your default response to feedback”. Sometimes when people give us information, it’s hard to hear. By making “Thank you” your default response, you can take time to decide how you feel about what you’re being told; whether you need to respond in a different way; and what you can learn from it.

We also don’t say “Thank you” enough. I spend a lot of time ranting at the TV, watching a film or a series in which one character does the other a favour, letting them know that they’ve just been rescued. The favoured character sighs. “OK.”

“Say thank you.” Nothing. “Say thank you! Why does nobody say thank you?”

It’s because we get lost in our own heads; we’re focusing on what we need to do next, and not what just happened. Saying thank you is a really quick way to amplify positives (see Rule 1) and meaning it when we say it can also help us to think of ways to amplify it, for instance by adding detail or asking for further help. “Thank you. I really appreciate that you did X. Any chance that you might have time to pass that on to the other team too? I think they could really use it.”

4. Pretend to be Brave.

Everyone gets impostor syndrome.

Everyone.

Some get it more than others; but there is always some element of doubt in our heads, some feeling that maybe we don’t really belong. The trouble is that unless you’re stuck in a rut doing the same things you’ve always done, you’re going to be doing something new; and if you’re doing something new, you’re not necessarily going to be great at it to start with.

It’s not that you’re an impostor. It’s that you’ve found a niche, and now people are expecting you to be an expert, but you’re merely knowledgeable and you’re still learning.

As the Peter Principle suggests, we tend to rise to the level of our incompetence… but that’s not actually such a bad thing, as long as we can learn fast, safely. The best way to do that is to make sure things are safe-to-fail, which usually means putting appropriate feedback loops in place. In a human system, that usually means feedback.

Getting onto the ground and listening to the stories (“gemba”) is one way for leaders to do that. Another way is to make “thank you” the default response to feedback. See Rule 5.

Respect the knowledge you do have! I’ve seen wonderful, kind people who uplift and motivate and guide others be so very mean and unkind and down on themselves. Think of the skills and knowledge you have as a sound base on which to build, and strengthen that base inside yourself. And see Rule 1.

3. Clarify Your Intent.

A leader once asked me, “How do I stop the devs from gold-plating this thing? They keep wanting to put tests around it and refactor it and I just need them to get it out there; it doesn’t matter if it’s a bit flaky?”

“Huh. I like tests and high quality code too. Is there a reason you don’t think it needs maintaining?”

“Yes; we don’t even know if it’s valuable or will be used yet.”

“Ah. It’s an experiment?”

“Yes!”

“Did you tell them it was an experiment?”

“…Oh.”

Sometimes it’s the simplest thing in the world, and we forget to do it. Clarifying why you want something allows people to make autonomous decisions about how best to work towards the outcome you want; or (even more important) give you information about the context you were unaware of that will cause difficulty getting that outcome. (Remember Rule 5 – say thank you.)

I like David L. Marquet’s “Turn the Ship Around” – one of those books that everyone talks about and you bought it and stuck it on the shelf and never got round to it. (Actually, if you bought a physical copy you’ll have seen how small it is – a very easy read – so this is mostly for the people who have it stuck in a Kindle or similar backlog somewhere.) Read it!

2. Visualize the Work.

Jabe Bloom once said of Wardley Mapping, “If there are two people in front of a map and they’re arguing with each other, it’s because there’s something missing on the map.”

Visualizing work, or the problem you’re trying to work through – putting it down somewhere where people can see it, ideally move things around, separate easy from hard and agreement from disagreement and related from unrelated can help to clarify all kinds of problems. Make it spatial; something other than a document or a list.

It doesn’t have to be on Jira or Trello or involve post-its. I like mind-maps, drawings and sketches, triads and dyads, and anything involving Cynefin. Miro and similar electronic tools are great for remote work too.

1. Amplify the Positives.

If you see something going well, call it out. Strengthen it.

When dealing with probes in complexity, we have to be able to tell what’s working and what isn’t, amplify it if it’s working and dampen it if it isn’t.

People on the ground though know better than most leaders and coaches what might be coherent, meaning there’s a sufficiency of evidence to progress, or a realistic reason for thinking things are a good idea. So they’re always trying out new probes and ideas.

I was on a project once where a couple of less experienced devs went a little astray, trying out a new tool that turned out to be a bit of a waste of time. The PM and senior BA came down on them like a ton of bricks. “Nobody is allowed to do anything without checking with us first!”

The problem with that was that the project had already spawned a ton of innovative tools (Mockito was one of them!) – and the innovation stopped overnight. We hadn’t amplified the value of that experimentation enough. The PM and BA were unaware of how much the autonomy had helped us; far more than a couple of days of development time.

It’s also far easier to spot things going wrong than going right. Learning to see the positives, and then to amplify them, is a habit that I had to actively develop. I got in trouble so many times in my coaching career for wading in and suggesting changes without first showing my appreciation of what was already working well.

Amplifying positives is the single simplest way to give feedback, help create psychological safety so that people feel free to experiment and report back their failures, and it helps to build rapport in case a more urgent intervention is required. A lot of people trying out “Radical Candour” miss this bit; it’s the part where it has to “come from a place of care”.

Above all though, amplify your own positives. You’ll fail sometimes. A sound base inside yourself and knowledge of what you can do well helps with getting back up again.

0. Breathe.

Of course there’s a Zeroth Rule of Coaching; a thing that is more important than all the others.

There will be hard days. Change is difficult, and sometimes people don’t like it. They will not be your friends. They will have bad days themselves; they will be scared, have low self-esteem, feel like their identity or power is threatened. There will be days which are frustrating. There will be impossible expectations. There will be context-switching and you’ll forget things and do things wrong and be ashamed and guilty and feel terrible.

Breathe.

I really love Katherine Kirk’s work on situational awareness and insight. One of the things she taught me is that we make poor choices when intensity is high; either because we want something desperately or because we hate or fear something awfully. We react, instead of widening our possibilities. We turn inwards, instead of nurturing our relationships and letting others help us. We see the things going wrong, and the imperfections, instead of the seeing the resources we have for innovating and improving.

Breathing is an easy, simple way to reduce intensity.

I have a particular love of Playne; a meditation game in which you bring life back to a small island where the sea gently washes against a sandy shore, while a fox gives you guidance beside a fire that represents your ongoing journey.

Breathing deeply, and taking time to do so, is the single simplest act of self-care that I can suggest for anyone, anywhere.

I’d love to say that it’s all going to be OK, that it gets better. Sometimes it doesn’t. There are pandemics, and climate crisis, and corruption, and some days the world is tangibly falling apart. There are many of us grieving loved ones, our dying ecosystem, our collapsing civilization. Life, and the prospects of our future, can be terrifying. There are many of us for whom the world is hard, and getting harder, and many of us grieve too when we cannot find a way to help.

It’s OK to stop; to take a moment for ourselves. We cannot navigate when we are blind, and intensity is blinding.

Breathe.

Posted in coaching, life, Uncategorized | 1 Comment

How Agile Manages Out Innovation

Posted on December 11, 2020 by Liz

The Oatmeal has a fantastic comic on the Backfire Effect that was so popular, they rewrote it with, um, cleaner language. It starts simply. “You’re not going to believe what I’m about to tell you.” And it goes on to talk about the emotional response that we sometimes have to people saying things that we just don’t want to hear.

I had that reaction when Dave Snowden said, “Agile manages out innovation.”

“What? Of course we don’t.” From anyone else I would have been a bit more defensive, but given Dave’s history of being right about things, I settled for just thinking he was probably wrong this time.

I thought it was just about the parallel probes.

When you’re dealing with truly complex problems, there’s no guarantee that any one experiment will work; so carrying out a bunch of them, all at the same time, is actually more useful than doing them sequentially. Complex, cultural problems aren’t physics; the landscape is going to change anyway, and eliminating side-effects isn’t as important as finding ones which happen to work in your favour.

Of course, most of us aren’t running experiments in parallel. We have one product we’re working on, and we’re iterating towards a final solution, knowing vaguely what we want to achieve and getting feedback along the way. It’s very rare that we don’t have some idea of what we ought to be doing.

Agile doesn’t actually prevent us from running parallel probes, though. I once worked in a mixed dev/coach role writing a new trading platform. It wasn’t entirely an Agile project. They’d brought in some UI designers before-hand, who had carefully researched, then created, the design of the UI they wanted. Back then I already knew that if it was new, it was likely to be full of discoveries, so I hard-coded it and got it in front of the traders, who hated it.

Of course, being not entirely an Agile project, our UI designers had gone on to pastures new, so we were left with the terrible position of having to let the developers come up with the design.

Three of us, independently, came up with something we thought might work. The traders quite liked two of the solutions (or at least, they talked about what was wrong with them rather than why they were wrong, which was much better), so we kept those and made them work together, iterating to fix everything. But we did work in parallel for a bit, and it fitted nicely into our Sprint.

I couldn’t help feeling that I’d missed something, though. Dave didn’t just say that we tend not to be innovative; he said we actively manage out innovation. It took me a while to work out what was wrong.

It’s our focus on customers that holds us back.

Stop. Hold on. What? How can that possibly be the wrong thing to do?

It’s such an important part of Agile that it’s right there in the first principle:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

– The Agile Manifesto

The Kanban body of knowledge isn’t any better, either; all the Lean principles from which it derives are also very customer-focused, with the value stream being measured from when the customer need is discovered to when value is realized.

But how could that possibly be the wrong thing to do?

The most innovative companies aren’t just satisfying their existing customers.

Amazon doesn’t just sell books. Google doesn’t just do search. Netflix doesn’t just stream content. John Menzies, once the darling newsagent of high streets, now does airport logistics. Nintendo once made playing cards. Even Toyota started as a loom manufacturer.

At smaller scales, huge number of inventions are no longer driven by their original intent. Kleenex was originally made to take off make-up. The Slinky was meant for stabilizing ship instruments. Microwaves were discovered while messing with radar. And a monk called Dom Pierre Perignon was once tasked with removing the unwanted fizz from the wine.

All of these have something in common: they repurposed something they already had.

This is exaptation; the re-use of things for purposes for which they were not designed or evolved.

A lot of these discoveries and inventions have happened by chance… but what if there was a way to deliberately cause this kind of innovation?

This is what Dave calls “Managing for Serendipity”.

I’m pretty new to the entire field, so worth looking for his material on it rather than trusting me. In basic terms, though, it means looking to repurpose what you already have, to satisfy new varieties of customers.

Cognitive Edge use Sensemaker surveys to look for patterns in customer need and existing technology, but even introducing different kinds of experts from outside of your core domain to what you do can help to generate new ideas (these are the “oblique” probes in your probe portfolio).

IBM repurposed sewing machine punch-card technology for use in computing. Amazon repurposed their back-end and sold it as a product; AWS. Edin Berliner repurposed Edison’s telephone message recorder and invented the music industry. So many inventions are there, waiting to be discovered… unless we fall into that “first-fit pattern-matching” trap, and focus only on the one customer we already have.

“Innovation” comes from the Latin “to introduce as new”. If you’re being truly innovative, it’s the customers that are new, too.

Posted in complexity, cynefin | 9 Comments

Constraints and Cynefin

Posted on December 9, 2019 by Liz

A short reminder of Cynefin and the difference between domains:

  • Obvious situations can be categorized and have fixed constraints.
  • Complicated situations can be analyzed and have governing constraints.
  • Complex situations can be probed (trying something out that’s safe-to-fail) and have enabling constraints.
  • Chaotic situations require you to act, and have no constraints.

The fixed constraints of the obvious are easy to understand. Think of putting a plug into the wall. There’s really only one way to do it, and it’s very hard to get it wrong!

Chaos is caused by a lack of constraints; meeting constraints will cause it to dissipate. Think of fire burning until it runs out of fuel or oxygen. This is what makes Chaos transient and short-lived; it will rapidly grow until it meets constraints, at which point the situation resolves (but not necessarily in your favour).

Robust constraints

In complicated situations, the governing constraints provide limits to what can be done. In terms of our policies and processes, these are hard-and-fast rules. They are context-free, which means they apply to everything, regardless of context.

In one of his later articles on constraints Dave Snowden refers to governing and fixed as robust constraints, which survive by becoming stronger and which, when they fail, do so catastrophically. Think of things which snap, shatter, or result in someone being immediately fired.

Resilient constraints

Enabling constraints, though, are contextual. That means that they can be adapted or escaped for context. In policy and process terms, they’re guidelines or heuristics. Dave uses the analogy of a salt marsh, as opposed to a sea-wall; the water is contained, but can gradually permeate the marsh.

Enabling constraints are resilient. That means that when they break, you usually get a bit of warning, or the impact is small to start with.

Coupling (connecting) and Containing constraints

Resilient and robust constraints can both be either connecting or containing. A connecting constraint is one which holds things in place without limiting them; a tether or an attractor. A containing constraint keeps things in one place without centering them; limiting or guiding them.

Disorder and Constraints

Disorder often occurs accidentally when we’re using the wrong kind of constraints for the situation.

For instance, think of the difficulty of getting innovative work done when you’re at a highly regulated big bank with all of its processes, its governance and change control!

Or alternatively, think of what happens when you fail to obey the safety notices or read the instructions, treating something as if it’s safe-to-fail when it isn’t.

Using the wrong kind of constraints – treating something complex as if it’s complicated, or vice-versa – is a form of disorder, and when disorder persists, it usually results in chaos.

Creating Probes around Constraints

Wicked, complex problems are often hard to solve directly, and they’re usually made up of combinations of human behaviour, and the constraints within and around which we act, whether complex or complicated.

By looking at the ecosystem of constraints – all the processes in place, and all the rules and guidelines and legacy that help us or hinder us – we can consider whether relaxing or tightening constraints might produce a beneficial outcome. That relaxing or tightening can become a probe.

In complex ecosystems, especially human ones, be careful! Dark constraints – things which cannot be seen, but the effects of which can be felt – are often cultural, and changing things can cause unexpected side-effects. Remember to check that it really is safe-to-fail!

Posted in cynefin | 2 Comments

A Probe by Any Other Name

Posted on November 20, 2019 by Liz

In complexity (new stuff is complex) we prefer to probe; which means to try something out that’s safe-to-fail.

Knowing things are failing or succeeding relies on feedback loops; but who do we get feedback from? And what do we do with it?

There are a few different terms for different kinds of probes in the industry, so I’m writing down my thoughts here about each kind, from the PoV of someone in the development team. These aren’t hard-and-fast rules; if you have different naming conventions that’s probably OK.

Spike – demonstrates to us (the team) that something is possible.

Prototype – demonstrates to someone else that something is possible.

Alpha – gets feedback from real users / customers on value. Fix showstoppers; keep track of other bugs.

Beta – gets feedback on readiness to release. Fix bugs.

Release – provides value, even if in a limited context. Fix bugs urgently.

One of the most common problems I see is a mismatch between what the team, the PO, the business and other stakeholders all think people are working on.

Chris Matts explained a phenomenon to me called “signalling intent”. It’s what happens when you intend to explore or open up an option, but instead you accidentally communicate a commitment.

For instance, let’s say you work in a very casual office. Shorts and flip-flops are the norm. You get a call from an engineer at Avogadro Corp (side-note: read this book; it’s really good). It seems like it might be a fun conversation; even if you aren’t looking to jump ship, it would be a shame to waste the chance to find out more. So you turn up in the morning dressed smartly, ready for your meeting in the afternoon.

But your team-mates and managers have noticed. They think you’re going for an interview. Your lightweight probe is interpreted as a commitment; they think you’re about to jump ship. Their behaviour changes as a result.

When a perfectly lightweight probe is miscommunicated as a firm investment or commitment, people start aligning around it (positively or negatively) until it becomes the only option available. At that point it’s no longer safe-to-fail.

So if you’re thinking of trying out a probe, consider how you’re going to communicate it, both internally and externally, to the team, or to the leaders, or to the customers.

And if you are a leader, consider how you’re asking for the probe in the first place. If it’s an experiment you want, tell your people. Clarify your intent about the level of feedback you’re looking for, and the extent of the commitment you’re willing to make, in time or money or social capital, however small.

The alternative is disorder, and the inevitable chaos that results.

 

Posted in cynefin, feedback, real options, Uncategorized | 3 Comments

Scenarios using custom DSLs

Posted on August 27, 2019 by Liz

One of my clients recently asked me how often I use Cucumber or JBehave in my own projects. Hardly ever, is the answer, so I want to show you what I do instead.

The English-language Gherkin syntax is hard to refactor. The tools form another layer of abstraction and maintenance on top of your usual code. There’s a learning curve that comes with them that can be a bit tricky. The only reason to use the tools is because you want to collaborate with non-technical stakeholders. If nobody outside your team is reading your scenarios after automation, then you don’t need them.

There may still be other reasons you want the tools. They’ll be more readable than the code I’m about to show you. Dynamic languages are harder to refactor anyway; I work primarily with static typing. Maybe you want to take advantage of hooks for your build pipeline. Maybe you already know and feel comfortable with the tools. Maybe you just really want to learn the technique. That’s OK. But you don’t need them.

So here’s a simple alternative.

Have some conversations, and write down the examples.

I like it when the developers do this, and get feedback on their understanding. Writing it in semi-formal Gherkin syntax is pretty useful for helping spot missing contexts and outcomes. All the usual goodness of Three Amigos conversations still applies.

Find a capability, and the thing that implements it.

Your application or system probably has a number of things that it enables people or other systems to do. We’re going to be using a noun that matches those things as a way of starting our DSL. Here are some examples:

  • Buying things -> the basket
  • Making trades -> a trade
  • Commenting on an article -> a comment / the comments
  • Doing banking -> the account

You may find the language is a bit stilted here (I did say the English was clearer!) but that’s a trade-off for the ease of getting started with this. You might find other things which make more sense to you; it’s sometimes possible to use verbs for instance.

  • Searching for a car -> I search

You’ll get the idea in a moment. Each of these is going to be the stem of a bit of code.

Start with comments in the code

Sometimes I like to just start with my scenario written in comments in the code. For each step, think about whether the step has already happened, is the thing that triggers some interesting behaviour, or is the outcome of that behaviour. Add Given, When or Then as appropriate:

    // Given an article on Climate Change
    // When I post a comment "This is a really conservative forecast."
    // Then it should appear beneath the article.

Add the Given, When or Then to your stem, and…

  • Given the basket…
  • When the trade…
  • When a comment…
  • When a search…
  • Then the account…

…construct your steps!

Now we’re in code.

GivenAnArticle().on("Climate Change")

GivenTheBasket().contains("Pack of Grey Towels")

WhenTheTrade().isCreated()
    .withCounterparty("Evil Corp")
    .forPrice(150.35, "USD")
    .....
    .andSubmitted()

WhenISearch().For("Blue Ford Fiesta")

ThenTheAccount().shouldHaveBalance(15.00, "GBP")

You can see that trading one is using a builder pattern; each step returns the trade being constructed for further changes, until it’s submitted. I sometimes like to use boring, valid defaults in my builder so that these steps only call out the really interesting bits.

I normally suggest that a “When” should be in active voice; that is, it should show who did it. If that’s important, add the actor.

WhenTheTrade().isCreated()
    .....
    .andSubmittedBy("Andy Admin")

or

WhenTheTrade().isCreated()
    .by("Andy Admin")
    .....
    .andSubmitted()

Active voice would normally look more like:

When("Andy Admin").createsATrade()
    ....
    .andSubmitsIt()

But now our “When” is ambiguous; we can’t tell which kind of capability we’re about to use, so it makes it really, really hard to maintain. It’s OK to use passive voice for DSLs.

As I construct these, I delete the comments.

Sometimes I like to just put all the detailed automation in which makes the steps run, then remove the duplication by refactoring into these steps. (Sometimes it’s enough just to just leave it with detailed automation, too, but at least leave the comments in!)

Pass the steps through to Page Objects; use the World for state

You’ll probably find you need to share state between the different steps. I normally create a “World” object, accessible from the whole scenario.

Each of the stems you created will correspond to one or more page objects. I like to keep those separate, so my steps in the DSL don’t do anything more than just call through to that object and return it.

Here’s an example of my scenario object for a Sudoku solver:

public class Scenario
{
        private readonly SudoqueSteps _sudoqueSteps;
        private readonly CellSteps _cellSteps;
        private readonly HelpSteps _helpSteps;

        private World _world;

        protected Scenario()
        {
            _world = new World();
            _sudoqueSteps = new SudoqueSteps(_world);
            _cellSteps = new CellSteps(_world);
            _helpSteps = new HelpSteps(_world);
        }
        
        protected CellSteps WhenISelectACell{ get { return _cellSteps; }}

        protected CellSteps ThenTheCell{ get { return _cellSteps; }}

        protected SudoqueSteps GivenSudoque{ get { return _sudoqueSteps; }}
        
        //...

        protected HelpSteps WhenIAskForHelp { get { return _helpSteps; } }

        protected HelpSteps ThenTheHintText { get { return _helpSteps; } }
}

It does get quite long, but it’s pretty easy to maintain because it doesn’t do anything else; all the complexity is in those underlying steps.

And here’s how I use it:

    [TestFixture]
    public class PlayerCanSetUpAPuzzle : Scenario
    {
        [Test]
        public void APlayerCanSetUpAPuzzle()
        {
            GivenSudoque.IsRunning();
            WhenISelectACell.At(3, 4).AndToggle(1);
            ThenSudoque.ShouldLookLike(
                "... ... ..." + NL +
                "... ... ..." + NL +
                "... ... ..." + NL +
                "           " + NL +
                "... ... ..." + NL +
                ".1. ... ..." + NL +
                "... ... ..." + NL +
                "           " + NL +
                "... ... ..." + NL +
                "... ... ..." + NL +
                "... ... ..." + NL);
        }
    }

Full scenarios here.

This one was written in plain old NUnit with C#. I’ve done this with JUnit and Java, and with JUnit and Kotlin. The examples here are only from toy projects, but I’ve used this technique on several real ones.

There are lots of tools out there which help you to construct these kind of DSLs; but I’ve found they also come with their own learning curve, constraints, maintainability issues etc.. This is a pretty easy thing to do; I don’t think it needs anything more complicated than I’ve put here.

It’s also very easy to refactor overly-detailed, imperative scenarios, of the kind created by lots of teams who didn’t know about the conversations, into this form.

It’s easy to move to the BDD tools if you need them.

With your Page Objects already in place, it’s pretty quick to get something like Cucumber up and running and make the step definitions call through to the page objects exactly as you were before, with just a little bit of refactoring of method names.

It’s a lot harder to move from Cucumber and regex to a DSL.

Chris Matts once had some great wisdom. “If you don’t know which technology to choose, pick the one that’s easy to change. If it’s wrong, you can change it.”

This is the one that’s easy to change, so I tend to start with this. And sometimes it doesn’t need to change.

 

 

Posted in bdd | 13 Comments

Off the Charts

Posted on July 2, 2019 by Liz

If you’re following me on Twitter, you’ll have noticed that the amount I’m talking about the environment and climate change has ramped up recently. I want to explain why, and why this is probably the most important blog post I’ve ever written.

For GOTO Amsterdam, the organizers asked if I could talk about the 4th Industrial Revolution (I may write a blog post on that later). While I’m familiar with the concepts in the 4th (possibly actually the 6th) IR, I needed to know a little bit more about the history of Industrial Revolutions in general to make a good talk. So a few months ago, I started researching.

Iron and steam. Steel forges and railways and ocean-going ships. Electricity and telephones and computing and the technology age that we now currently enjoy. Movement and machinery and connectivity. The automation that started with the textile mills of the UK has spread world-wide.

It all needs power. Lots and lots of power. Those of us in the tech industry use a hell of a lot of it; in our work, our play, and our travel. Our computers and the internet require power. Those hot laptops and graphics cards are evidence of how much power we use. The aircon that keeps our offices cool. Our cars, our flights, the industry that makes our phones and tablets and all the other tech…

It all needs power.

So I started researching the effects of that power.

I hadn’t actually read the IPCC’s report before. There’s a summary of it for policymakers that’s a bit long.

Until this year, I figured the policymakers had probably read it. They had to be working on something that was appropriate for the urgency, right? But the Extinction Rebellion movement keeps growing… is it just people panicking over nothing, or is that sense of urgency really justified? Does Greta Thunberg, the 16-year-old who’s spoken most passionately about her own future, really mean it when she talks about the collapse of civilization as we know it?

Well, the IPCC’s got some nice pictures to make it easy for us. Here’s two of them. They’re on page 11 of that summary I’ve already linked.

IPCC report: How the level of global warming affects impacts and/or risks associated with the Reasons for Concern (RFCs) and selected natural, managed and human systems

So this is why they’re asking us to stay below 1.5C.

I thought 1.5C might be, you know, kind of OK. But it turns out even at 1.5C we’re destabilizing the arctic (bye-bye, polar bears), probably the Western Antarctic ice sheet, losing most of the warm-water corals with their rich ecosystem, turning some places into famine-stricken deserts, and flooding others. You know, more than they already are. You can see the grey bar representing 2006-2015 on that chart.

1.5C turns out to be… still pretty bad.

At 2.0C, as well as the effects being horribly red-looking across the board, we’re entering that place where the feedback cycles start kicking in. You know, more than they already are. Here’s a picture from ClimateVictory.org that shows the basics of what that looks like.

So we’d really, really like to stay below 1.5C if we can, because 2.0C is not looking good. 2.0C is looking, well, pretty devastating.

So how are we doing?

Here’s the Independent’s report, based on a number of existing models. I’m just going to quote it, because there’s a key phrase in there, and the fact that it exists is ridiculous.

Based on lack of meaningful global action to rapidly extinguish all greenhouse gas emissions within the next decade, the authors sketch out a scenario in which global emissions peak in 2030.

In this case, using several existing studies, they hypothesise average global temperatures may reach 3C above pre-industrial levels by 2050.

Scroll back up. Can you see 3C on those charts?

I think that’s the point where scientists just throw their hands up and beg everyone to grow the f&*$ up. Actually, that’s Bill Nye doing that, right there. And you can hear everyone laughing, because Bill Nye swearing is incongruous with his normally family-friendly presentation and incongruity makes us laugh, but it isn’t funny. It isn’t funny at all.

3C is off-the-charts catastrophic.

And we’re looking at 5C by the end of the century, at least. 5C’s unimaginable. At 5C and above, things start to get apocalyptic. If it isn’t an existential threat for humans entirely then it will certainly, as Greta Thunberg says, be the end of civilization as we know it. António Guterres, the Secretary-General of the UN, said this week that “We are in a battle for our lives.”

What does that look like?

We’ve already started to see it. It looks like Chennai, India’s 6th biggest city, running out of water. It looks like police using tear-gas on peaceful protesters, in a country where the temperature hit 45C this week. It looks like animals going extinct, at a rate that’s faster than anything since the meteor impact wiped out the dinosaurs. It looks like insects disappearing and the failure of ecosystems world-wide that results.

It looks like that, only more, and worse, everywhere. Oh, and the sea-level rise will cause storm-surges (which will be more frequent) to flood most coastal cities, and probably London too.

So what do we do?

1. Change your personal priorities.

Most of us who are environmentally-minded are used to thinking, “How can we live our life the way we want, and still be kind to the world?”

We need to change this round. “How can we be kind to the world, and still live our life the way we want?”

That means doing whatever you can, even if it makes you uncomfortable. Take the train instead of flying. If you have to fly, carbon-offset your flights. Carbon-offset everything. This site by fellow coach Henrik Kniberg and friends, GoClimateNeutral.org, makes it easy.

A zero-carbon world doesn’t have to be an awful one. The more we invest in it, the more the infrastructure around it changes to support it, and the easier and cheaper it gets… and the more normal it gets, until hopefully the outliers are shamed into joining the rest of us.

2. Make a difference, or support people making a difference.

Join the protests. If you can’t join the protests, fund the protests. If you can’t fund the protests, facilitate a workshop for them or help out with a website or even just offer a bit of moral support. (Shout-out to Sal Freudenberg for her inspiration; she will have even more suggestions.)

Plant a tree. Change providers. Use green electricity. Get an electric car. Or better yet, a bicycle. Switch to the Ecosia search tool. Don’t like my suggestions? Great! Make better ones.

3. Make a noise.

Do not go gently into that good night. It won’t be good, and it won’t be gentle, and by the time that starts to make itself felt in your life, it will probably be too late. Shout about it. Those of us in technology are more connected than anyone else. Shout about the products making a difference. Shout about the awesome people doing good things.

But most of all, shout about the urgency. Shout about how we need to do something now.

They say the best time to plant an oak tree was 20 years ago, but the second best time to plant it is now. It’s already too late to save everything.

Let’s save what we can.

Posted in life | 5 Comments

On Multiple Givens, Whens and Thens

Posted on May 6, 2019 by Liz

I wrote this as a reply to user RHarris’s question on StackOverflow, but thought it might be easier to find here too. The login scenario and the access record here are adapted from their question.

What contexts should we include in a scenario?

Scenario 1: A user signs in with valid credentials

Given the Sign In page is displayed
When the user enters a username and password
And the user submits the request
Then the user should be directed to the Home page

I find it helps to think of scenarios not as tests, but as living documentation that helps to illustrate how the system behaves and why that’s valuable.

If you can tell that the user isn’t locked out and isn’t disabled in that first scenario, then you don’t need to include those steps.

For something like logging in with an active, enabled account this is obvious, but it might not be for something like a trader staying within their trading limits, or a fetal heartbeat running at a healthy rate, or a comment that hasn’t yet reached the reporting threshold. You can decide whether to include those kind of contexts pragmatically.

I prefer though to move documentation that doesn’t change or doesn’t change very often, like core domain concepts, outside of the scenarios. Perhaps it can be at the blurb at the top of the scenario file, or on a team wiki somewhere that new joiners get to read before they code. It doesn’t have to be in the scenario.

(Obviously you would need to include the contexts which cause the failure in any failure scenario though!)

What about side-effects and other outcomes?

...
Then the user should be directed to the Home page
And the logs should record their access.

All outcomes that matter do so because at some point, they become visible or have effects beyond the system whose behaviour is covered in the scenario.

For instance, when I get money from a cash machine, my account is also debited. I might not see that as part of the behaviour, but it does have to happen. That’s because there’s another stakeholder involved in the scenario – the bank.

Or perhaps, when Fred gets a refund on his microwave, the microwave is put back into stock and the stock count is incremented. Fred, the till operator and the stock controller are all stakeholders here.

In the case where we’re adding something to the logs, there’s a stakeholder who’s going to use those logs for something else. Having an awareness of that value can help us work out why we’re logging, and describe that outcome from the POV of the stakeholder who finds it valuable.

If the outcomes can be shipped independently and still be valuable, they can appear in separate scenarios. I’m pretty pragmatic about this, so I might put them in the same scenario to start with, then refactor them out later once the number of “stock control” scenarios means that it should probably have its own feature files.

If the outcomes can’t be shipped independently, which is usually the case with anything transactional, I like to see those outcomes appear together in at least one scenario, to make it obvious that they’re related. They don’t have to appear in every scenario. For instance, once we’ve written the scenario where the user doesn’t have funds so their account doesn’t get debited, we probably don’t have to mention the account again in any other cash withdrawal failure scenarios.

This perspective of multiple stakeholders is also related to the BDD concept of “Outside-In”, where all the behaviour we add to the system is done to provide a value to some stakeholder through some interface.

What about interactions with other users or with time?

Sometimes – very occasionally – we need more than one when to describe what’s happening, and the example of a login counter being incremented is a great one to use.

The value of a login counter is only that it disables the account after 3 attempts (for instance). It has no value in and of itself. It’s an implementation detail. If we made this into an outcome in a scenario, we’d be coupling ourselves to that implementation, which wouldn’t be great. So having two scenarios – one to describe how the login counter works and one to show why it’s valuable – doesn’t feel right since one of them isn’t describing valuable behaviour:

Given Clarence logged in successfully last time
When Clarence enters his password incorrectly
Then the login counter should be incremented.

Given Clarence's login counter was incremented twice
When Clarence enters his password incorrectly
Then his account should be disabled.

Yuk. Let’s not do that.

The only value in that counter is from the interaction of Clarence’s behaviour with Clarence’s future (or past) behaviour. So we could have something like:

Given Clarence logged in successfully last time
When he enters his password incorrectly
And enters his password incorrectly
And enters his password incorrectly
Then his account should be disabled.

Of course, that’s a bit of a mouthful, so we’d probably just say:

Given Clarence logged in successfully last time
When he enters his password incorrectly 3 times
Then his account should be disabled.

We can do that because it’s the same thing happening. Some interactions though involve different things happening (“time passing” is another one I frequently encounter).

Given Clare is editing trade 12345
When Stephen edits and saves that trade
And Clare tries to save that trade
Then she should be told that Stephen has already edited it.

In this case of course Clare’s interaction is different to Stephen’s, since her attempt to save fails.

Note the use of tries here to indicate failure; another example of how I use assumptions. If it doesn’t say tries we can assume that the event was successful. The alternative would be:

When Clare saves the trade successfully

Unless a successful outcome is somehow surprising and not the norm, this would get a bit repetitive, so I prefer to use nothing for the default and tries for failure. Having a difference between them is important from an automation perspective since it lets us do things like move the automated workflow to an error page instead of the confirmation page.

It also reads quite nicely. Which is pretty much why we’re trying to use these English language tools anyway.

Posted in bdd, stakeholders | 5 Comments