Elizabeth Keogh

One of the biggest problems I encounter with BDD is that it was started by developers, for developers, so that we could get a better grip on what it was we were developing.

As we began to understand the complexities of what we were developing, conversations with business stakeholders started to become more fluid. We started to understand what it was like to handle multiple stakeholders; to have uncertainty around requirements where stakeholders weren’t really sure about the outcomes they wanted; to pay to delay decisions about implementation until later.

There are three practices / principles / bodies of knowledge and experience which I use and teach as part of BDD, and I don’t think BDD works well without them. Good BDDers have taught these practices anyway, sometimes without giving them a name, so I wanted to call them out explicitly so you know that they’re there and can use their names to go find out more.

This is the stuff that happens in conversation, before developers get anywhere near a keyboard.

Feature Injection

A large number of Agile projects have backlogs of user stories. Some of these backlogs can be quite large. One team had over a year’s worth of stories, covering four walls of a room. Scrum and other Agile practitioners talk about “grooming the backlog”; reacting to their growing understanding of the real problem by removing some stories and adding more in. Even Agile teams can be sidetracked by “quick” two-week-long analysis phases, or two-hour planning sessions, or additional functionality that still fits within their deadline when they could have shipped three weeks ago.

What if you didn’t have to do this?

Lean proponents talk about minimum viable products or increments, in which we determine the smallest thing that could make a difference to the problem, then do the minimum necessary to ship. Feature Injection, introduced to me by Chris Matts, is a fantastic technique for discovering that minimum. Here’s how it works.

• Every project worth pursuing has a vision - either something new, or something that you’ve seen someone else do and you want to do it too. The vision is designed to increase revenue, decrease costs or protect revenue – for instance, keeping customers from going to a competitor (note that there’s no ROI for a vision like that!)
• There may be other stakeholders whose goals need to be met in order to allow the vision to go live. Frequently these stakeholders have traditionally gatekeeping roles – UAT, Architecture, Legal, Security. By recognizing these stakeholders early, we get a chance to turn them into educators instead.
• To meet the stakeholder’s goals, we create capabilities. For instance, employees might need the capability to book a holiday. Notice that they could quite easily do that with paper! To make our differentiating vision compelling, we may need a certain amount of commoditised functionality – things that people will expect in that kind of application. When David Anderson talks about differentiators he uses the mobile phone market. An example of a differentiator is the first ever camera in a phone. We’ll also need to be able to make calls, receive calls, look up numbers, etc.
• To deliver the capabilities, we design features. We may decide that some features are too complex, and create manual workarounds instead. The features represent the way in which users will use the capabilities we’re giving them – through a browser, a windows client, a mobile phone, etc. Now we’re starting to move into the areas of UI design, preferably with a UI designer, and developers and testers can really get involved if they weren’t already! Even if the development team wasn’t involved in the conversations before this point, I recommend they should be aware of the outcomes and able to map their features back into the capabilities, stakeholder goals and initial vision. Even better, the team might only have the capabilities on their backlog – breaking them down into features as and when they reach the next capability (see Deliberate Discovery for prioritisation).
• To really explore the features, we talk through scenarios; examples of the outcomes a system should produce when a user uses it in different contexts. We can use the scenarios to decide what we want to get feedback on, and thus divide the features into stories. The main purpose of dividing things into stories is to be able to get feedback quickly.

Scenarios are the BDD artifacts people are most familiar with, but look how much happens before we even get this far! And that’s without budget negotiations, portfolio management, company strategy, recruitment and all the other gubbins needed to get a development team up and running…

• After that, we can move into the traditional development space – TDD (or unit-level BDD if you prefer), code, integration and, we hope, production.

Deliberate Discovery

In Agile projects, we normally prioritise stories by their value. But wait a moment! If we’re doing Feature Injection, our vision is for the smallest valuable thing we could ship (otherwise, that smaller thing would be our minimum viable product). So we can’t really say that one feature is more valuable than another, because we need them all (and if we don’t, that’s our minimum viable product!).

What we can say, though, is that we know more about some of the features than others. Commoditised features, particularly, will have been done before, and we can probably estimate them and make predictions about them, as long as we have enough expertise in the domain. Anything that’s new, or that’s new to the team, we’ll know less about. We can bet that there are some things in there that we’ll discover as we code, some of which will come back to bite us. These are the kind of things which can really derail a project.

In the spirit of failing fast, we’d really like to have our projects derailed early, while we can still change our minds and perhaps think of something else to do instead. Deliberate discovery is the act of assuming ignorance, then going to look for it and optimizing to address it first. There will always be things we don’t know we don’t know – but since those things will usually show up in the functionality we’ve not delivered before, why don’t we do the new stuff first?

