On Multiple Givens, Whens and Thens

Posted on May 6, 2019 by

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 | 2 Comments

How to run a Futurespective

Posted on September 12, 2018 by

Futurespectives, like Retrospectives, look back at the past… from the future!

I find them very useful when there isn’t much to retrospect on: at the start of a project or initiative. I’ve run them for myself, for other individuals, and for groups of up to a hundred individuals, so it’s pretty flexible.

In a futurespective, we imagine that we’re in the future, and we look back to the past. Here’s the quick outline of what I do:

  • Set the scene and create a timeline
  • No explicit safety check (use common sense)
  • Step forward into the future
  • Look back at the past negatively (skip to positive if short on time)
  • State interrupt – break the mood!
  • Step forward into the future again
  • Look back at the past positively
  • Dot-vote
  • Create actions.

There’s some notes at the end too.

Set the scene

Imagine that the thing you’ve started has reached some kind of conclusion.

How long did that take? It could be the first project release, or the first time the team move onto something new, or the first time someone realizes that what they were trying to do has worked (or not).

I like to ask the people in the room, but if they don’t have experience, I’ll use mine or refer to other people’s. Futurespectives work well when the timeline is of the order of months or years (though I’ve done them with just days before!)

When we’ve decided what boundary of time we’re going to use, make post-its for any known or proposed events like release dates, deadlines, etc.. Tangential events which help people to imagine where they are in time are also useful, like the office Christmas party, or the rough date a team-member’s baby is due, or the start of school summer holidays.

The team can add any events they know of to this timeline.

No explicit safety check (use common sense)

Most of the time when I run this session, it’s because something highly uncertain is about to happen, often with people who aren’t used to working together. Asking whether people feel safe to share their opinions is less useful than encouraging them to be creative… particularly in the “negative” run-through!

Make sure you position the “negative” run-through as something of a ritual, so that people feel safe to make suggestions. I tell people that if the worst thing that happens is that a meteor hits the building, then that’s what happens.

Step forward into the future

I ask people to stand up and gather in a group at the start of the timeline, then walk with me as we progress through to the future. I talk about things that are happening as we move; any events that are occurring, the changes in the season, and events like Hallowe’en or that late blast of sunshine that we always get at the end of September; anything which reaches out to the imagination.

At the end of the timeline, we turn and look back.

Most of the times I’ve done this, there hasn’t really been enough room for everyone to traverse the whole timeline from start to finish; they get to shuffle along a little bit behind you while you lead the way. Remember to move past the end so that you give the group as much space as possible! The most important thing is that they aren’t standing where they started, and have moved to somewhere else.

This means that when they look back on the timeline, they will be able to correlate that movement more easily with the shift in time as well, helping them to imagine what happens next (or before).

Look back at the past negatively (skip to positive if short on time)

I like to make the first run-through the negative one, because then we end on a positive note. This one can also be quite funny.

I tell them, “Look back on the previous years / months since <date>. Wasn’t that just the most awful time you’ve ever had, ever? Everything went wrong.” Then I describe all the symptoms of it going wrong – people quitting, blaming each other, stealing the milk… whatever you can think of. I talk about my own role, too, with phrases like, “nobody is even speaking to that consultant you hired back in January!” or “that facilitator just didn’t help at all!”

I encourage people to be absolutely outrageous – in one organization Boris Johnson became the company Chairman; another large national company was reduced to less than 100 staff members because of the high turnover; quotes from “Office Space” and other parodies get scattered around liberally.

The outrageous ideas provide a container in which people can post dangerous ideas; things that might actually be a bit likely, but which would be taboo to suggest in a serious manner. We don’t ever discuss the negative things, so this is OK. Lots of elephants may emerge in the room. We’ll deal with them positively, later.

Ideas go onto post-its and those go up on the board. Ask your attendees to put any continuous events at the point at which they first noticed them happening.

I like to use pink post-its for bad things (and green or yellow for good things later), but I also put them below a particular line, leaving space between the negative ideas and the timeline above it for positive ideas (or you could have the timeline in the middle if you can make it visible enough).

