Downloaded 1,518 times
Uploaded byLiz Keogh
Behavior Driven Development
The document discusses behavior-driven development (BDD) and provides various examples to illustrate its principles, such as refund scenarios and conditions for selling pets. It emphasizes the importance of conversations, context, and clarity in defining acceptance criteria and scenarios for software development. Additionally, it touches on risk management in projects and encourages collaborative discovery through exercises and examples.
More Related Content
Similar to Behavior Driven Development
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Behavior Driven Development
- 1.
- 2. Behaviour-Driven Development Feature Injection Cynefinand Differentiation Splitting Stories
- 4. An Example ofan Example Given Fred has bought a microwave And the microwave cost £100 When we refund the microwave Then Fred should be refunded £100.
- 5. An Example ofan Example Given baby rabbits cost £10 When we sell Snowy the Baby Rabbit Then the customer should be charged £10.
- 6. Examples Given a context Whenan event happens Then an outcome should occur
- 7. “Given Scenario” –an antipattern Given Fred puts a microwave in the basket And the microwave cost £100 When Fred buys the microwave Then he should be charged £100 When we refund the microwave Then Fred should be refunded £100.
- 8. Cucumber Feature: Addition In orderto avoid silly mistakes As a math idiot I want to be told the sum of two numbers Scenario: Add two numbers Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press add Then the result should be 120 on the screen This is what most people associate with BDD
- 10. BDD is abouthaving conversations
- 11. BDD should makeit easy to create software
- 12. A scenario isan idea, not a promise
- 13. A scenario isan idea, not a promise
- 14.
- 15. Exercise Think of the bestconversations you’ve had. What made them awesome?
- 16.
- 18. Boring! Given Fred boughta microwave And has receipt number 1857123 And receipt 1857123 lists it at £100 When we scan the receipt Then the screen should show the list of items When we select the microwave And we refund it And scan Fred’s credit card Then Fred should be refunded £100.
- 19. Examples Given a context Whenan event happens Then an outcome should occur
- 21. Make sure youget it right Assume you got it wrong
- 22. Is there acontext in which this event will create a different outcome?
- 23. Examples Given Fred hasbought a microwave And the microwave cost £100 And the microwave was on 10% discount When we refund the microwave Then Fred should be refunded £90.
- 24. Examples Given Fluffy thebaby rabbit is 1 ½ months old When we try to sell Fluffy Then we should be told he’s too young
- 25. Is this theonly outcome that matters? If we could achieve it with pixies, would it be enough?
- 26. Examples Given Fred hasbought a microwave And the microwave cost £100 When we refund the microwave Then the microwave should be added to the stock count.
- 27. Examples Given each rabbiteats an average of 20g of carrots a day When we sell 10 rabbits And 5 rabbits are born Then our order for carrots should go down by 700g a week
- 28. Same scenario? Then Fredshould be refunded £100 Then the microwave should be added to the stock count
- 29. Same scenario? Then Ishould be given £20 And £20 should be debited from my account
- 30. Then my eyesglaze over… When we select “baby rabbit” from the list of pets And the customer declines all special offers And we want a VAT receipt And we select payment by credit card And the customer is present Then the receipt should say £10 And we should have £10 more takings And the number of rabbits in stock should decrease And …
- 31. Then my eyesglaze over more When we click the “Pets” drop-down And we select “baby rabbits” And we click “No” And we check “VAT receipt” And we click “Pay” And we select “Credit Card” And we click “Yes” And …
- 32. Exercise Come up with twoscenarios with two outcomes from your own work, one of which can be split and one of which can’t. (They don’t have to be about software)
- 33. And you cankeep going… Given Fred has bought a microwave And the microwave cost £100 And the microwave is faulty When we refund the microwave Then a fault ticket should be printed.
- 34. Exercise What other benefits canyou think of that might come from talking through different scenarios?
- 35. Acceptance criteria vs.Scenarios Given Fred has bought a microwave And the microwave cost £100 And the microwave was on 10% discount When we refund the microwave Then Fred should be refunded £90.
- 36. Acceptance criteria vs.Scenarios Given an item was sold with a discount When a customer gets a refund Then he should only be refunded the discounted price.
- 37. Acceptance criteria vs.Scenarios Items should be refunded at the price at which they were sold.
- 38. Acceptance criteria vs.Scenarios Given Fluffy the baby rabbit is 1 ½ months old When we try to sell Fluffy the baby rabbit Then we should be told that he’s too young
- 39. Acceptance criteria vs.Scenarios Given a pet is below recommended selling age When we try to sell that pet Then we should be told that the pet is too young
- 40. Acceptance criteria vs.Scenarios We shouldn’t be able to sell pets younger than the recommended selling age
- 41. Exercise Can you derivesome scenarios from these acceptance criteria? The user should be able to add and remove bold, italics and underlines. When browsing an item, users should be able to see what other users who browsed the item bought. Pets shouldn’t be listed for sale until they’re old enough.
- 43.
- 44.
- 45.
- 46.
- 47. Story A slice through afeature to enable faster feedback
- 48. Scenario An example of howthe system might behave from a user perspective
- 49.
- 50.
- 51.
- 52.
- 53. Exercise Who are yourstakeholders?
- 55. Is there astakeholder for whom this application will not meet their goal?
- 56. Are all ofthe stakeholder’s goals met by this? If we could achieve it with pixies, would it be enough?
- 57.
- 58. BDD Less Rework Developers Testers DeliberateDiscovery skills Testers
- 63. Real Options Options havevalue. Options expire. Never commit early unless you know why.
- 64.
- 66.
- 67. A Gantt Chart… 11 1 3 3 2 2 1 2 3
- 68.
- 69.
- 70. If a projecthas no risks, don’t do it.
- 71. Prioritizing for deadline $$$$$$$$ $$$$$$$$ $$$$$$$$ $$$$$ $$$$$ $$ $$ $$ Shipped(1 year) Not Shipped Deadline
- 72. Minimum Viable Product $$$$$$$$ $$$$$$$$ $$$$$$$$ $$$$$ $$$$$ $$ $$ $$ Shipped(2 months) Not Shipped Not Shipped Shipped (2 months)
- 73.
- 74.
- 75. Cynefin Simple ComplicatedComplex Chaotic With thanks to DavidSnowden and Cognitive Edge
- 76. Cynefin With thanks to DavidSnowden and Cognitive Edge Disorder
- 77. Cynefin SimpleChaotic With thanks to DavidSnowden and Cognitive Edge
- 78.
- 79.
- 80. BDD works reallywell… …hereish.
- 81. Exercise Help me stop thespammers!
- 82.
- 83. Goal Scenario Goal Feature A Real Project Vision Goal Capability Capability Feature Feature Story Story Story Scenario Code Code Code Whoops, forgot Oops,didn’t know about that… Look what I found! Don’t need this… Can’t remember what this was for…
- 84. Goal Scenario Goal Feature A Real Project Vision Goal Capability Capability Feature Feature Story Story Story Scenario Code Code Code Whoops, forgot Oops,didn’t know about that… Look what I found! Don’t need this… Can’t remember what this was for… Um Er… Oh! Oh F… Dammit! Hmm! That’s funny! Ooh, look! Interesting! Sh..! Oops!
- 85. We’re uncovering betterways of developing software by doing it Vision Goal Goal Goal Capability Capability Feature Feature Feature Story Story Story Scenario Scenario Code Code Code
- 86. We’re discovering howto discover stuff by doing it Whoops, forgot Oops, didn’t know about that… Look what I found! Don’t need this… Can’t remember what this was for… Um… Er… Oh! Oh F… Dammit! Hmm! That’s funny! Ooh, look! Interesting! Sh..! Oops!
- 87. Different levels ofgranularity
- 90. Risk (Newest Stuff)First Vision Goal Goal Goal Capability Capability Feature Feature Feature Story Story Story Scenario Scenario Code Code Code Feature Goal Capability Scenario Code Story
- 91.
- 93.
- 94. Exercise What should yourboard look like now?
- 95. Boring! Given Fred hasbought a microwave And the microwave cost £100 When we refund the microwave Then Fred should be refunded £100.
- 96. Interesting! Given Fred hasbought a 120kg fridge-freezer When we refund the fridge-freezer Then um…
- 97. Exercise Can you derivea more interesting scenario from these acceptance criteria? The user should be able to add and remove bold, italics and underlines. When browsing an item, users should be able to see what other users who browsed the item bought. Pets shouldn’t be listed for sale until they’re old enough.
- 101. Fred Buyer 999 LetsbyAvenue London N1 0UC By Spiking Fred Buyer Save New
- 102.
- 103.
- 104.
- 105.
- 106.
- 107.
- 109.
- 113.
- 114.
Editor's Notes
- #5 Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.
- #6 Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.
- #8 This is actually two scenarios.The first scenario is concerned with payments. The second scenario is concerned with refunds. The first scenario is setting up the context for the second scenario.Talking through scenarios like this is absolutely fine. If you capture them, you might want to separate the two scenarios. As we’ll see later when we start looking for different outcomes and more interesting scenarios, once things start getting complicated these scenarios can be hard to maintain.Usually, if you see this, you’ll find there are either two different concerns in play, or that one of the scenarios is redundant.
- #9 There are tools available which will take your English-language steps and turn them into real automated regression tests! Cucumber, Cucumber for the JVM, SpecFlow and JBehave are all examples of system-level BDD tools. There are others which run against smaller elements of code or classes, such as RSpec and MSpec, but you don’t have to worry about those unless you’re a developer.
- #11 However, the conversations are the most important bit, so start with those.
- #12 Remember that the point of BDD is to create working software. If you find that it’s getting in the way of that, you’re probably focusing too much on the process, and too little on the goal.
- #13 A lot of teams that use BDD insist on having very clear examples for everything they attempt. As we’ll see later, some things resist well-defined outcomes, especially when they’re very new or innovative. BDD should be a collaboration tool, not a contractual one; it’s about trying to understand what the business want, not making it “their fault” if we end up producing the wrong thing.
- #14 We should always be looking for what we want next, or what we’ve got wrong, or what we could do differently.
- #17 These were some of the ideas I came up with. Others might be relevance, unexpectedness and surprise, being funny… these can all come into your scenarios, too. Make them memorable.How many people said, “These are things I value in conversations…” and started listing them, and how many shared stories of conversations they’d had? We are “homo narrans”; we learn best from stories.
- #18 When I spoke to the Head of Client Management, I said, “Given a client manager has some clients, when he logs in, then he should see his clients. Given he has no clients, what should he see when he logs in then?” I was thinking about the case when they had an empty list of clients.But the Head of Client Management said, “If you’re a client manager and you have no clients, I’m about to fire you! Get on the phone and get some clients!”From my dev perspective, I was worried about empty lists. From his perspective, an empty list was a business about to be bankrupted. So that taught me quite a bit about the domain!
- #19 If you find yourself talking in ways that seem unnatural, you’re probably thinking too hard about the solution, rather than the problem. This is a very solution-focused scenario. Also try and avoid any reference to the UI, as that’s part of the solution space too.
- #20 “Should” is a magic word that allows us to question whether an example really should happen.
- #21 Should it happen now, or should it happen later? Or at all? Should it always happen? Is there a context in which it doesn’t happen?
- #23 This is the pattern I call “context questioning”.
- #26 This is the pattern I call “outcome questioning”.A pixie is a small person. If you’ve ever read Terry Pratchett’s “Discworld” novels, you’ll know that when you take a photo in the Discworld, a little goblin or person inside the camera quickly paints the picture for you! I sometimes find it helpful to imagine that there are similar tiny people inside all of our machines, painting on the inside of our computer monitors and sitting crouched in our cash machines.As a developer, I love writing code. I can’t help it! So as soon as you start talking to me about the problem, I start writing software in my head – moving to the solution space. If I can imagine that pixies are going to do the job instead, it makes it much easier to think about, and question, what the pixies should do, instead of the implementation of it.
- #27 I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.
- #28 I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.
- #29 These are two separate aspects of behaviour, so you probably want to put them in different scenarios. It’s OK to get this wrong, though, and if someone comes up with an interesting outcome, it’s probably better just to capture it quickly. Remember that it’s more important to keep the conversation fluid and allow ideas to flow than to do it “right”.
- #30 These are not two separate aspects of behaviour. This is one transaction. It needs to happen in the same scenario, because we can’t ship one without the other. That just isn’t useful.
- #31 If you have a scenario that gets like this, you might want to start splitting it up. Nobody is really interested in talking about all these outcomes at once.
- #32 This is even worse. Focusing on the GUI ties you to a particular GUI. If you ever have a search box instead of a drop down, this is going to be a maintenance nightmare. I can tell from this scenario that whoever wrote it hasn’t actually had any conversations with anyone!
- #33 Transactional outcomes often have two different outcomes for two different stakeholders.Imagine paying someone money online. You want to have some kind of confirmation, don’t you? Would it be OK to pay the other person without getting that confirmation? Or get the confirmation when you haven’t paid? These kind of outcomes have to be shipped together.
- #34 As you talk through different scenarios, you’ll find new requirements. If you’re after an MVP (Minimum Viable Product) – the smallest thing that you could usefully ship and make money from or learn from – then think about whether you really *need* to ship the scenario or not. For instance, you could usefully deploy a cash machine which doesn’t work for people who have overdrafts, and it will still cut the bank queues down.
- #35 Another benefit we talked about is that developers start using the language in the code, so that they can talk more easily to the business and their code is easier to read and more maintainable.
- #36 This is a scenario with specific data. We can’t tell from this what the actual rules are. It’s an exemplar; an example made to *illustrate* behaviour. It’s not really a description of the behaviour.
- #37 This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It’s a description of the behaviour which is true for all the contexts mentioned… unless you can think of another context which changes this!
- #38 We don’t need to phrase things as GWT if the scenarios can easily be derived.
- #40 This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It gives us the rules for all pets, not just rabbits. If someone started with this, we could ask them, “Can you give us an example?” Using concrete examples with real baby rabbits entices our imaginations in a way that abstractions don’t. I bet you even have an image in your head of what colour Fluffy is too!
- #41 There are multiple ways of phrasing acceptance criteria. If we can’t imagine scenarios from the criteria then we can create some to help illustrate the behaviour. It’s perfectly OK to capture obvious scenarios in this form – you don’t have to write *everything* down! The trick with BDD is to get to the things we’re discovering which are new as quickly as possible.
- #42 When we talked through the examples, a lot of them read as acceptance criteria. I ask concrete questions like, “What’s his name? Can you think of an example of text that Fred might want to make bold? Can you think of an example of that?” Even just repeating “Can you give me an example of that?” usually helps reduce abstract acceptance criteria to something that really fires the imagination.
- #43 When Chris Matts taught me Feature Injection, he explained it in much the way I explained it to you. However, he has some different emphasis that’s worth reading, and is strongly aligned with the later sections on differentiation. Here’s his article on it: http://www.infoq.com/articles/feature-injection-success
- #44 There’s always someone who cares about the project; who has fought to get the budget for it, or perhaps funded it directly. This is the project owner. Everyone else is a proxy.
- #45 As well as the project owner, there will be several other stakeholders whose needs have to be met in order to go live. Often these are “gatekeeping” stakeholders – security, support, audit, legal, etc. You can engage these stakeholders before-hand and get some tests for their goals.Tom Gilb is pretty big on quantifying goals. Here’s a good article on it: http://projectmanagement.atwork-network.com/2012/03/20/qa-tom-gilb-on-quantifying-project-objectives/You may also find my blog post on identifying stakeholders across the whole value stream useful: http://leansystemssociety.org/value-streams-are-made-of-people/
- #46 To deliver the stakeholder goals, we look to see what capabilities are needed. A capability is “the capability to do something”. For instance:The capability to trade copperThe capability to book a holidayThe capability to comment on an articleThe capability to calculate counterparty exposureetc. We can also find smaller capabilities within larger ones if we need to. A 1-year, enterprise-wide project in a trading company we used this in had about 30 capabilities for the whole project, some of which were – in a rough estimate – 10 times smaller than others. Capabilities may also be principles that extend across the whole project (security, performance, etc.) They *all* have stakeholders, even the ones we refer to as “non-functional” or “technical”. Working out who the stakeholder for a requirement is, and phrasing it in terms of the business benefit, can really help to narrow down what actually *needs* to be delivered.
- #47 Some capabilities will be delivered in the form of software features. There may be one or many features related to a capability. For instance, in order to comment on an article we may need user registration, comment reporting (in case of spam, vulgarity or libel), and the comment box itself.The features that we choose to implement may change frequently during a project, especially if the capabilities we’re delivering are new. Capabilities don’t change often, though, so one trick is to find the newest capabilities, and work out a way to get feedback on those quickly!More on that in the differentiation / Cynefin section.
- #48 The reason we split features into stories is to get feedback and trust. Showing that you’ve delivered *something* that the stakeholders can see and play with is usually more valuable than trying to get a whole “complete vertical slice”. If there’s a way to show progress or get feedback more quickly, do that. Why code an entire slice if you can throw something smaller away?
- #49 Scenarios can be used to help discover the scope of features and capabilities, and to split features into stories. If we can’t think of an example in which a capability or feature proves its value to the business, maybe it won’t…
- #50 And finally, we get to code.
- #51 And later on in this talk, I show why this doesn’t actually work as neatly as this diagram shows But it’s a useful model to bear in mind for the moment.
- #52 We focus on the capability wherever possible because it gives us options for changing the lower-level steps beneath. The features we use to deliver a stakeholders’ goals often change, but the capabilities the business needs to meet those goals rarely do.
- #53 We focus on scenarios in BDD because it’s the place where the technical, problem-solving developers and the non-technical business analysts and problem-finding testers meet.
- #54 Who are the stakeholders for your project?Are there any which are missing? Are there capabilities that are simply delivered as an industry standard? Do you actually need them?
- #56 Remember the “context questioning” question? (Do you?)This is what it looks like when we apply it at the stakeholder level.
- #57 This is what outcome questioning looks like (do you remember that?)We can also do this for the other levels. Is there some context in which this feature won’t be usable? Is there some market context in which we won’t make money with this?
- #59 Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.
- #60 Here’s how evil testers are. Adev once asked me, “Why do we need testers, if we’re doing automated testing and having conversations around scenarios?” So I wrote this on a napkin. “What’s in the middle?” I asked.
- #61 “It’s a 3,” he said.“Put your tester hat on. What’s in the middle now?”
- #62 “I don’t know,” he said. “I mean, it might be a 3. But if I’m a tester, I’ll ask.”“That’s why we need testers. Of course it’s a 3, but a tester thinks about what really ought to be there, and we devs just fill in the gaps.”Then I showed it to a *real* tester.
- #63 “Might not be a 3,” the real tester said.Evil. Evil! And very, very, valuable.
- #64 For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.Automation is also a commitment!BDD, done well, helps us find the right balance between conversation and prototype.
- #65 If you don’t have actual testers, get someone to play that role. Someone who *isn’t* a dev. Us devs are very good at abstraction, and will start solving a problem before we see the whole problem. I don’t believe that an awesome dev can also be an awesome tester, or vice-versa.
- #66 That’s just how you pronounce it. Cynefin is a way of making sense of problems, and working out what kind of problem you have (relatively; the boundaries are fuzzy). This is important because…
- #67 This is how requirements have traditionally been gathered. Stakeholders are used to only having one chance to get everything they want, so they put in things that they think they *might* want. Even in Agile, we frequently have these Waterfall habits. How many projects have you been on where analysts or PMs spent time “grooming the backlog”?
- #68 Traditionally, we tend to do the most valuable things first. This gives us milestones. We normally manage these with a Gantt chart! But we’re *Agile* now, so let’s slice things up into stories…
- #69 …and then…
- #70 Bingo! Our big bucket of requirements has become a backlog. Now, we can start with the most valuable features. But really, why are the others even in there? What do we actually *need* to do to release something valuable?What if one of those 1s was really valuable, and only needed a 2 or 3 to go with it to release it? Why would you do all of them?
- #71 This is a great book to read. All projects have something new associated with them. If they don’t, get the experts in to do it (for instance, a SAP rollout).
- #72 We normally do this because we think that a deadline is the risky part of the project. I find a lot of deadlines are purely political anyway. I don’t know about you, but I hate working weekends and evenings just so a PM can look cool because they got their project in “on time”!
- #73 What if there was some aspect of the project that was differentiating? How little could we get away with doing just to get that one differentiating feature out of the door? Now we’re making money earlier, and if it turns out that our feature is too hard or it doesn’t rock the market, we haven’t invested huge amounts of money.
- #74 The summary of the next few slides can be found here:http://lizkeogh.com/2012/03/11/cynefin-for-devs/http://en.wikipedia.org/wiki/CynefinAnd this article is worth the money IMO:http://hbr.org/2007/11/a-leaders-framework-for-decision-making/ar/1The short version: There are different kinds of software.There are some things we do which make our project different to other, similar projects. Even if the only thing we do different is that it’s meant to be maintainable, or we’re doing it in HTML5, or we’re doing it for this new customer with these few new requirements, there’s always a reason we do the project, and the reason is something that didn’t exist before. People have differentiators, projects have differentiators, and so do whole organisations!If we make a cameraphone for the first time, it also has to be able to make calls, receive calls and look up numbers, otherwise it’s just a camera. These are commoditised requirements.There are also some pieces of work that are urgent and unplanned – production bugs that we have to expedite, for instance.And lastly, we have katas – simple problems with very well understood outcomes, which we often use as exercises to try out other, more complex ideas.
- #75 Spoilers happen when we see someone else’s differentiator and want it for ourselves. Eventually the differentiators become so spoiled that they’re commoditised. Everyone now has phones with cameras on them!
- #76 This matches the Cynefin framework.In the simple domain, we can understand problems easily and fix them. Cause and effect are tightly coupled, and we work by categorizing the problem.In complicated domains, we need expertise to understand the relationship between cause and effect, but they’re still predictable. We work by analyzing the problem.In the complex domain, cause and effect are only correlated in retrospect, and we can’t predict outcomes. They emerge. We have to probe, or run experiments, to understand what happens. The experiments must be safe to fail.In the chaotic domain, cause and effect aren’t correlated. Chaos is short-lived, and often very destructive. We have to act to stop our house from burning down or someone from bleeding to death!
- #77 There is a fifth domain in which we’re not sure which of the other domains dominates. So we usually act according to our preferred domain.Developers, for instance, love working in complex spaces, so they will usually take a complicated problem andautomate it, turning it into a different, complex problem.Some managers love command-and-control, which works very well when an urgent situation requires people to act, but not so well when you need people to interact in order to get an emergent outcome.
- #78 Along the border between simplicity and chaos lies complacency, which results in a small cliff-edge, like the fold in a sheet. It’s very easy to tip into chaos, and hard to get back out of it again without going all the way round all the domains!
- #79 When I showed you Feature Injection, I showed you a method of breaking down problems into smaller and smaller pieces. But we know that only works for problems which are well-understood, and for which expertise is enough!We have an expression, “Frog thinking vs. Bicycle thinking”. You can break a bicycle into pieces and put it back together again, but you can’t do that with a frog!
- #80 For things which are new, we can’t break them down. We don’t know enough about them. Breaking them down will give us the *illusion* of certainty without giving us certainty!Instead, in this space, find something we can *try out* and learn from.
- #81 On the left, you’ll start hearing the language of uncertainty.On the right, you’ll see people getting bored.BDD is brilliant for learning more about the domain in the middle, and for helping to work out when you don’t need to have any more conversations and can start coding something – either because it’s well-understood, or because it’s time to try an experiment!
- #82 What capabilities do I need to deliver if I want an app to quickly report text spammers to my mobile phone company?Which of those capabilities do we know have already been delivered?What’s the scope of this project? Would it be valuable to do it for just “3” (my network)? How about just spam containing “PPI”? What else would we absolutely need in order to release that safely?If you released that as an MVP, what would be the next thing you added to it? Another stakeholder, or another feature for “3” and me (Liz)? This is how we do release planning!
- #89 Conversations are a reasonably small commitment.
- #90 This book is all about Real Options, and I recommend it.
- #92 On one project, I got them to list the capabilities of their application. They always talked in terms of the 3 main architectural components, so we listed them in terms of the components’ capabilities.“Put a red dot on anything you haven’t done before,” I said.We estimated in very large-scale points. “Which is the smallest? Call that 20. Which is the biggest? How much bigger? Call that 400. Is there something in the middle that’s about 200? Fantastic; rank the rest.”After they’d finished, I said, “Now double everything with a red dot on, unless you can think of a good reason not to.”This included risk associated with people, process and technology… so anything where they were unclear about how it would happen, or who or when it would happen with, as well as new problems the company had never solved before.I now have a much better way of doing this: http://lizkeogh.com/2013/09/05/capability-based-planning-and-lightweight-analysis/
- #94 The team broke off different capabilities and the analysts split them into features. If the devs decided a feature was too big for a sprint, they split them into stories using scenarios. Mostly the scenarios were end-to-end.
- #95 If you were to take on the ideas in this talk, what would you like your Scrum or Kanban board to look like?
- #96 The ideas about uncertainty and certainty – and complexity and complicatedness -mean that this is a *really boring* scenario. This teaches us nothing, and if all our scenarios look like this we are yawning.
- #97 But by changing the context, we can suddenly discover uncertainty. Fred didn’t walk back into the store with a 120kg fridge-freezer on his shoulder… so, what do we do now?
- #98 Can you think of any scenarios which actually teach us something about our domain? Anything which might have more than one answer that’s “right”? Or anything which you can’t think of what the right answer is?
- #99 Those examples – the ones where we don’t know the answer and we have to try something out - *those* are the ones we want to find the most.
- #102 Hard-coding data behind a UI is a great way to get feedback on a new UI. You can also do things like send hard-coded messages over a message bus to test the performance, etc. Do whatever is new, first.
- #103 In any architecturally complex system, the feature we’re building will only need part of that system. By building just enough for the feature, we can get information about whether our chosen architecture will suit our stakeholders’ needs while leaving our options open elsewhere in the system for the future.
- #104 We code just enough of the architecture to get our feature working.
- #105 Sometimes showing an architect that you’ve left it open for change, so that it can be moved to the “ideal” architecture later, is enough. The best architects love this, because it lets *them* try things out and be wrong… and options have value.
- #106 We can look at different inputs and get different scenarios, then decide which of those inputs to do…
- #107 Or we can do the same things with outputs.
- #108 Sometimes the format of input and output is the same, but the content of output will change depending on internal rules. For instance, Amazon ships orders over a certain price for free, and Amazon Prime users get it more quickly.
- #109 This was a real project I worked on which had something similar. All those little squares are user stories. How can we possibly spot uncertainty when we break everything down up-front like this?Instead, I recommend breaking things down to the capability and maybe the feature level, then letting the devs break those down into stories based on what they think they can usefully do before the next time they’re due to see stakeholders for feedback.
- #110 Remember the Asteroids game? The big asteroids travel very slowly. The smaller asteroids travel faster. The way to die quickly is to split up all the asteroids into tiny little ones that you can’t keep track of. If you do this with your stories, you’ll find your project just as hard to handle. Take one big chunk at a time, finish it off, then go for the next one.
- #112 Think of the last time you did a long project, > 9 months or so.How long would it take to do the same project again with the same people, same technology, same requirements, same everything… just *again*?That’s how much of our projects is taken up with learning! The more innovative the project, the more learning will go on. If you’re into Theory of Constraints, you can think of a project as a factory which processes ignorance into non-ignorance through learning. By focusing on that, we go faster.If you haven’t come across Theory of Constraints, here’s the book to read: EliyahuGoldratt, “The Goal”http://www.amazon.co.uk/The-Goal-Process-Improvement-ebook/dp/B002LHRM2O/Along with “Waltzing with Bears”, it’s one of my two most recommended texts to get hold of. It’s also a fiction book, so a very easy read!
- #113 Here’s my stand-up template. Using this will help the team focus on the interesting things that people find out, which will accelerate the learning of the whole team as well as enabling them to respond to each other’s discoveries.As another hint: PMs, or anyone with authority, should speak last if at all. If they start the meeting off it will automatically turn into a status update meeting to that person.Those of you telling the team who should speak next… what would happen if you stopped doing that? If they had a beanie toy, or a ball, to throw to each other to determine the order in which they went and who spoke? What amazing stuff *could* happen?
- #114 Remember this?Have fun with the conversations!