If you’re into Theory of Constraints, you know that in a production line environment, you tailor your system to the constraining machine, putting it first where possible. But software development is more like product development; it’s creative knowledge work, rather than doing the same thing over and over again. Ignorance is the constraint.

This is how we prioritise – by the features and capabilities about which we’re most ignorant. It helps us to address the risk early. Since the risky stuff is usually what keeps our stakeholders awake at night, this is a great way of establishing trust, too.

Real Options

As well as the things we don’t know, there will also be things we don’t know that we don’t know. No amount of analysis will ever allow us to discover everything! So we have to keep ourselves ready to change.

Unfortunately, we human beings don’t work well with uncertainty, and have a tendency to try and eliminate it. One of the ways we do that is to break down problems into their components. That works very well for predictable stuff that we’ve done before, but not for new things which we don’t understand so well. Doing this for new functionality only leads to the uncertainty being hidden away!

So what can we do to keep our options open, so that our ignorant ignorance doesn’t bite us?

Chris Matts took the concept of trading options – the right, but not the obligation to buy copper at $1000 a tonne in October, for instance – and worked out which aspects of options still apply to Real Life. Here are his principles:

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

With Deliberate Discovery, we’re getting what information we can before we make a larger commitment, so Deliberate Discovery plays into this very nicely. There’s another thing we can do, though. We can pay to keep our options open. This is what we do when we take time out to design our code well or refactor it so that it’s understandable. We’re creating options for the future.

When we talk through our scenarios and we see our P.O. frowning or saying, “Um…” then we know there’s uncertainty there. It might be worth spiking out a feature cheaply, to see if it does the job, before pinning that feature down with automation (or even, dare I say, unit tests). Discovering that uncertainty and ignorance is at the heart of BDD – not finding the examples, but finding the examples we can’t find.

Another practice Chris taught me off the back of this is, “Don’t pick the right technology. Pick the technology that’s easy to change.” Whenever we have a choice and not enough information to help us make the decision, picking a decision that’s cheap to change later usually turns out to be a good way forward, as we can change when we have more information (or keep it if it turns out to be good enough!)

BDD is just TDD?

Sure, if you’re a developer, and you only get to see the stuff that happens in development. Even then, it may be worth talking through not just the scenarios, but the larger-scale picture; discovering uncertainty and ignorance, paying to keep options open, and working towards a clear and compelling vision to deliver software that’s not only well-tested and functional, but which really, truly matters.

In this post, I’ve focused on the differences between BDD and TDD, most of which have been spawned by the language of BDD which allows for more appreciation of uncertainty than the language of TDD. For the similarities, and more about the history of how BDD was originally derived from TDD, see this article.

Originally published at Liz Keogh's blog. Please leave any comments there.

Since there are a few debates going on (again!) about whether BDD is just TDD done well, I thought it might be interesting to showcase some examples where BDD language made a difference to people’s understanding.

From StackOverflow, TDD – Should Private/Protected methods be under unit test?:

Original Poster wrote:

In TDD development, the first thing you typically do is to create your interface and then begin writing your unit tests against that interface. As you progress through the TDD process you would end-up creating a class that implements the interface and then at some point your unit test would pass.

I wrote: Please let me rephrase this in BDD language:

When describing why a class is valuable and how it behaves, the first thing you typically do is to create an example of how to use the class, often via its interface*. As you add desired behavior you end up creating a class which provides that value, and then at some point your example works.

*May be an actual Interface or simply the accessible API of the class, eg: Ruby doesn’t have interfaces.

This is why you don’t test private methods – because a test is an example of how to use the class, and you can’t actually use them.

Response: Brilliant post. Clarifies a lot.

From StackOverflow, should i only be testing public interfaces in BDD (in general, and specifically in ruby) (sic):

I wrote:

Instead of writing a test, you’re going to write an example of how you can use your class (and you can’t use it except through public methods). You’re going to show why your class is valuable to other classes. You’re defining the scope of your class’s responsibilities, while showing (through mocks) what responsibilities are delegated elsewhere.

At the same time, you can question whether the responsibilities are appropriate, and tune the methods on your class to be as intuitively usable as possible. You’re looking for code which is easy to understand and use, rather than code which is easy to write.

If you can think in terms of examples and providing value through behaviour, you’ll create code that’s easy to use, with examples and descriptions that other people can follow. You’ll make your code safe and easy to change. If you think about testing, you’ll pin it down so that nobody can break it. You’ll make it hard to change.