As a guide for the space to leave, the positive ideas should be at or slightly above eye-level, and we normally use 1 or 2 feet (30 to 60 cm) of wall-space for each run-through, depending on how many people are involved and how long we can make the timeline in the space available.

State interrupt – break the mood!

I ask people something like, “Who’s a cat person here, and who’s a dog person?” or, “What’s your favourite film?” I often ask them why they think I asked that question, and they usually guess correctly that it’s to break the sad mood of the previous run.

Step forward into the future again

We repeat the previous walk-through, gathering at the beginning and walking back through to the future, with the same events (which is why the timeline should be of proposed or known events rather than imagined ones).

Look back at the past positively

I tell them, “Look back on the previous years / months since <date>. Wasn’t that just amazing? Look at all the awesome stuff that happened! All those risks we identified back in <this month>… none of them materialized. We managed to mitigate or minimize every single one! So many good things have happened! So many wonderful things! So what are they? What happened?”

Ask attendees to put the ideas onto post-its, and put them on the wall once more.

Dot-vote

De-dupe any of the positive events, moving them to the earlier dates if possible.

Ask the attendees to dot-vote on the events that are “most important, and least likely to happen without intervention”.

There are important events that will happen anyway, and unimportant events that people can work around. We want the events that are most risky; the things that really need to happen, but perhaps haven’t been started yet because people don’t know how.

These are often things that will only happen when people learn by trying them, so getting started is the important thing to do. This just gets people started.

Note that some of these may be the elephants in the room, but we’ve turned them into positive outcomes (see also Mike Burrows’ / Agendashift’s 15-minute FOTO if you want another excellent way to do this!)

Create actions

If anyone can make a difference to the events, or try something out which might help with them, they can volunteer for actions.

It’s highly likely that some of the events require sponsorship, authority or assistance from people outside the room. If you as a coach or consultant are in a position to help with those, you can go ahead and take the actions yourself.

Otherwise, ask if people know who to talk to. The action to take is then at least to have a conversation with that person.

Don’t create actions for people who aren’t in the room or don’t want to own them! That’s a really great way to waste post-it notes.

Notes

As long as some of the actions get taken up, and a bit of change happens, the futurespective was worth it. Change creates a new context, in which change has already been successful, which can make future changes easier and more likely to be attempted. In those situations the actions should be safe-to-fail probes. Simple conversations ought to be safe-to-fail (and if they weren’t, that’s useful information to have anyway).

It’s often the case that the red post-its pile up at the end of the timeline, while the green ones are clustered near the beginning; we need to act now to prevent problems later. If that happens, it’s worth drawing attention to it.

I sometimes get asked if we’re going to talk about the red ones. I explain that they’re only there to generate the green ones, but that if they want to, they can create a green one that’s an exact negative (“Boris Johnson does not become our chairman!”) and we can vote on that and talk about how to make sure it happens.

(In that positive timeline, he actually emigrated to Australia. I liked the imaginative creativity of that group very much.)

 

 

Posted in Uncategorized | 3 Comments

Probably not

Posted on July 28, 2018 by

When working in complexity, where the right thing to do emerges and we learn by actually trying things rather than by analysis, there’s a very human instinct that happens when we think of probes to try out. I see it all the time when I teach Cynefin, and I sometimes catch myself doing it (which means I fail to catch myself doing it a lot; welcome to bias).

I see people think of perfectly lovely, lightweight probes. “Let’s try using Slack.” “We could set up a visual board…” “Let’s try talking to the Ops team.” “It looks like a simple fix, and we can back it out easily if it fails.”

The urge that kicks in is then to take these lovely lightweight probes, which are perfectly safe-to-fail, and add stuff to them to give them a better chance of working.

“Slack? Fantastic; I’ll need the list of everyone to add to it, and I’ll set up these fifteen channels, and we’ll have a launch party in two weeks to encourage people to join…”

“A visual board? We should copy it into JIRA as well, and make a key of what colour post-its to use and here’s all the information that we need to put on them…”

“Our Ops team? Let me set up a meeting with our senior stakeholders and third-party suppliers so we can talk through what we need…”

