So I work as an independent Lean and Agile coach, I’m based out in London, as part of hanging out in London I get to hang out with cool people like Dan North and Chris Matts and Dan North created Behavior Driven Development, so I’ve had two sessions about that, both of them technical which is unusual for me and one session on complexity thinking and Cynefin. That was a lot of fun. I got into the complexity thinking partly through this stuff around BDD, this word should we use quite a lot in BDD which allows you to question things and to discover uncertainty, so they are quite closely correlated.
It stands for Behavior Driven Development and it’s about questioning the behavior in application, the intended behavior in application through using examples. We describe the behavior, we come up with some examples to illustrate that behavior, we can do it at class level as well, so we go right down into the code. More recently I’ve been working with Chris Matts talking through feature injection, which takes it to a much higher level so we’ll be looking at visions and stakeholders, different stakeholders and their goals and examining whether the capabilities of the system that we’re developing would actually suffice to meet the goals of the stakeholders. I think a lot of people don’t really know that BDD is more than just a development tool, increasingly we’re using it as an analysis tool, investigating and exploring the problem space. One of the things Dan North did when he came up with it was to replace the word test with this word should, so when you say test to somebody they immediately think, “oh, ok, so I understand what I am doing, now I am going to test that what I am doing is the right thing”, whereas if you say “this piece of code should do this thing, this application should do this thing”, you go “should it? should it really? should something else do it, should it do it now or later?” and you can start exploring the scope of your application and questioning it, so it allows for a lot more uncertainty than words like test or even like specification. Specification is another word that I try to avoid, a lot of people refer to BDD as specification by example, some even talk about executable specifications, but again I find that word doesn’t allow for the kind of uncertainty that I’d like to look for when I am doing BDD.
Todd: And assert is probably another one that people kind of throw in there too.
Assert, did you say? It’s hard to get away from the frameworks that do things like assert, rspec and some of the other frameworks have replaced that with “this thing should look like this”, and I really like that syntax.
I would encourage them to talk to some of the teams that I’ve started doing BDD with, who just have conversations, some of them didn’t even start by writing those conversations down, just having the conversations and using that language of examples to explore scenarios. Most of the teams I work with tend to capture in Mono Wiki, in some cases automation is really really hard and often not worth it, so usually if you get a regression bug in something it’s because your design is flawed somewhere. We were using frameworks in the last project I was working on where they were so modular it was really hard to get the behavior of one affecting behavior in another module, so once you’ve tested them manually, you know it was going to stay that way unless you changed it deliberately. I think automation on that project would have been complete overkill. What we did do is we had long conversations with our business owner, our product owner over what the different aspects of, I can’t really talk about it in too much detail because it would be quite differentiating, but the aspects what the application should do and we came up with lots of different examples.
I talked to him both over the phone and when he came over to London in person, because he was actually mostly based in another country, and then I wrote the scenarios down myself, send it back to him, said “can you please read these, check them over, is there anything missing, what have I got wrong?” and then he would fill in any gaps. And sometimes he would say really interesting things like “what should we do in this situation?”, he would go “oh, I haven’t thought of that” and that’s what I mean by being able to capture uncertainty. So a lot of teams I found when they go into BDD, they almost use it in a way of punishing the business and say “you must come up with clear acceptance criteria, you must come up with clear examples”, and I’ve heard that from a few teams, “if you can’t come up with clear acceptance criteria, the story is not ready for us to do”. Instead what I would love to see teams do is to collaborate around the uncertainty, “we could do this thing, and it would be quite easy for us to do and you get some feedback with it”, rather than saying “no, we’re not doing it because you’re not sure”. The whole of software development is about being able to cope with uncertainty and being able to work with your business when they are not sure, not force them to come up with a certainty that doesn’t exist.
So, one project we talked through the capabilities in the system. Literally, you’ve got initial project vision, I think they were trying on this occasion to align the three different applications from companies they purchased and make them work as though they were the same company, which it was by then, that was the vision and then, we looked at the capabilities that needed to be delivered for that vision to happen, we also looked for any stakeholders that were going to stop us going live. Usually you’ve got a championing stakeholder, a core stakeholder, who is sponsoring that vision, but also you’ve got additional stakeholders who are going to stop you unless you meet their goals as well. One of my favorite things is to take those gatekeeping stakeholders and get them to educate the team about what they need, so in the same way that in lower level BDD you get the testers involved and you define those scenarios in combination with the testers before you start implementing the code.
You can get these gatekeeping stakeholders to help you work out what they need, what capabilities they need in the system, so it might be security, this must be secure, mustn’t allow SQL injection attacks, and you can break down what secure means in that way, must be all visible, maybe you’ve got legal guys involved, whatever you need to get those goals out and then you have these capabilities in the system. It’s weird, because when we describe scenarios, we frequently describe them in terms of the capabilities even though they are much lower level. So if I’ve got a pet shop, I’ll say things like “when I register a new pet, when I put a pet in a basket, when I sell a pet, the ability to sell pets is a capability of the system. And you don’t know whether I am using a journal with a pen and paper and a calculator to add up the numbers or a website, or windows till software or mobile phone, it’s completely UI independent, but you know that this is what we need to be able to do. And frequently you will find that those capabilities are already being done by something else in the business, it might be done manually with paper and pen. It might be they’ve got five different systems and a really painful process in the end to bring the numbers together, but that capability will already generally be somewhere in the business.
So you take the capability, work out what features you are going to get from it, when you understand the features, you can start seeing the UI come out, at that point you can start getting feedback on what you are really going to code and you can write the scenario around that UI, but without mentioning the UI. It’s only when you come to implement the scenarios, if you are going to automate them and make them executable, that you can start referencing the UI, and you do it underneath the covers, so that it’s not part of the language.
6. So how does this kind of differ from let’s say, generating user stories?
A user story tends to be quite high level, quite large, a user story will be the journey of the user through a whole system, for instance you say “here’s Penelope”, they usually have a persona associated with them, she's a “student at the Oxford University, she needs all these textbooks, she goes to Amazon, she searches for the textbooks, she puts them in her basket and goes and sells them, three days later they get delivered”. But that’s probably about four scenarios, so there are probably different capabilities there as well. You have the capability to shop and search for books and pay for them, but you’ll have the capability to pay by PayPal, the capability to pay by credit card, you have delivery options, so the capability to get the books delivered first class, get the books delivered with Amazon Prime. Amazon Prime is a great example of a differentiators, I’ve got an Amazon Prime membership, I love it, because I can get things delivered the next day, the number of things I can buy on Amazon now is obscene, I got a light bulb delivered by Amazon because I couldn’t be bothered to remember which size to get and then get down to the shop and pick one up and carry very gently home, I just wasn’t sure, Amazon got one ready, I just ordered one from them.
Todd: I must say I am incredibly jealous as a Canadian because we don’t have Amazon Prime.
You don’t have Amazon Prime.
Todd: We don’t get all of those.
For me it’s why I buy so much stuff from them, I can get it the next day. So when you can actually start looking at those differentiators with companies, you can really see, focusing the scenarios around those differentiators makes for a much more exciting conversation, so rather than saying “we are going to deliver the books” you can say “we are going to offer Amazon Prime membership and deliver the books the next day”. When somebody comes on Amazon Prime membership, then what happens? That’s the kind of thing I try and do in the conversations I have with the business as well as go straight for what makes this application different from the previous ones? If you are replacing a legacy application, what is different about this legacy application to the one you’ve already got, the new application to your legacy one? It always makes me laugh, but in a very sad way, when the main differentiator is that is going to be more maintainable, but somebody’s put some deadline on it and the first thing that happens is the deadline is approaching and there is a lot of pressure on the devs to go faster and so rather than creating an application which allows those options for the future and it’s more maintainable, they start cutting corners and produce a legacy application. It happens so many times, it’s just wrong.
I tend to trying and avoid having conversations about really blindly obvious stuff, I used to have those conversations, we always used the retail store as an example. So given Fred has bought a microwave for 100 pounds, when Fred asked for a refund on that microwave because it is broken then he should get 100 pounds back. But we all know how that works, it’s a very boring scenario, it’s a retail store, we know how retail stores work, we use them every day, that’s not the conversation I want to have. The conversation I want to have is given Fred bought a fridge freezer for 200 pounds and fridge freezer is broken, Fred’s not going to be carrying that thing on his shoulder, then what should happen? Are we going to give him a refund, what happens to go and get the fridge freezer back from his house, what happens if he just forgot to plug it in? And those are the conversations that I find more interesting because there is more uncertainty around them and the first person to write an automated till system to do that is going to have to find answers to those questions and might get them wrong.
So if you can see that there’s uncertainty, you know, is our customer going to get really upset if we refuse to give him a refund until we have picked up the fridge freezer, if we give him a refund and then it turns out the fridge freezer isn’t broken can we get the money back again? And those kind of conversations I think will be much more interesting, if you can appreciate that there is uncertainty there then you can leave the options open, you make sure the code is easy to change. If you don’t appreciate the uncertainty and get the business scenario down, “yes, we know how this works now”. Now I’m sure we do know how that works now because there are retail stores out there that do that, but the first person to do that, the first store to do that probably had to answer those questions.
So, a couple of people, and I am not going to name names or bodies or tell you why they were doing it, but at least two groups of people have either done or wanted to break their entire backlog down into scenarios, ahead of time and just have scenarios. Now, for me, that is again representing a ton of certainty that you cannot possibly have. I found it bad enough when I walked into a room and there were four walls covered in user stories, at least they’re higher level then scenarios, but even so four walls with 80 stories is again, is a level of certainty that you cannot possibly have and they come to 374.6 story points. There’s a difference between having a good idea of what you are doing and having a very precise idea of what you are doing and we cannot possibly have that kind of precision nor can you possibly think of every single scenario. I know a lot of people have got rid of the description of behavior so you have acceptance criteria that defines the rules for all situations and then you have some examples that illustrate that acceptance criteria, what some people are doing is getting rid of the behaviour once they have the scenarios.
Now that’s great if you can guarantee you’ve got all of them, I don’t think you can, especially not if the thing you are concentrating on is the new differentiating behavior because you are going to miss bits, because you’ve never done it before and you are human. So that’s the bad examples of BDD, just trying to use it to eliminate uncertainty, you don’t, you just hide it until you start delivering and then it comes back to bite you.
You know when it’s time when the conversations you are having are surprising you and you’re learning something from them and you’re “oh, ok, that’s how it works”, those are the scenarios I would want to write down. And be aware that you probably have junior devs, maybe people that don’t know the domain so well, so if you’ve got domain knowledge like that make sure that gets passed on, I don’t mind whether that domain knowledge is written down or not because it should be something you’re talking through all the time, as part of devs working in that domain anyway, so by the time you’ve been working on the project for six months you probably have a really great domain knowledge anyway.
The differentiating stuff, the new stuff, the surprising stuff, write that down because you are going to want to make sure other people understand that, you’ll want to showcase that you’ve understood it, I actually really like getting the devs to write the scenarios, because if the business people write the scenarios, first of all there is so much temptation to not have the conversation if the business people are going to write the scenarios and giving it to the devs and when you miss that conversation, you miss the opportunity to ask questions. If you get the devs to write it down, the devs play them back to the business people, there is often “you’ve misunderstood something”. Something I did with the product owner I was working with the last time was getting them to actually come up with people, real people whose needs were going to be matched with the scenarios you’re writing, so if you have different people with different permissions in the application and the permissions for this application were quite complex and then you are going to want to see different things happen as a result, find the people who actually get those different sets of permissions and describe what they are doing with it and then write the scenarios around them.
And it gives you that much more alive, living, much more interesting flavor to them when you know you’re writing it from real people. So wherever possible I say use examples which excite the imagination. When I do the talk I always have a pet shop and a baby rabbit and frequently say “I just mention this baby rabbit, little baby rabbit, what color is it?” And people usually have an image in their heads, it’s usually white, but frequently, sometimes it’s little grey fluffy rabbit, the point is you have a picture of the rabbit in your head.
Todd: I think you’re biased it by naming the bunny Snowy.
Yes, calling the bunny Snowy is a good example, you’ve seen him.
Todd: Yes, I saw him Snowy the white bunny.
Snowy, the bunny rabbit.
Once the UI has stabilized a bit, you can automate it. I find that if the UI is in flux, particularly if it’s a new UI, you're going to show it to the business and then you've got something wrong, because it’s new UI. We had this conversation in this previous application I was doing, brand new piece of UI, had been analyzed to death, it took ages to find components that would allow us to do it, it took even longer to automate it, we did automate it, a bit, I found it really hard to automate writing into this thing, which was great because as soon as we actually showed it to the business and got them to try and write into it they were like “oh, no, I need to use a mouse, no, we don’t want to use a mouse, we’re all traders, we don’t like to take our hands off the keyboards” and that was great, that was really useful feedback, what we'd actually done was hardcode the data behind it, so it had hardly been any work done, minimum work to get this thing up and running. It was also written in WPF, with nice NVFM so we could just rip the whole of the front off and probably throw another one on without probably any changes to the model at all, and come up with a completely different UI. I love that WPF and Silverlight allow you to do that, I just wish it also worked on Linux machines and with IDEs, for free. That would be nice, it’s a really good model, I love C# as a language as well, it’s very flexible.
Yes. Ok, so the other session I was doing, it was called Turning and turning in the widening gyre, which is the first line of a poem from Yeats’ Second Coming, the line everybody knows from that poem is “Things fall apart; the center cannot hold”; meaning anarchy is loosed upon the world and it’s basically about the idea that sometimes things do no work out the way we planned and most of the time when you are talking about differentiating pieces of software that is the case. We also talked about chaotic pieces, expedited bugs, there’s a trading system which very recently managed to lose half a billion pounds on rogue trades, something got released into production that shouldn’t have, they tried to stem matters as quickly as possible and work out what went wrong and stop it, but even so it’s still very expensive for them, that’s an example of an emergency bug fix.
Now, if they would have failed to stop it, they would be bankrupt. I don’t know quite what their situation is at the moment, but it’s that kind of emergency is chaotic. And then you’ve got this complex stuff where David Snowden described it as the cause and effect are only apparent in retrospect, you can tell once you’ve seen the effect what caused it but you can never have expected that outcome particularly, as I said with this new UI and we had to change the new UI because we’d never done it before, so you get these emergent outcomes in a complex space. A lot of what we do is actually complicated, a lot of what we do is the outcome is really well understood so your bulk standard CRUD form, your web form, create delete, update delete, we know how it’s meant to work, we know what’s expected of it, it’s really boring for devs to do, it’s so boring that they decided to automate it, they created Rails and that’s a very frequent response I find to complicated problems.
There’s a great cartoon from xkcd where this guy goes “pass the salt” and then the next panel is like “dude, it’s been five minutes, where’s the salt?” and the dev is like “hold on, I’m just creating you an arbitrary system to pass you arbitrary condiments when you need it, it’ll be quicker in the long run” and that’s what devs do when they come across boring things, especially if it’s something complicated where you have to remember all the steps but the steps are really well understood and you’re just executing them again. I suspect most of the automation frameworks actually got made when they tried to make devs do testing because testers tend to have inexhaustible amounts of patience and be prepared to sit there and click and they are just waiting for that surprise when something doesn’t work and devs are like “click, click, I’m bored now”, so they want to automate stuff. It’s just really funny the amounts of things I see devs will take this complicated problem and automate it and turn it into a much smaller but more complex problem. Devs really love working in that complex space.
Some of the other things we talked about were different Agile practices, so I got the group to start by just thinking about different environments they were coding in, so we talked about a Lean startup. So Lean startup is almost your canonical complex environment, you’re doing something where you have absolutely no idea what the outcome is going to be, you hope it’s going to be positive but you’re prepared to change direction, you know that what you end up with may not be what you started with. So I say “ok, now you’re writing a trading system is that more or less complex”, and we reckon it’s still complex but it’s definitely more towards that complicated well understood space, so a complicated thing, you can break it down, you know what the outcome is going to be, you just require expertise. And then I said “ok, can you think of any complicated systems?” and they were all like “no, I can’t think of anything complicated, everything has this complex component to it”, “so is there anything where you just hire experts and get the experts do it?”
And then they started thinking of all those other things which they don’t do themselves because software developers tend to work in a complex space but when you hire an expert to do like a SAP roll out, somebody would say “oh, yes, because we have this code and all we need to do is get our experts to configure the code, you can configure the CMS, install the timesheet system”, heaven forbid the company should write their own timesheet systems, I don’t know anyone who does that, but it’s that kind of movement around the domains that we were looking at. When I got them to write down the places and the environments and the situations, what I did then was get them to write down practices and draw an arrow on the practices to show which way they moved. For instance, TDD is a practice which relies on you being able to have a particular outcome, so it’s actually close to the complicated space, it’s not really a complex thing, while you are exploring the problem if you use it to discover uncertainty, great, that’s one aspect of it, the other aspects is being able to tell that you’ve reached these defined outcomes and then it works in the complicated space.
Then we mapped all these practices and we looked at what happens in a Lean startup that doesn’t happen anywhere else, what happens in a SAP roll out that doesn’t happen anywhere else, we used those mechanism for generating the practices and then we took places away so it’s just practices left, and we can see kind of how they move around. We looked at what practices fail and why they fail, what made these practices fail, so one of the examples was the planning game. You break down the work into small stories and you make estimates for those stories and comes the end of the sprint and you’ve failed your commitments. And I really hate this idea that you are committing to something you’ve never done before, you have no idea how long it’s going to take, and this is a very frequent failure I see, the planning game assumes that you can analyze it and work out exactly what’s going to happen and if it’s new and differentiating you really can’t.
I worked on one project where we addressed all the new and differentiating stuff right at the beginning of the project, five PMs yelling at everybody because the velocity is all over the shop and we can’t estimate for toffee because everything we were doing was something new, everything was a spike and the stakeholders were really happy, because they can see we’re doing everything that keeps them awake at night, but you can’t track it for toffee, you just can’t track that kind of stuff, all you can do is go “ok, it looks like you’re doing a good job, let’s keep funding it, let’s keep the project going”, and things do gradually settle down but the point at which they settle down is just a matter of feeling in the bits that we were already knew about, we were able to start off-shoring those bits and getting some help from junior devs and the likes. So I really like that way of working but it doesn’t fit with your standard Scrum implementation.
You keep your head down and hope your project manager doesn’t blow too much. It did resolve once it started being obvious that we were delivering really effectively, I think we were slightly short of the deadline and I will say that our project manager’s response to discovering we weren’t going to meet the deadline two months ahead was to get us to work weekends and evenings. Now, at that point I am not doing the planning game anymore, right, because I don’t see the point, we’re going as fast as we can and if you don’t like it, there’s nothing you can do, the car won’t go any faster. Jerry Weinberg has a great story where he’s told “we need this”, he said “it’ll take 18 months”, “no, we need this in six months, not 18, we’re losing 100,000 a month”, “oh, are you? So if I give it to you in six months you will stop losing money immediately?, “yes”, “so, if I give it to you in three months, you’ll save 300,000?”, “yes”, “if I had it right now you’d stop hemorrhaging 100,000 a month and you’d be able to save all money going forward?”, “that would be brilliant”, “you should have asked me 18 months ago”.
And I love that, it’s such a great response to those kinds of deadlines and those problems, it takes as long as it takes. One of my friends has a phrase “yelling at the engine does not make the car go faster”, and it really doesn’t, it never does.
The Cynefin framework. It’s not spelled like kuh-nev-in, it’s spelled like psinephin. I was showing it to somebody, I said how many of you have heard of the Cynefin framework and everybody was no, and then I wrote it on the top and one of them was “oh, that, yes, I’ve heard of that”. So it’s spelled Cynefin but it’s pronounced /ˈkʌnɨvɪn/. It’s the invention of David Snowden, worked on a lot by the guys in Cognitive Edge and it’s a framework for understanding which domain you’re in. So it’s called sense making but the act of sense making is itself complex so one of the things they asserted, it looks like it’s got four quadrants, it looks like a little matrix, it isn’t a matrix, the lines are blurry, their domains; if you call them quadrants David kills a puppy because otherwise his cat gets really vengeful of him if he kills kittens, so they’re domains.
What we did is we put simple, complicated, complex and chaos on bits of paper and just didn’t put the lines in at all, so we use them as attractors, one of them called them gravity points and then we kind of put the Lean startup close to the complex; by looking to see what’s going on there and your simple stuff there’s only one way of doing things so we didn’t come up with that much that was simple. The example I use is the turtle software where you can program how far the turtle goes forward and the angle it moves and you can make it go round and stars and squares and lots of kids have played with that inside museums, I used to have one of those on BBC computer when I was very very young, and there is only one way of programming that turtle, it’s best practices, the example they use is when your chain falls off your bicycle you look at it you go “oh, my chain’s fallen off the bicycle, it’s one of those problems” and you put it back on, so you sense, categorize, respond.
The complicated space is very similar, it’s also very order but you need expertise, so you sense, analyze and respond. In the complex space you need things to be safe to fail, so you probe, you have to run experiments and I’ve had long discussions with people over what kind of things can you hypothesize in that space and you can’t hypothesize an outcome, you can hypothesize an impact. So one of the things I like doing is running a workshop for TDD where I go to a new company, I run a workshop for TDD, I don’t know what the impact will be but it’s usually positive. Sometimes people are really excited about TDD and suddenly they are skills and all of those in the company start to go up, sometimes it just creates this feeling that learning is valued and people start learning on their own at home, sometimes people find better jobs as a result and that makes me sad because it’s usually not why I’m brought in to coach.
I do actually warn people before I come in, if I think that’s the kind of environment they’re running in because I think they need to solve that problem before they move to Agile, training really great people in Agile in an environment where they are not supported usually makes those people quit. So you can usually tell what the impact is going to be but not necessarily the outcome. And then you’ve got your chaos space, your expedited bug space, one of the practices I challenge them to look at was roll backs, so you’ve got a roll back procedure, where does that move you from, what domain would you be in if you didn’t have it, what could happen. If we don’t have rollback and we release a bug, we might be in chaos, we might have one of those expedited bugs hemorrhaging. So if you go rollback procedure, you just roll it back, now you’ve turned it from being a potential chaos thing into a safe to fail experiment and you can roll back if it goes wrong. The team that I spoke to, that had the best rollback I have ever seen, released two or three times a day to live and they don’t have a particularly much automated testing.
14. So what does that move you towards then if you have the rollback procedure?
It makes releasing an experiment or a probe, so you’re in the complex space so it gives you that safety net, and the idea that it has to be safe to fail, I find that really interesting, so many companies run projects with an expectation that they’ll be successful, 60% of projects are successful, nobody is ever like “yes, this project that we are doing now has 40% chance of failure” and they’re like “oh, yes, that will work, that’s going to be fine”, ”how many projects have been successful in this company in the last year?”, “about 30%”, “right, but this one is going to be successful”, “yes”.
So one of the things we’ve talked about when we talked about these failures, we’ve been looking at using the planning meeting as a way of breaking things down. Now if instead you look at it as a framework for getting people talking and you make that the thing that happens, talking about interaction rather than breaking things down and breaking things down works in a complicated space, getting people to interact and collaborate on a goal works in that complex space, so if you change the nature of the planning meeting , the focus of the planning meeting instead of breaking things down and making sure you have all the small pieces, to be “let’s collaborate around this, where is the risk in it and how are we going to address that risk, what’s the goal we’re heading towards” and turn into that instead, you’re more likely to be successful. Anything which breaks stuff down in a complex space, including estimation, breaking everything into scenarios, without considering any probing scenarios, I find that is just really dangerous and usually ends up in somebody yelling at somebody later.
Sure. The HBR article, there’s a Harvard Business Review article called something like A Leader’s Framework for Decision Making, by Dave Snowden, I found that was very well worth reading. If you want to get into behavior driven development there’s an entire page of links on my blog lizkeogh.com, which should take you on a journey from getting started, it’s got some links if you’re used to TDD and ATDD and how to covert over to BDD, it is different, it’s also got stuff about BDD in the large, my whole tutorial slide set is actually on Slideshare and I taped everything so you can just go look at that, it’s three hours of tutorials, it’s more when I started adding all the workshops that I normally do as well, but it’s very focused on the conversations, there’s no code there, it’s just about how to have the conversations.
Todd: Excellent. Well, thank you very much Liz.
Cheers.