Response: good answer! very concise!

From comments on my blog post, “Translating TDD to BDD”:

Ben asked: Given this terminology, can you reword these sentences to eliminate the TDD terminology, but in such a way that someone who doesn’t know what BDD is can understand it?

Writing the tests first ensures that the code we write to make them pass is actually testable. Otherwise, we may wind up with classes and methods that, although fairly well designed, are not easily tested

I replied:

Writing examples of how to use the code, before we write the code that makes those examples work, ensures that the code we write is easy to use and understand. Otherwise, we may wind up with code that, although adhering to SOLID principles, has been written to be easy to write rather than easy to use or maintain.

(Of course, if you’re doing true outside-in then you already have one example of how to use a piece of code, from its consuming class. I reworded this from ‘well-designed’ to ‘adhering to SOLID principles’, since they’re necessary for good design but IMHO not sufficient.)

Ben responded: Liz, that’s beautiful. I especially like how you phrased your points about use and maintenance. Takes the focus off “testing” and puts it on something that’s more directly tied to value.

Taking it up a level, again from StackOverflow, Are BDD tests acceptance tests?

BDD “tests” exist at multiple different levels of granularity, all the way up to the initial project vision. Most people know about the scenarios. A few people remember that BDD started off with the word “should” as a replacement for JUnit’s “test” – as a replacement for TDD. The reason I put “tests” in quotes is because BDD isn’t really about testing; it’s focused on finding the places where there’s a lack or mismatch of understanding.

Because of that focus, the conversations are much more important than the BDD tools.

Acceptance testing doesn’t actually mandate the conversations, and usually works from the assumption that the tests you’re writing are the right tests. In BDD we assume that we don’t know what we’re doing (and probably don’t know that we don’t know). This is why we use things like “Given, When, Then” – so that we can have conversations around the scenarios and / or unit-level examples.

We don’t call them “acceptance tests” because you can’t ask a business person “Please help me with my acceptance test”. Try “I’d like to talk to you about the scenario where…” instead. Or, “Can you give me an example?” Either of these are good. Calling them “Acceptance tests” starts making people think that you’re actually doing testing, which would imply that you know what you’re doing and just want to make sure you’ve done it. At that point, conversations tend to focus on how quickly you can get the wrong thing out, instead of about the fact you’re getting out the wrong thing.

Response: 20 upvotes and a “nice answer” badge!

These are just a few instances of using BDD’s language instead of TDD’s. I’ve found it even more powerful in spoken language, and more powerful still when talking to business-focused stakeholders about examples of how we might use a system to deliver the value they want. I taught BDD to my dad once, showing him how to write examples in Java in order to ensure that his code would be usable and maintainable. After we’d written a couple of classes, I said, “Of course, this also gives you a nice set of regression tests.”

“Oh, yes!” he said, “So it does. I hadn’t thought of that.”

Originally published at Liz Keogh's blog. Please leave any comments there.

A lot of times when I go to conferences, I’ve already got a slew of half-formed ideas and thoughts from the amazing communities with whom I hang out. The conferences have been fantastic for helping me refine and validate those ideas, but it’s been a while since I’ve come across anything genuinely new.

LSSC 2012 was very, very different – challenging a ton of sacred cows, trashing some long-held ideas and giving me a bunch of new thoughts and understanding. The format was perfect: seemingly flawless organisation; amazing speakers, including some that we wouldn’t have heard if we weren’t in Boston; a Lean Camp unconference where I actually felt panic at not being able to attend all the sessions; long breaks giving us plenty of time to talk, network, reflect and synthesize ideas; innovative sponsors whose presence added value; lightning and ignite talks with hours of brilliance compacted into small spaces of time (thanks for letting me rant instead!); great venue, food and service and of course the fantastic mix of attendees.

Here are some of the joyous nuggets that I learnt and the people from whom I learnt them, paraphrased for your quick enjoyment.

Hillel Glazer: Demand pulls most of us to start projects, but it only really works when it pulls us to finish them and produce something. For that, we need to work on capacity. David Joyce echoed Hillel’s sentiments in his talk when he told us to stop disbanding teams right when they’re at their most productive. That’s part of the problem.

Steven Spear: If you can’t make predictions, you lose your ability to be surprised, which means you can’t learn. This spawned a Twitter conversation with Karl Scotland and others about complexity and whether expectations apply in the complex space, which helped me with my ignite talk. I really love Karl’s take – that we should at least predict impact if not outcome. Steven was talking about nuclear reactors, which I hope are a little more predictable than the software we produce.