“Release? You’ll have to work with the other teams and join the release schedule we’ve already set…”

The trouble is, these speculative investments of time, money or effort can mean that the probe is that much less safe-to-fail. Communicating a probe without being really clear that it’s just trying something out can result in communicating intent, leading others to create commitments around it, cementing it in place. The sunk-cost fallacy kicks in. “What do you mean, it’s not working? We spent two weeks on that…” The more people it reaches, the greater the impact and the need for success.

Having an awareness of this tendency has helped me to ramp it back. Instead of trying for something that will probably work, think about keeping it lightweight, so that if it doesn’t, it’s easy to fix or reverse or dampen in other ways. We’re aiming for things that might possibly work, or even plausibly work (I saw a figure from Ozzie Yüce that suggests only 1 in 3000 new ideas are actually successful). Keep it simple, small, or cheap, or short, or even hacked-into-place if that’s something you’re good at.

(Probes don’t have to be simple, small, cheap, or short, but I’ve found those are pretty good heuristics to work with.)

Resist the urge to double down by surrounding the probe with expensive scaffolding to prevent the failure. If it seems like it might not work, try to find ways instead to make it safe-to-fail. Those options that you make available for handling failure will work with other probes, too. (Automated rollback, for instance, makes all kinds of production releases safer, allowing all the teams involved to try things out more easily.)

And if you hear someone else’s ideas, please also resist the urge to tell them all the reasons you can think of that mean it’s going to fail, unless it really isn’t safe to do so (or your feedback has been explicitly invited).

In the complicated domain, things will work as predicted; in complexity, probably not so much. And that’s OK.

Posted in cynefin, real options | 1 Comment

Me too.

Posted on October 17, 2017 by

I don’t need to write a post about sexual harassment in the workplace. I already wrote one, 12 years ago.

Reading it back, I was struck by the paragraph I wrote about blurred lines.

I tried to remember what I was like, back then. I remember having chronically low self-esteem and a feeling of utter worthlessness. I valued every positive interaction that validated me in some way, even if it was borderline inappropriate.

I was in, then escaped, an abusive relationship at the time, but given I’m pretty bright and seem to be good at tech… why didn’t I feel like that was where my worth lay? Why was work also contributing, when it should have been uplifting me? I loved programming. I was demonstrably good at it. Why did I feel like playing into the expectations was the only way I could get ahead?

Oh, I remember.

Being told by a visiting professional in my A-level electronics group that I was “only there to hold the breadboard”. The lab partner who thought women should defer to men and couldn’t understand my behaviour. The students who tried to look up my skirt. The anonymous emails telling me how beautiful I was walking out of my lecture, describing my movements for some days. (Idiot got caught; it was sent from a university terminal.)

Then, at work.

The worst thing.

The guy who decided I was his wife, and referred to me as “wife” for about 6 months, even when our manager told him to stop (nothing else was done about it and I didn’t feel like I had any power). It still makes my skin crawl. I remember crying, a lot, thinking about the fact that I had to go to work again the next day. That was the worst thing.  Having someone think they own you. Being worried, every day, about what else was going to happen. Feeling sick. Watching other people watch it happen and knowing they saw me powerless and afraid and frustrated and angry. That remains, many years later, the worst thing.

Worse than being groped in the street in broad daylight in Bath. Worse than being followed home through Camden. Worse than the guy who decided to lift my skirt up in Slimelight to see what was underneath (and got thrown out by the bouncers). Worse than the guy who tried to put his hand in my top in Bristol (no bouncers needed; I chased him out myself).

It’s always worse when it’s work. We don’t have to go to clubs. We don’t have to go out late at night alone. We do have to work, and there’s no escape. It’s worse at work, but this one was worse than all the others.

Worse than the swimsuit calendar on the wall with the swimsuits made only of body-paint.

Worse than the high-level exec who stroked my hair in the pub as I passed.

Worse than watching 7 women be made redundant out of 10 redundancies for “performance reasons”, in a company with only 10% female staff. (I performed well enough, apparently.)

Worse than being asked if I only got the job because I was a woman.

