Ok, I discovered extreme programming in 2000 and it transformed the way I work as a developer, even though the organization I was in was not an Agile organization, and I was basically doing XP 4.1 within a more traditional organization and I found it hugely valuable and it’s sort of a success I wanted to continue and it’s very difficult to get organizations to change from within and get the visibility I wanted and that ultimately led me to being a consultant and helping organizations coming in from an external point of view.
Well, in the early days I was mostly running into problems with people, organizations were just completely unfamiliar with anything about Agile or heard little bits of it, had strange misconceptions. Today there’s a lot of enthusiasm about it, but they still don’t know much about it. But they’ve heard this is something we want, this makes people faster, cheaper, a lot of times they still don’t get it, but now they are at least asking for it even though they don’t know what they are asking for.
Right, so these are the things, in my mind the three fundamental views of the work that it’s being done in general, and when there is misalignment between these, there are problems. And so there are a lot of Agile techniques that work towards bringing these things together and still, in practice, I find that a lot of times some of that alignment happens way late and so it causes rework, it can cause finger pointing, there are these different silos, people still do the programming and then do the testing and the testers get crunched at every iteration rather than at the end of the project, it’s the same problem, and they end up with something that surprises the business “no, that’ not what we meant”, and ultimately they have to agree on this at some point.
In my experience if they get that agreement before actually building, doing it in little pieces, then that helps build the right thing better. In the communication between these three points of view, don’t have to be roles, but points of view, is huge for actually clarifying the work. So I call this “the three amigos”. So the business knows more or less what they are looking for, what advantage they are trying to get, the programmers know something about how to achieve this, what’s possible. The testers are the ones bringing the point of view of what can go wrong, what are the edge cases, where are the things to watch out for. Getting this conversation which looks at, from three different ways, you can really get some very explicit ideas about what you are trying to do, not just this vague thing the business started out with, but get that into sharp focus with some examples, because people communicate better with examples than they do with abstract terms.
If there is a discussion “is this a bug or is this not a bug”, that’s a real common thing, is this a bug or is it a feature, is it an enhancement, when they are differing opinions like this it means they haven’t talked about it enough yet.
5. Is that something that usually shows itself first from the testing side?
Well, that tends to happens once a tester gets into it, but it can also show that maybe the programmer and the tester have come to an agreement, but then they show it to the product owner and they say “no, that’s not what I meant” or show it to some other stakeholders and say “oh, this isn’t going to work for the people I work for”.
6. Why do you think this particular talk is such an important one right now?
Stephen Covey says “begin with the end in mind”, this is your goal, being clear about what your goal is helps you hit it, maybe there is some ambiguity in what your real goal is, some companies, some organizations are kind of feeling their way, they’re working on something totally new that nobody’s ever done before, so they are not quite sure exactly what it is, but they need to get some clarity on how will they know when they see it, some guidelines to steer these things in the right direction.
Well, in cases where you really don’t know it’s a lot fuzzier and you have to work harder at it, but in typical organizations these days, they really do have a good idea of what they are trying to accomplish, you’re trying to just hand it off to the development team to get it done, but a lot of times the business hasn’t thought through all the ramifications, or sometimes they are over specifying, “we want this” and then the programmer might say “that’s really hard to do, would this work for you?” and they would say “oh, that’s even better”, but they didn’t know it was possible. That sort of thing happens or they specify what, the business says they want and maybe the tester asks “in this situation where this data is not available, what would you want to have happen?” or “if this goes wrong, this other system goes down, what should happen?” and the business people don’t think about these things typically, the programmers may or may not, but having these three points of view, again they are not necessarily roles, they tend to be in traditional IT departments that we are trying to get to work in a better fashion, but they don’t have to be roles they just have to be points of view.
Well, my experience is that if you can boil it down to examples, explicit examples to illustrate what you want, because people talk better about examples, people are working with personas, use them to drive examples, that’s one way of doing it, other people are doing simpler approaches, but coming up with explicit examples that illustrate the abstract concept in ways that you think it’s important, then you may miss some, but really trying to get all those and think you know that’s the easiest time to think about what the possibilities are as you are kind of mapping that out and then that makes it easier to say one, how big it is if there’s a whole lot of examples, obviously it’s a bigger problem than if there’s only a few examples, then you can split the problem up by that, maybe these examples illustrate something that is likely to happen and this example was something that maybe it will never happen, we don’t know and if it did happen maybe we could do a manual work around and so we can put that on the back burner, we don’t need to do that one, that part of it right now because it’s low risk.
9. Sounds very much like behavior driven development, is that kind of a good comparison for it?
Behavior driven development is part of that, yes.
10. In what would you say it kind of differs?
So, people talk about behavior driven development or acceptance test driven development, but quite often I find there is still getting that clarity kind of lagging behind, people have a hard time really doing this early and in close collaboration with the business and so it’s just cranking up the nob a little on that.
So, what I recommend now is to have these conversations a little bit at a time throughout the sprint in preparation for the next sprint, so that by the time you get to planning the next sprint, what goes into it, you have this information. Now you don’t need to have the whole team involved in every discussion, a lot of times just three people is good enough and you can work a little bit with these three people, and then the next day work on some other aspects with different three people, if you’re doing traditional Scrum you’ve got one product owner they would possibly be involved in all of them. But sometimes even not, sometimes maybe they’ve got a proxy standing in for him for parts of it, maybe a user experience expert, who’s working on some aspects to represent the business view in that and get all this stuff done so that when you’re deciding what work you are going to do in the next sprint you already have a real clear picture of what that work is, what the possibilities are to select and you can make better decisions then.
To me that’s typically part of the business point of view, sometimes you’ve got user experience people who are also implementers, so they’re playing both sides of the fence. So this three amigos concept is a model of three important viewpoints but a lot of times there’s more than three people involved, you might have the product owner and the user experience person to get that extra view, you might have someone from the security department to make sure we’re protecting against these threats, attacking the system, or maybe from the accounting department because not only are we concerned with the customer experience but we need certain accounting controls, that’s another point of view that needs to be represented, so depending on what you are working on, the three amigos may be more than three people.
Todd: Those are the three important viewpoints but there are other important viewpoints that come in as well.
Right. That’s sort of a case by case basis.
Todd: So, you’re saying it should go on during the previous sprint or the current sprint should be going ahead.
Right, so that’s just in time but before saying “this is the work we’re taking on”, because when you’re taking that work on you want to have a pretty clear idea of what that work is so you know you are taking on the right work, right amount of work and the most important work, and also, once you’ve got these clear examples it’s easy to create automated tests from those examples, test those examples and you can do that before the programming is done. Now, you may have to wait until some programming is done to actually hook those tests up to the system, so it’s not done until it’s all done, but that’s ok, you can then see these expectations of the systems, all these examples, going from red to green and get a real clear picture of the progress at least for the foreseen functionality. You still have to check, is there something we forgot about, have we messed something else up that we weren’t looking at, maybe all the functionality is there but the screen is completely white so a user can’t use it, but the test tool can.
Todd: Of course, once the users get their hands on it, who knows what happens at that point, because their usage scenario can be completely different than what you were planning for.
That’s right. You may discover that your analysis of the original problem is completely wrong.
Typically, just taking a user story and then thinking about what’s the acceptance criteria for this user story, what examples do we need to insure that we’ve met that acceptance criteria and so we’d have to test different scenarios to be sure that we’ve got all the things we expect of this acceptance criteria, and so that gives us, we want all the essential examples. Dale Emery says “everything that matters and nothing that doesn’t matter”. So, try to get it down to sort of a minimal set but that covers everything that’s important to you.
I don’t think it really happens in silo-ed departments.
Todd: Specifically, it doesn’t happen, because they are separated. When you have a collocated team, it’s supposedly cross functional, why is that still not happening?
Well, I think the biggest problem is that people think they have agreement and communication when they don’t. So, the product owner says “I wanted to do this”, “ok, we can do that” but they may have a different picture of that means and until they examine the details, they may not realize that maybe there are some holes in that description or they are saying the same words but meaning different things by them.
Todd: And so by having the examples they can get closer to being on the same page.
You can think of the examples as a test for the communication of the acceptance criteria. If the product owner says “I want the system to do this” and you say “ok, well, so in this case it should do this” and they can say yes or no, that validates that the communication has happened and it’s clear.
The biggest challenge in my experience is that people are reluctant to spend, they think it’s a lot of work so they are reluctant to spend that work upfront, it’s a lot of detail, the product owner may think “I shouldn’t have to know all this detail, they can take care of that”, which is perhaps ok if you get what you want but you don’t always, so people think “it’s not necessary to do this, we can wait on that” and then they get into a situation where all of sudden “this piece of work is much bigger than we thought” or “there is some disagreement in what it is supposed to do” or “we don’t know what to do in this situation, who knows, where can we get this information?”. So problems come up down the line, that could have been discovered by a deeper discussion prior to starting work on it.
Todd: So, do you find that it’s different, you mentioned it seems like a lot more work, probably in Agile teams, what about in teams that are more silo-ed, they have requirement documents so they already do a lot of work upfront, they may not have the same examples, they may still be missing those though they may have hundreds of pages of documentation.
Right. So, typically, those are not written as examples, those are trying to write in abstract terms what they expect, so they write more volume of abstract terms to prevent somebody from misinterpreting it, but it’s still easy to misinterpret, and it’s so silly. In my mind, look at the publishing industry, to put out a book there’s an army of people involved to fact check things, to look for spelling mistakes, editors are looking for clumsy wording, there are a lot of people involved to try to get these sort of mistakes out, and here we think we can hand off to some technical person who maybe took one class of English in college, “write something that nobody will misinterpret”.
Well, it depends on the story, I would say that hundreds is way too big for a story. In fact I like really small stories, if you start getting above five to seven you might want to consider splitting it down to that level so that you can see the progress in a finer grain. Some people say “oh, but we’ve got to deliver all of them anyway”, it’s ok, you can do that but tracking the progress by the examples that are working is still very powerful, if the example doesn’t have to work, you don’t need it, if it has to work you mind as well list it, it’s kind of to say “well, we don’t need to make this example clear”, it means that we don’t have to make this work, and sooner or later they will want it to work, so you’ve got to come up with that example anyway.
Todd: And that can be a good guide on the size of your stories as well, if you find you have ten or 20 examples per story, maybe it’s an indication that your stories are not necessarily as narrow as you think they are.
I found that it’s a better guide than trying to do task breakdowns, because people forget about tasks that are involved or they don’t realize this is a simple task but they are making assumptions about the state of the code and then get in there and find “oh, this wasn’t written this way at all, this is hard to do with this code base” and I think this is a more stable way of looking at the size of things, you’ll still get surprises but they’re just estimates anyway.
Todd: So, in the honor of liking examples, give us an example of what some good examples might be that you would find for a particular story or scenario.
Well, you think about the essence of what you are trying to do. Say you’ve got an e-commerce site and you’re shipping physical goods and one of the features might be to calculate the shipping cost for US Postal Service and you think about “oh, well, what’s the way, we need to do an example for different zones to check that it handles that, we may need to do an example for oversize packages”, and then maybe we decide “we want to extend this, we want to be able to ship UPS also”, maybe there’s certain things that Postal Service won’t take and UPS will take, examples for those. You can see clearly that some of those examples are more related to each other than others, shipping materials that the Postal Service won’t take by UPS, that’s kind of a very different example than checking a five pound package and a 75 pound package.
Well, a lot of it has to do with talking about this together, so common reference, common language that they are talking about, so how they express it isn’t so much, but some of this you could do as a table, so given postal rates for this year, then if we are sending a package of, a standard size package of this weight to this zip code, then postage should be this. They come up with some examples, vary the zip code for different zones, vary the weight for different weight categories, maybe one that’s overweight and then expect that it says you can’t ship this, or something like that. So that would be one set of examples for one slice of the bigger shipping story.
So these I’m talking about at the business level, so when the programmers are working on this then they may write other tests, unit tests at the technical level, to help them write the code, they want to make sure “yes, we’re drawing the data from this table, if we put data in this table it comes out here”, which is not a business level thing, they want to check that the answers were correct. And the examples I mentioned here they are sort of spot checks, we’re not checking necessarily that there is not a mistake somewhere, maybe somebody entered something wrong, if you exactly put in 5.026 pounds then something goes wrong because of some strange bug, being reasonable to check representative data points to feel confidence.
Those make for very fragile examples, very wordy, very implementation dependent. Then instead of just being a button to click it becomes a drop down say, then your example is wrong and it’s very hard to understand what this example is getting at, so somebody coming along later trying to read it “why is this?”, maybe the business rules have changed, how do we have to change this because it’s not expressed in business terms but in application terms. It’s better to write the examples from a descriptive point of view of what you expect a system to do, rather than from a series of steps and then you can translate that into the series of steps necessary for the system at this time. So, say we have to write a test for “well, let’s put in a one pound book and a two pound book and a three pound book so that we can and then press the order button so we can check”, that’s not what you want to do. You want to write your examples more in the business terms, the business rules you are trying to check and for something like calculating postage you may not actually want to run these through the GUI, you may want to run them directly against a module that just calculates the postage, it's quicker and easier and changes less. And then maybe you want one test somewhere that checks that the gooey is hooked up to this and when you put in something and click it, you do get a right answer, so then everything is wired up correctly, but you don’t need to check everything through the GUI.
Well, if it’s the product owner it’s really easy, just walk into the team room and say “hey, have you got some time today to talk about some of the stories that are coming up?”, then recruit a programmer and a tester to find some time when you can sit down and look at some of these and start talking about them, it really doesn’t take a lot of ceremony to do this.
They can do the same thing, go to their product owner and say “hey, listen, I think it would be valuable if we talked through some of these in a little more detail” and maybe particularly after there’s been some rework, some problem came up, that’s an excellent time to say “hey, I think we can improve this, let’s talk about the next ones in a little more detail and get clear because we had this misunderstanding, I think we can avoid this type of misunderstanding if we do this”.
Todd: Excellent. Sounds good, I think everyone should go do it now. Thanks a lot, George.
Thank you.
Community comments