David Anderson: It turns out that the community is doing more than just software these days, so the Lean Software Systems Consortium has rebranded as the Lean Systems Society. It’s modelled on the Royal Society, and I’m honoured to be named as a fellow. Particularly interesting was David’s comment that they’d observed the behaviours and values of the community, and drawn up their Credo or value statement accordingly – not the other way round! Talk about making process policies explicit…

Michael Kennedy: From TPS – “Product development is not about developing cars, it is about developing knowledge about cars.” Michael showed how sharing knowledge across projects can help us to build quality in. He showed how Toyota explore new ideas, resolving complexity while developing expertise before using them in production, which falls right into place alongside some of the Cynefin conversations that have been happening in the UK, as well as Dan North’s call for Deliberate (as opposed to accidental) Discovery. One excellent quote: “They’re only standards because they’re the best we can do right now. Engineers are expected to break the standards. Managers decide which standards they want to be broken.”

Gregory Howell: It turns out that the construction metaphor we’ve been using in IT doesn’t even work out in construction! One study found that 85% of construction managers had underestimated the complexity of the project. Pushing people to go faster isn’t as useful as working on the interfaces between people. The stories he told mostly centred on slowing things down and increasing quality and fluidity of hand-offs in order to go faster.

Robert Charette: All exchanges of goods and services are exchanges of risks and opportunity. Robert used the example of a plumber who’s taken on risk by investing in his own skills. He has an interesting model for risk and particularly market share, and challenged us to think about the kind of things which might end up bringing a company as successful as Apple down.

Jim Benson: If you have a repetitive task, record the metrics for how it went each time on your kanban board. Jim was talking in terms of Personal Kanban, but I can see how that could be useful for eg: retrospectives. Already added the “exercise” column to mine! Jim also taught one table at the Brickell Key awards that if you play buzzword drinking games with the Lean & Kanban crowd, you’re going to get what you measure… dangerous stuff. Congratulations to both Brickell Key winners, Jim and Arne Roock.

Mike Burrows: Limit WIP in portfolio too. Mike also suggests limiting the amount of money carried in the portfolio, allowing you to have a few big projects or several small ones. Richard Hensley apparently thinks a similar way. Karl Scotland shared another of Mike’s suggestions: limit dots in progress. Put dots on the cards every day they’re in progress and you’ll be able to see the flow very clearly.

Karl Scotland and Larry Maccherone: Our data is really dirty. If you start using 2-sigma thresholds to make SLAs, you’ll probably get stung. It doesn’t follow a normal distribution, in part because developers simply don’t update the statuses on time – they’re too busy doing the work! Outliers are also interesting. Rally has some neat tools to show you where your percentiles really are, but they’re in competition with Lean Kit’s lounge with its hot dogs and ice-cream. Lean Kit definitely win the prize for brand awareness this trip.

Yochai Benkler: This was the most mind-blowing talk for me. It turns out that our desire to collaborate is partly genetic, and only prevalent in 60-70% of the population. The industrialised world is slowly moving towards models in which we *do* collaborate – it does actually form part of our evolution, and making collaboration the norm can help – but our innate desire to collaborate can easily be disrupted by extrinsic rewards and punishment for failure to collaborate, amongst other things. Motivating people to collaborate is way more complex than we thought.

This is only part of the learning I take away from LSSC 2012. Already signed up for LSSC 2013 – hope to see you there!

Originally published at Liz Keogh's blog. Please leave any comments there.

There are a few exciting speaking and training engagements coming up, many of them UK based!

First off, two tutorials:

I’m running my first Deliberate Discovery, Cynefin and Real Options tutorial at Skills Matter on 29th May. These three ways of thinking and modelling software development and the world in general have really helped me, and I’d like to pass the techniques on. Highly workshop-driven and not at all technical.

At the end of September I’ll be running my 1-day BDD tutorial as part of Agile Cambridge. This is the only BDD tutorial I’ll be running this year, so if you’re interested, get in there now! Dan North (my mentor in all things BDD and Agile) and David Snowden (Complexity Thinking and Cynefin guru) are keynote speakers, so it promises to be an excellent conference!

I’ll also be speaking and running workshops through the year:

The Next Generation Testing Conference organised by Unicom is on the 23rd. I’ll be on the panel talking about Agile, and particularly ranting about our obsession with granularity and our need for certainty even where it doesn’t really exist.

I’m going to be talking about Real Options at Dev Tank in London on the 29th, after the Progressive .NET Tutorials. It shouldn’t be a long talk, so lots of opportunity to catch up with your fellow devs over a beer. More details to follow – watch the space!