Worse than being quizzed repeatedly about gender diversity issues, just because I’m a woman. (My favourite: “Liz, what’s difference is there between a team with women in and a team without them?” “How would I know? I’ve never been on a team without a woman in.” “Really? How come?” Duh.)

Worse than having to tell someone with a topless woman on his t-shirt – at work – that it was making some of us feel uncomfortable.

Worse than being asked why I was out at a conference, and shouldn’t I be home raising the kids I choose not to have, because how else could any man find any value in me?

Worse than the tweet that said I only won a prize because someone was “stung by gender diversity issues and trying to redress the balance”.

Worse than having someone tell the crowd at the bar that “I’d better cover up my pint, otherwise Liz might want to drop rohypnol in it.” (This comment was freakishly out of the blue, I promise. We had no history of intimacy. We had no CoC either. He doubled-down when I told him it wasn’t funny. I have no idea why his head went there. It scares me more than a little. I try to avoid speaking to him these days.)

Worse than a long-term mentor telling me that I should “have more empathy” for that guy.

Worse than having someone touch my ass at the conference bar (kudos to the LASCOT conference organizers for the sensitive handling of that one; CoCs rock).

Worse than all the other things.

It was a long time ago, that worst thing.

I keep thinking that maybe I’m lucky it wasn’t worse.

I keep thinking that maybe one day I’ll be old enough that it will stop happening to me.

I keep thinking that maybe the world will be better, and it will stop happening to anyone.

12 years later, it hasn’t stopped.

Maybe I need to write a post after all.

Posted in life | 15 Comments

On Real Options and Speculative Investments

Posted on September 8, 2017 by

If you’ve read the awesome graphic novel, “Commitment”, you’ll know the rules of Real Options already:

  • Options have value
  • Options expire
  • Never commit early unless you know why.

There’s an additional rule which is sometimes added to this:

  • Options have more value as uncertainty rises.

…and software development is full of uncertainty.

We do want to make commitments; also investments, which are the subject of this blog. Failure to act is itself a decision, and at some point options do expire. As David J. Anderson says, “If you leave it long enough, eventually everything becomes an expedite.” The problem comes when the commitments are premature, and the investments speculative. So this post is about minimizing speculative investments, and avoiding premature commitments altogether.

An option is the right, but not the obligation, to do something or get something.

Chris Matts took the term “Real Options” from financial options, for which we can easily assign value; the right to buy cocoa beans at a certain price right before Christmas so that your chocolate factory can meet its own commitments to provide chocolate Santas to its customers, for instance. If cocoa beans are cheaper than the option price, we don’t need to use the option. If they’re more expensive, we exercise the option and we get our beans affordably.

In real life, options are harder to value. They’re just choices. However, they have value, and we as human beings tend to exercise our options way before we need to. We have an innate dislike of uncertainty. Our confirmation bias serves to make us think we have certainty and understand the patterns we see, even when we don’t. That’s great for helping us move forward in an uncertain world… but if we could move forward in a way that kept two directions open for us, cheaply, why wouldn’t we?

The other problem I’ve encountered is that we don’t actually commit a lot of the time. Instead, we make heavy, and speculative, investments.

A speculative investment is risky.

In finance, a speculative investment is one which may entail a significant degree of loss, and which by its nature is uncertain. I’m talking about real-life investments, which might be of time or effort or willpower or social capital. The term “speculative” also means “based on conjecture, rather than knowledge.” Like premature commitments, a speculative investment is one made in an absence of good information.

So what’s the difference between a commitment and an investment?

Commitments are discrete; investments are continuous.

Let’s say you’re skiing, and the lift is broken. You plod up the mountain with your skiis, investing in the ride down. At some point you realise the slope is a bit steeper than you thought, and not a good match for your ability. You decide you’ve invested enough, and put your skiis on, and off you go. Only the effort you’ve spent is committed; you haven’t made any future commitments. The decision is a continuous one, and can be changed at any point, dampening future consequences. If it’s a bit too steep for you you might feel a bit uncomfortable and you’ve still got a chance of crashing, but at least you were able to stop when you did.