On June 7th, I’ll be giving an overview of BDD, how to do it well and why it works at Agile East Anglia. If you’ve been out of the loop on BDD, this is a great chance to get into it, and I’ll be answering any questions you have too. I think there may be just one ticket left…

In August I’ll be at Agile 2012 in Dallas, running “Turning and turning in the Widening Gyre”, a workshop on complexity and deliberate discovery, and “BDD: Look, no Frameworks!” on how to do BDD using custom DSLs instead of BDD tools, while keeping steps maintainable and readable.

On 21st – 22nd September I’m honoured to be one of the keynote speakers at Lean Agile Scotland. Topic still to be decided, but it’s going to be related to people and the inside of our heads; one of my favourite minefields.

I’m also speaking at GOTO this year (October 1st to 3rd, Aarhus, Denmark). In my talk, “To be honest…” I’ll be looking at why honesty is so important and yet so hard to do.

In the meantime, I have some days free for in-house training or coaching. Please get in touch now, before the rest of the year gets this busy too!

Originally published at Liz Keogh's blog. Please leave any comments there.

If you’ve heard me speak at any conferences or read my blog over the last few years, you’ll know that I’m really, really into Real Options.

I’m half-tempted to get “Options have value. Options expire,” added to my tattoo. The principles which Chris Matts and Olav Maassen champion have become such guiding forces in my life that many of the decisions I make are only done in order to increase the number of options available to me. Once the whole innate phobia of uncertainty is out of the way, it’s a fantastic way to live life in freedom and with fun.

Real Options are also a phenomenal model for managing risk on software project – and not the only brilliant idea that Chris and Olav have!

So imagine my absolute joy when I saw this in the works – a graphical novel, fun and easy to read and understand, dealing with all kinds of ideas around risk management. The skiing story at the end of the first chapter (downloadable from the link) is the same one that Chris shared with me to help me understand his ideas.

Chris and Olav describe it as “a business graphic novel on managing risk. The book is a culmination of their collaboration on the real options model over the last six years. It provides examples of how to manage a project using the real options model and outlines a simple technique for making better (informed) decisions. It also covers more advanced topics such as information arrival process, game theory, feature injection, paradox of choice and how to deal with uncertainty. While geared towards project managers, the book benefits anyone making decisions in their job or daily life. Chris and Olav focus on making risk management easily understandable as everybody does this every day without being aware of it. ”

I am very confident that this book is going to be ground-breaking. I am so confident that I’ve already laid out £500 of hard-earned cash for a chance to star in the book (sorry, that option has expired). I don’t regard this as charity. This is me doing something small to pay Chris and Olav back for their guidance and help over the last few years, and it’s money they’ve helped me earn anyway. Estimated publishing date is Winter 2012… assuming they manage to raise the funds to kick it off.

If you would like to help these two fantastic people get this novel out of the door and benefit from the same help they’ve given me, please go to the Sponsume site before April 14th and pick an option. You never know – you could be the proud owner of a limited edition of a book that turns out to be as ground-breaking as “The Goal”*.

Originally published at Liz Keogh's blog. Please leave any comments there.

Every now and then, someone comes up with a new way of looking at the world that becomes the next fashionable thing to do. Every time I’ve seen this, there’s usually a space of time in which a lot of people say, “Meh, it’s irrelevant”, or “Meh, consultants”, or “Meh, they’re only in it for the money.” After a while, things settle down and everyone is used to that new model or concept, and it’s no longer seen as edgy or strange. I’ve seen it with Agile, and Lean Software Development, and BDD, and now it’s the turn of Cynefin and Complexity Thinking.

I’d like to shortcut some of that with Cynefin, because I think it’s kind of cool, I’ve found it useful, and it’s not actually that hard to get your head around once you make the small mindshift. I’m going to share a bit about what I know of it, then talk about how it might actually be a useful concept for a dev to have in their head.

Some of us went to the Calm Alpha meet up, created a list afterwards, and have been using it to discuss which kinds of software can be categorised by which domains. I think our need to categorise everything is part of the problem, but I haven’t worked out how to solve it yet. In this post, I’ll be categorising things according the Cynefin definition of the terms, so resist the urge to say, “No! What I’m doing is simple!” or “But it’s complicated!” because Dave Snowden, who created the Cynefin model, uses those terms in a slightly different way to our common usage.

So here’s Dave’s Cynefin model.

Dave Snowden, released under CC BY 3.0 – thank you!