A commitment is jumping out of a plane. If your parachute doesn’t work, you can’t change your mind half-way down and decide you’ve had enough. The future consequences are unavoidable.

I think of investments like a slope of expired options against time, with the steeper slopes being heavier investments, and commitments being a vertical line. Sometimes investments can turn into vertical lines, like the V1 point at which a pilot is pretty much committed to taking off from the runway and can’t abort. Sometimes they can be unwound, but the unwinding can be painful, like plodding all the way back down the mountainside.

Investments in software development prove really interesting, particularly because of two human biases: confirmation bias, and the sunk-cost fallacy.

Together, they lead us to commit to the direction set by speculative investments, thinking that we have certainty and good information when we don’t; and to build on the investments we’ve already made, even if we do have information that they’re wrong. Sometimes the commitment is just a mental block. Sometimes we communicate it to others, creating reputational or contractual commitments. Sometimes we tie other decisions to the investment, making it a far heavier investment than it was before, until it’s practically a vertical line anyway.

Here are some common examples of speculative investments that I see in software development, and some ways of improving your process by making that investment smaller and lighter and less likely to invite commitment.

Research, analysis and design done a long time ahead of the actual development. (Yes, two weeks is a long time.) Prototype as soon as you can, especially if the solution is technically complex. Use the prototype for guerrilla testing. Keep your options open by having several different designs (concurrent set-based engineering, or in Cynefin-speak, parallel probes). Don’t worry about bits of the design which are easy to change; fonts and colours and spacing and even layout can be sorted out later. Bonus points to designers who can sit with the devs and help them tweak the final bits… especially if it means you learn a bit of code yourselves.

Backlogs that require grooming. This is another sign of speculative investment in the form of analysis. I find planning at the capability level is a good level of granularity at which to stop. Put them on cards or post-its and stick them on a wall somewhere. A big one-year trading project had about 37 cards. The projects I work on now are typically a few months long and have ten cards or so. Let the team break them down as they come to them. Focus on the riskiest ones that the team know least about, too, so that you can make discoveries and get the information for good decisions early. And minimize the work you’re looking at! If you don’t need it, don’t put it on the wall until you’ve done the stuff you need (and often, discovered what that really is). Everything else is an option, and options have value.

Yearly budgeting cycles. Most organizations do have a process for changing direction mid-year, but it’s painful. The cost of unwinding heavy investments often is. Bjarte Bogsness’s work on Beyond Budgeting is excellent for separating the different concerns of budgets like resource allocation and motivation and prioritisation, providing more flexibility, as well as being beautifully alliterative. Budgeting for half a year or quarterly lets you change direction more frequently. Concepts like BHAGs, True North and the One Metric That Matters (OMTM) can help departments to align, letting them make decisions locally, enabling greater trust and more autonomy for spending the money you’re giving them.

Leaving testing to the end. Doing this at the end of a project is going to hurt you badly, but even leaving testing to the end of a sprint means you’ve got two weeks of speculative investment of code. Devs, if you’ve got something working on your machine, and your tester is co-located, go and get them so they can see it. Chances are you’ve forgotten something. (Chances are good you’ll remember it as you’re walking across the room.)

Big releases without the possibility of rolling back… or without the information that tells you that you need to. Actually, this is a commitment rather than an investment, since you’ve got no choice but to enjoy the freefall. I heard of one company that had to cease online trading for months afterwards… or there’s Knight Capitol Group, which, well, it doesn’t exist any more. Don’t do big-bang releases with no rollback, unless you’re really sure that you’ve eliminated uncertainty or opened some options for yourselves through other means. (If this is the norm for you, you probably don’t have those techniques either. Start learning, because your competitors do.)

It’s all about investments and commitments.

These are just a few examples of speculative investments that I see in software and the wider organization, from code to corporate strategy. We’ll always have some level of speculative investment, because we need to move forwards and uncertainty always exists, but it doesn’t need to be heavy. Minimizing speculative investment is a principle which scales.