The Cynefin model consists of four domains – simple, complicated, complex and chaotic – with disorder in the middle. The edges of the domains aren’t strict – they’re domains, not quadrants. There’s also a little fold beneath the “simple” to “chaotic” boundary, to show how easily simplicity can tip into chaos. If you’re going to use this for a lot of items, it might be worth using the domains as attractors, rather than categories. Put the items down on a table, then work out where the lines go afterwards. If you can get your head round that, you’re already on your way to understanding complexity thinking.

Here’s how I tell what kind of programming I’m doing.

Simple

Everyone can work out how to do this. Like, everyone. The example the CE guys used was a bicycle chain falling off. It’s easy to work out how to get it back on again. If you’re programming, I imagine stuff like the turtle at the science museum, or Lego Mindstorms with its graphical drag-and-drop interface, might fall into this space. Children and non-programmers can do it.

In a simple environment, you sense, categorize and respond. You say, “Oh, it’s one of those problems.” No analysis is required.

Complicated

Complicated stuff is predictable, but requires expertise to understand. A watch is complicated. If you’re programming, complicated stuff will be well-understood, done before, not going to change as you develop it. Writing yet another CRUD form probably falls into this space.

In a complicated environment, you sense, analyze and respond. You say, “Let me have a look at this problem and I’ll tell you how to solve it, because I’m an expert at this.”

(I have a theory that most devs get really bored by doing the same predictable but complicated thing over and over again. We tend to turn it into open-source or automate it, reducing it to the far smaller but more complex problem of how to do the automation or use the open-source. Devs are drawn to complexity like moths to a bonfire. And we make it when we don’t have it…)

I reckon that if everything in software development was merely simple or complicated, Waterfall would work very well. You’d be able to set out to achieve some goal, work out how to do it, achieve the goal and say, “Job done.” Software doesn’t consist of only simple and complicated stuff, though. So let’s have a look at the other two domains.

Complex

My favourite way to understand complexity is that acting in the space causes the space to change, and cause and effect can only be understood in retrospect.

When you start writing tests, or having discussions, and the requirements begin changing underneath you because of what you discover as a result, that’s complex. You can look back at what you end up with and understand that it’s much better, but you can’t come up with it to start with, nor can you define what “better” will look like and try to reach it. It emerges as you work.

In a complex environment, you probe, sense and respond. You do something that can fail, safely, and it tells you things about the environment which you respond to, changing the environment . This is the land of high-feedback, risk and innovation: generally stuff you’ve never done before, anything that the business are unsure about, new technologies, etc. This is the domain in which Agile techniques really flourish. If you have a look at Cynefin’s pyramids, this is the one with very loose leadership and the people at the bottom all connected together, collaborating to solve a problem.

This is the most interesting domain for me. It’s the reason why we do things like BDD – using examples to discover more about what we’re doing – but it’s also the reason why, if we focus on trying to pin every small requirement down, we fail.

Chaotic

Chaos is your house catching fire. Chaos is accident and emergency. Chaos is that bug you released to production that brought your site down on the day of release, and you need to drop everything and fix it now.

In chaos, you act. You get out of the house. You stem the bleeding. You do something to get the situation under better control. When Egor Homakov hacked Github this week, Github responded by suspending his account immediately. They acted on the threat. After that they analyzed his actions, considered what he had done and reinstated his account. Act, sense, respond.

So why should I care as a dev?

I’ve found this model really useful for understanding why certain ways of approaching software work best in certain situations, and fail at other times.

The biggest failures I’ve seen have come from treating complex problems as if they’re complicated. For instance, a common Agile practice is to divide a problem into small chunks that we call “stories”, then start working on them. That’s actually a good way to work when most of the problem is complicated, but if you’re doing something new then you may want to go down the “probe, sense, respond” route instead. Hack something out, and get feedback on it. There’s no point guessing how you’re going to reach the goal, because as soon as you get feedback, there’s a good chance the goal itself will change.

Also, sensemaking is itself a complex thing. By trying to get feedback, you might find out how easy or hard it is just to get feedback. That could change the way in which you engage with the business. It might affect how much time you put into preparing for a planning meeting, whether you make a feature work fully or just fire off a screenshot, etc. As you seek to get that feedback the business will change the way in which they respond, too, so it might become easier or harder, and you need to be watching for those signs so you can help to change the process to match. As a dev, you’ll be the one feeling the frustration or ease from the process. It’s no good just relying on your coach or Scrum Master to help you, because he or she needs your insight too.