I’ve realised that just about every aspect of my job as a Lean / Agile coach and consultant is about minimizing these speculative investments and avoiding premature commitments; encouraging people to keep options open by creating safety (organizational, technological and psychological), minimizing queues and feedback loops and embracing the riskiest and most uncertain work so that information for making better decisions arrives earlier, helping people limit the work in progress with that “stop starting, start finishing” mantra so that the investments already in flight pay out or give us feedback earlier, clarifying direction to allow for swift and autonomous changing of decisions, and helping people communicate and visualize with greater transparency.

Everything decision we make, we do with the information we have. We often make the wrong decisions, and more so when we don’t have good information. Unless there’s something urgent going on (because chaos is often what happens when you make premature commitments), we want our investments in uncertainty to be probes; a Cynefin term which means trying something out that’s safe-to-fail, with feedback on whether it’s succeeding or failing and mechanisms for amplifying it or dampening it accordingly.

With investments, being wrong less doesn’t have to mean being right. It can mean being wrong with less money, in smaller contexts, for less time, with less stuff and fewer people.

That’s how we keep our most important option open: the option to do something else instead.

Posted in cynefin, real options | 1 Comment

Reflecting Reality

Posted on August 31, 2017 by

One of the things I often do as a coach is help people to set up their visual boards, whether physical or electronic. Sometimes that can be surprisingly hard for teams to do without a bit of guidance, so I wanted to provide some hints and tips for getting a board up and running, fast. A lot of these have come from the world of Kanban, and I think they really help with small, continuous improvements.

My most important hint of all:

Make your board reflect reality.

If reality is ugly, your board will be ugly. If you have lots of places where work passes from one role to another, your board will have lots of phases too. If you have work piling up in one area like “Ready for Dev” or “In QA”, your board will have a lot of work in that phase.

Do not hide it. I see a lot of teams aiming for some kind of Agile ideal, and when the work doesn’t match the ideal, sometimes they think, “Well, we shouldn’t really be doing it, then.” And so, they hide the work, and things end up dropping through the cracks as a result. Sure, maybe the team shouldn’t be working on five things at once. If you are, though, put it on the board. The first stage to fixing a problem is admitting that you have a problem!

Once when I was working as a dev, I was told not to put any work on the board without going through my team lead, who was often away. That resulted in each dev keeping a little file of stuff that we knew needed to be done. Our lead was very surprised to find that we weren’t confident about meeting the sadline*… and even more surprised by the amount of work still left to do to go live. We’d love to have a small backlog and be releasing every week, but if that isn’t possible, put it on the board.

Change the board.

If you find that your board doesn’t reflect reality, or that you’re having to adopt processes that feel wrong because of the board, change the board. If you’re using a technology that isn’t adaptable to change, change the technology. Your tools are there to support your work, not the other way round.

I love physical boards because they’re so easy to change, and you can tweak them together until you get a result you like.

Keep your metrics.

Most of the teams I work with actually have two: one physical, and one electronic. Often one of those is nominated as the “master”; usually the electronic one. If you only have a physical board, though, or your physical is the master, when you move a card, put the name of the phase / column and the date you moved it on the back.

This is invaluable in seeing how and whether the team is improving, and in making forecasts about when you’re going to be finished, so you can manage things like stakeholder expectations and marketing and cross-programme dependencies.

Make process policies explicit.

Often teams have a really organic process, which means that sometimes when things get a bit crazy, as they always do, bits of that process get missed and fall away. By adding a simple checklist for moving into each column, we remind ourselves of the other people involved in delivering our work, and have a better chance of delivering it well.

You can have different policies for different types of work. Just make it explicit. Scrum practitioners often agree on a definition of “done”**, but I like having this definition for each phase-change. Bonus points if the policy involves talking to someone else and showing them what you did rather than just ticking boxes.

If we have a physical board, the policy might just be a little bit of paper at the top of each column with reminders on it.

Add all types of work, including improvements.

If the team are involved in something, and it’s taking their time and energy and focus, put it on the board. I tend to differentiate between customer/stakeholder-facing work that needs to be done, technical tasks where the customer is future-you or another dev team member, information-gathering activities like spikes, and improvements of the kind that often come out of retrospectives.