Knowing this model helps me know when to do TDD or automate BDD – defining a well-understood outcome, and working creatively with the software to reach it – and when to just use examples as ways of discovering more about what we’re trying to do. If I can clearly articulate the outcome and everyone agrees on it, then probably it’s good for TDD and BDD automation. Otherwise, having conversations is more important than automation, whether it’s with a pair-programmer at a class level or a business spokesperson or tester at a system level. Being able to tell the difference can help ensure that the conversations are the most interesting and effective conversations we can have. If I spot the conversations becoming boring, with people yawning or drifting off, then I know we’re trying to apply a complex method to a complicated or simple space and I can say, “Okay, I think we understand this well enough,” and work on something different instead.

(Also, knowing that the act of sensemaking is complex itself makes me look out for situations in which we’re misapplying methods.)

When chaos erupts, I know that letting my PM order us about for a bit is OK. Dropping everything we’re doing is also OK – forget the whole “developers need to be left alone to do their work” idea that the Scrum timebox normally provides. We fix the bug, hack the workaround, take the feature down, do whatever we need to do to get things under control. Chaos almost matches the “expedite” class of service in Kanban, except that I think you probably don’t even bother putting a card on the board until the need to expedite is over. After the emergency is over, we can look at whether it was just a one-off or whether there’s something we need to do to avoid happening again. For instance, being able to roll back a deployment cleanly and quickly gives us the ability to probe a release instead of crossing our fingers, moving something that might become chaotic into a complex space instead.

These are the kind of decisions that we make intuitively anyway, as developers, but human intuition is often flawed. We’re often uncomfortable with uncertainty, so we usually try to define outcomes regardless of whether they can be clearly defined or not. We’re definitely uncomfortable with chaos, and often make the mistake of treating a one-off chaotic incident as systemic, stamping controls over everything when what we really need is a way of probing, or trying things out safely. Having this model in my head has really helped me to become more comfortable with those situations, and to find approaches that fit them much better. Of course, this is massively useful when I’m coaching and acting as a change agent or helping a PM work out how to lead a team – but even as a dev, having this model makes a big difference to me and my day-to-day work.

I hope it will help you too.

Originally published at Liz Keogh's blog. Please leave any comments there.

I often hear things like, “Tell the team what to build, but don’t tell them how to build it.”

Or, “A feature is what you’re building. A story is how you’re going to build it.”

Or, “When you’re doing TDD, don’t worry about the internals of the class. The API is what it does. The internals are how it does it.”

Here’s the thing. When we write code, that’s how we’re creating a story or a feature. It’s also how we’re implementing the architecture. It’s how we’re managing security and providing an audit trail and doing a bunch of other stuff.

And that’s how we’re selling more goods. And how we’re keeping things maintainable for the future. And how we’re preventing data theft. And how we’re correcting our mistakes.

And that’s how we’re staying in business. And how we’ll be able to react in the future. And how we’re able to sleep at night. And how we learn.

• The code is how we deliver a story.
• The story is how we deliver a feature.
• The feature is how we give the users the capability to do something.
• The users’ capabilities are how they deliver a business goal.
• The business goals are how stakeholders implement a vision.
• The vision is an idea of how to make money, save money or protect revenue.
• And we could keep going if we wanted to…

Every goal, no matter how big or small, is the how for someone’s what. (The how and the what may come from the same person, but the interesting stuff happens when they’re different people. Or behave like they are.)

If only life worked by being able to divide a bigger what up into smaller pieces and manage them appropriately, then it would all be fine! Unfortunately the code has to work with other code to deliver its value. The features have to work with other features. The system has to work with other systems, users have to work with other users and the goals of one stakeholder have to align with the goals of another.

This is why we have root cause analysis and the “5 Whys” – because when we can see the higher-level goals and deeper-rooted problems, we can understand better how our own actions fit into them, and what they deliver – for better or worse. This is also true for other domains than software.

It doesn’t really matter much whether we call them features, stories or tasks, as long we appreciate that they’re how we’re delivering to those higher-level whats, and we have a pretty good understanding of the whats and how to test that we’ve achieved them, even (especially!) if the what is a learning or exploratory goal.

Of course, we’ll get the how wrong occasionally and fail to deliver the what. But that’s what feedback, in its many forms, is for.

Originally published at Liz Keogh's blog. Please leave any comments there.

I’ve been meaning to do this for a while. I have released my BDD Tutorial slides on SlideShare.

There are notes underneath each slide which are a cut-down version of the kind of things I talk about. I’ve even left the exercises in, with a description of what I do in each.

I am releasing these under my usual favourite licence – Creative Commons share-alike. That means that as long as you attribute me, and are similarly generous with any derived work you make, you can use the slides commercially and base your own work on them.