It isn’t totally necessary to put improvements on your board, and a lot of teams are successful without doing that, but the teams which I see continually improving tend to have those tasks listed visibly somewhere. The improvements might go outside of your team, so it’s OK to put “please deliver a talk on your ways of working to the XYZ community” on the board. Flag it up as a different kind of ticket if you need to filter them out for some reason. “Improvement” is a ticket type in JIRA; get your admin to add it.

Visualize (small) queues, and limit your work in progress.

I’ve seen a lot of boards called “kanban board” that weren’t actually pull-systems. “Kanban” comes from Lean manufacturing systems like Toyota’s. It means a signal card, and it’s a way of making sure that the inventory in the system (i.e.: the work in progress) is a good match for the throughput capacity.

That means, for instance, that if your tester is regularly overloaded, you won’t be able to go faster than your tester. By putting WIP limits on your tester’s column, you create a signal (a space in that column) that your tester has room for more work. If the tester doesn’t have room, you know that rather than overloading the WIP limits, the right thing to do is to go help the tester. Or, if you can’t, read a book! Or do something small and interruptible, so that when the tester comes back with feedback, the work is still relatively fresh and the knowledge hasn’t rusted in the rest of the teams’ heads.

This way of working may not be productive, but it is more effective. Knowledge rusts way faster than cars.

We expect that in knowledge work, we’ll get a lot more variance in terms of how long things take than Toyota does in its factories. Because of that variance, and because human beings are capable of more than one skill (unlike factory machines), our constraints will sometimes shift. We want to keep the work flowing, which means that we never want the constraint to run out. So, we want small queues of work before the constraint.

If you want to start putting WIP limits somewhere, put them wherever work seems to get “stuck”. That’s your constraint.

As a note, there’s a pretty typical journey I see with teams adopting WIP limits for the first time:

  1. they ignore them completely
  2. they violate them reluctantly
  3. they fight to stay inside them.

At each of these stages, we have another conversation about why WIP limits will help. Coaching takes patience.

Stop Starting, Start Finishing.

If you don’t feel like your team is ready to start putting WIP limits in place, this litttle principle (from David J. Anderson) will help to get the mindset in place. Before starting work, look to see if there’s any way to help finish other work that’s ongoing.

That might be as simple as offering to get your tester a cup of tea!

Another way to start doing this is called “Walking the board”. In the stand-up, rather than just going round each person, look at the cards starting from the ones closest to release, then working through each phase towards the new work to be pulled in (normally right-to-left). Ask what’s needed to help finish it, and if anyone else could do that or learn that skill.

People will naturally start learning each other’s skills, becoming T-shaped, with narrow expertise but general ability to help out in the basics elsewhere.

Autonomy, Mastery and Purpose.

As Dan Pink says in his book / talk, “Drive”, this is how people in creative spaces are motivated. These ideas should help you provide your teams with the ability to change their own ways of working, in context; with slack as the constraint moves around to pick up new, related skills and to deepen and improve their own; and with a renewed sense of purpose driven by meeting genuine customer need, quickly and effectively.

Who knew visualisation could be so much fun?

*Sometimes no person or project or opportunity dies as a result of missing a date. If nothing’s going to die, it’s not a deadline. Often it’s just someone’s reputation at stake, and missing the date means that someone will be sad. People tend to be surprisingly pragmatic with real deadlines in a way that they’re not with sadlines. Humans are weird.

**You’re not really “done” until the software has been retired and is no longer used at all. Make your board reflect reality. Call it what it really is, whether that’s “ready for integration” or “ready for release” or “in production”. Remember that there are other people still using, maintaining and updating that software, and be nice to your IT Ops teams.

Posted in kanban, lean | 2 Comments

A Helping Hand

Posted on July 18, 2017 by

This week, Sallyann Freudenberg and Katherine Kirk have been running a small summit on inclusive collaboration and neurodiversity – not just focused on diversity in our experiences, but in the very make-up of our brain.