Yes, that means that if you want to, and you feel qualified to do so, you can use the slides, run the course and get paid for it. If you don’t feel qualified, feel free to experiment. Just please give a nod my way when you do!

Originally published at Liz Keogh's blog. Please leave any comments there.

A long time ago, I was toying with the idea of starting my test methods with “will”, instead of “should”.

Dan explained to me, “If you start with the word ‘will’, you’re already making the assumption that you understand what you’re doing. Using ’should’ allows you to question whether you understand or not.”

For me, that was the moment that I suddenly got it. BDD and TDD aren’t actually about making sure that something works well. They’re about uncovering the parts you don’t understand; the parts that are hard, and the gaps. Dan’s post introducing “Deliberate Discovery” takes this idea even further, but it started here: replacing the word “test” with the word “should”.

This is why I find it more useful to look for the gaps in the examples; scenarios we haven’t thought of, or don’t know what to do. Chris Matts calls this, “Breaking the model”. Often whatever we do here is wrong, so we need to write down our suggestions and then get feedback on them.

If you do anything which starts suggesting to people that these examples are correct and complete – like, for instance, automating them or referring to them as “specifications” – then you may find yourself running into trouble. Automation is a commitment, specification can be seen as one, and we know by now that we never commit early unless we know why.

You might also want to keep a small record of the looser requirements or behaviour that spawned the examples – for instance, as blurb in a scenario or as a method name – just so that you can give yourself a chance of spotting those gaps later. You won’t always get it right first time, and that should be OK.

Originally published at Liz Keogh's blog. Please leave any comments there.

CALMalpha was meant to be a mash-up between the Lean, Agile and Cynefin / Complexity Theory practitioners.

The outcome of the unconference wasn’t really stated. When you understand that a complex domain is one in which the cause of an outcome can’t be perceived except in retrospect, this might make more sense. The only thing we were trying to do was see if there was a way of using complexity theory to help inform our practices, and if there were some practices from Agile and Lean that complexity theorists might find interesting – a mash-up!

There’s one problem with this.

Currently, the best-known leadership of Complexity Theory revolves around the company Cognitive Edge. These guys have some amazing methods for making sense of domains, spotting complex problems and providing data which calls out “weak signals” that might otherwise be lost. I paid good money and took time off work for the course last year, and it was worth every penny. For the non-initiated and tl;dr, imagine five new types of retrospective, a method for reducing planning meetings to five minutes, and six different ways of making the output from them heard, and you’ll get a vague idea of the impact and scope. Oh, and they’ve got software for running the retro across countries.

Except…

I can’t currently use the methods they taught me, not as a professional coach. The methods are open-sourced, but released under a non-commercial, non-derivative Creative Commons license.

Cognitive Edge, your Wiki says (emphasis mine):

The Cognitive Edge wiki exists to provide a collaborative space for accredited members of the Cognitive Edge Network. All accredited practitioners should feel welcome to contribute to the ideas and concepts in these pages.

The licence prevents me from using your methods as a professional coach:

You may not use this work for commercial purposes.

The licence also prevents non-accredited people, which is most of our communities and a lot of CALMalpha attendees, from creating their own ideas:

You may not alter, transform, or build upon this work.

While I might be able to build on your work, I’m unwilling to do so as long as my efforts fall under this licence. I also can’t pass on anything to the people I work with for their contribution.

Can you see how this doesn’t mesh with the idea of a “mash-up”, and goes completely against your ideas around multiplying perspectives?

So here’s my request.

Cognitive Edge, please, please open your licence up for commercial and derivative work.

The stuff you do is amazing. If you were working solely for the money, you wouldn’t have come up with these ideas. I can only assume that you, like us, are trying to make the world a better place. We will continue to attribute the methods to you and talk about how amazing they are. Those of us who’ve seen it will continue to point people towards your SenseMaker software (which is ground-breaking, world-changing, worth paying for the 1-day demo, and deserves the more rigorous patent applied to it – I look forward to the day when it’s a bit cheaper!)

As it stands, we can’t do anything useful with your methods. Worse, because you’re working in a space full of narratives and I’m working in a space full of very similar examples, I have to be very careful that my work – released on my blog under CC, non-commercial, non-derivative – is actually based on other sources (mostly Dan North and Chris Matts) and not on yours.

Please. Be generous. Reach out to your contributors, ask them, and release what you can.

Sometimes it’s worth doing something you can’t go back from.

Originally published at Liz Keogh's blog. Please leave any comments there.