Sallyann suggested there was a little test that could be taken to discover if we ourselves have any autistic tendencies. I wasn’t surprised to find that I register on the threshold. I remember the years spent entirely alone at junior school, without worrying about any need for friends; losing myself in raindrops trickling down the windows; the rich visual stuff in my head (doesn’t everyone think like that? Apparently not, says Sallyann.)

I spot patterns not because I think about them a lot but because I associate visual and kinesthetic experiences. Cynefin isn’t just made up of obvious and complicated and complex and chaotic things; it’s stuff that’s hard and doesn’t budge; that fits together and clicks and is a bit greasy like cogs; that’s organic and smells peaty and crawls and climbs and shifts like plasticine; that’s on fire. When I feel the same way about something in life or work, I know instinctively what it is I’m looking at, which is why I think the framework made sense to me. Knowing how my head works has made a big difference.

In the last couple of years I’ve also lost much of my hearing. I’ve always been a bit deaf in the bass, but NHS hearing aids back when I was a child were big, clunky things that amplified the air con more than anything. Now I’ve lost more hearing still, so I need them. NHS hearing aids these days are tiny, but apparently my ear canals are narrow, and even in “extra-small” size the little gadgets hurt a bit to put in. Still, I can hear. It’s a blessing… and also incredibly tiring and draining. Paying attention to people is hard, though I have to, if I want to make a difference to the world.

So, when they told me that we’d be assembling hands for children who’d lost theirs, in complete silence, I felt calm and happy. No more straining to hear people. No more asking them to repeat themselves. Silence, my friend for a long time, would be keeping me company alongside my team-mates.

Then we started work.

First, we were missing the instructions. Oops! Are we meant to assemble this without them? I wondered. But no, they’d mentioned instructions… oh, Gitte put up her hand, so she’s on it.

We read through. I happened to sit in the middle, between Gitte and Aaron. A bad idea… I always tend to dominate these kinds of activities, with or without speaking. I tried hard to make sure that I was giving the others a chance to participate and not just doing all myself, but at one point Gitte started writing on a post-it. Katherine had suggested we do that, for things that we were thinking, or wanted to say.

What’s she writing? I thought. Is it about me? Did I do something wrong? Am I being too dominant again? Wow, that’s really paranoid. Seriously.

They seem to know what they’re doing. Why aren’t they doing it? They should pick up the fingers, the pins, the cogs. I want to. I’ll just hold them and let them take them; is that still dominating? They aren’t moving. Are they waiting for me? Do they want me to lead? I can do that, but it’s not a good idea; I should let one of them have a go.

It’s a lot like Lego. It’s easy. Do they think it’s easy? Am I being arrogant? I studied engineering; maybe it’s easier for me… no, they have it, look. Yep, that’s me being arrogant again; I’m not the only one who knows how to do this. Might want to remember some humility next time, Liz, teach you to think you know better.

And on.

And on.

I wanted silence, but I didn’t have it. I had too many thoughts, instead. Too many things that I wanted to say… not to my team-mates, but to myself.

The others started the day with meditation (which I don’t enjoy; a long story which I won’t tell here) but I don’t often get the chance to really talk to myself about what I’m thinking… let alone to listen. Self-hypnosis is similar, and I do practice it, but not as often as perhaps I should. I do freewriting sometimes, too, and it felt a bit like that, listening to my own running commentary inside my head.

There was only one thing I really wanted to say: hush. Be quiet. It’s OK.

At some point I think my head started to listen. It was all right that I didn’t know where a piece went, or what it was that Gitte wrote this time. It was all right that we made a bit of noise when we used my empty coffee cup as a hammer, and I didn’t need to worry about what the other teams thought. After a while, my thoughts stopped chattering and started getting to work. I started paying attention to what the others wanted, instead of what I wanted… and I moved seats so that Gitte was in the middle.

These days I’m generally good at being quiet around others. The WAIT acronym – Why Am I Talking? – is often at the forefront of my mind. Being quiet around myself, though, so that I can actually hear what other people are saying, and not just with my ears… that’s my new quest.

Somewhere, this year, a child will be getting a hand that they need.

I think I found something I was missing, too.

Posted in cynefin, learning, life | 1 Comment