 So welcome to one of the last sessions of the day. This is simultaneous phases agile secret sauce I'm James. Sure. I'm presenting if anybody didn't expect to be in this room now as your opportunity to lead All right, so my name is James. Sure. I am an agile guy I've been doing agile for a while now in September It will be the 10th anniversary when I started leading my first agile project and that first project was feature-driven development and Had some success with that other than the project being canceled in the budget running out. It went pretty well so Liked it well enough that one of the team members who had mentioned to me something called extreme programming Even though when he mentioned it to me, I thought it was absolutely ridiculous pair programming Incremental evolutionary design obviously could not work But I had enough success with feature-driven development That I wanted and enough failures with feature-driven development. I was interested in trying some new ideas. So I checked out XP and On my next project tried a few things like test-driven development and and saw that it was good and liked it So when they found what happened to the budget and brought me back. We tried out XP and That was a really big success. I was I was pleasantly surprised with how much of a success it was So my next project for that company. They said this is working pretty well teach it to this other group and That was actually here in Utah and I said, okay, let's try it Let's see if we can get everybody doing this XP thing and we did that for 18 months On a Greenfield project and just again had so much fun on that project best project I've ever been on as Brian talks about people saying from that we're doing projects in this time That was my experience. It was the best project I'd ever worked on so after that I was a contractor I would work with various teams and Went on to work with another team and I realized that if I couldn't do XP anymore. I wasn't really enjoying software development So I became a consultant and decided to teach people how to do XP and here we are today So let's see. I'm also the author of a book called the Art of Agile Development I was a recipient of the Gordon Pascal Ward, which is the Agile Alliance's award for people in the Agile community and I Really really think Agile development is the best way we know today develop software And I also really think that a lot of people today are practicing are really excited about the name Agile and not actually So excited about doing Agile. So when I heard about the Agile Roots conference I said great this is an opportunity to talk about what Agile really is and so I submitted this session on Simultaneous phases, which I think gets at the heart of how we execute Agile and is necessary to execute Agile in a good way So that's what I'm about to talk about. Could we get the lights dimmed? This presentation is here to you today sponsored by the color mauve We're very excited about this. It may make it hard to read. There's some sort of technical problem in the building So if you can't read it, let me know Okay, everybody's seen this before right? It says plan analyze design code test deploy that's sort of the typical phase-based cycle and we do that On the olden days we did in a waterfall over the course of years and the more modern cycle We do it we did it in spiral methodology over the course of several months But we still would follow the same basic phase based approach First we plan then we analyze then we design then we code then we test and finally be deployed Now in Agile, of course, we're working in iterations and after every iteration. We're supposed to have something that's potentially shipable We want to have a potentially shipable increment of code And yet the way we've learned to develop is in this phase-based cycle So we sort of drop this behemoth into the system and we say how are we going to make this work with iterations? Well, no problem. We just make it smaller There we go. Now it's gonna fit just fine, right? We'll put that up there. Oh, that's too big. I'll try again Let's sort of slam it in harder No, one more time. Let's squish it in. There we go. There we have scrummer fall Where we take our scrum Sprints or our iterations and we we sort of put the phases in there We've got a little tiny bit of planning a little bit of tiny bit of analysis Little tiny bit of designing little tiny of coding. Oh, we don't have time for testing and we're not going to deploy this time anyway So as a result, we actually don't have a potentially shipable increment and because we didn't really finish everything because we didn't have time We start our next iteration a little bit late And so we don't have a potentially increment shipable increment that time and well Goodbye So That's why we need simultaneous phases Because in a week if we're developing software in a week that doesn't give us enough time to do independent plan Analyze design Code test deploy phases. How many of you are in a scrum project? Where the amount of testing you have to do increases every iteration or every sprint? How many of you aren't willing to admit it? It's a couple more hands went up how many of you are in a in a System where or doing development where you don't really get things done done at the end of every iteration where there's Some stuff that sort of slops or in the next one Well, most of the hands in the room went up for that one That is why we need simultaneous phases So let's take a look at This iteration life cycle again simultaneous phases looks like this We do a tiny bit of task planning up front at the beginning of each iteration That's maybe half an hour no more than four hours and the four hours. There's a long time to do task planning Then during the iteration we need to do all those things planning analysis design coding test deployment pretty much all at the same time and We're not necessarily actually deploying to production What we're doing is we're creating an automated deployment script so that at the very end there you can barely see it When we're ready to release we push a button and ten minutes later. We're done So that's what we want to accomplish and that's what I'm here to talk about today is how to do this This is a big topic and I made the mistake k wave your hand k k is one of the fine organizers of this conference And she said to me how much time do you really want for this you've proposed it as a three-hour session? How much do you time do you really want? I made the mistake of saying well, I could do it in 90 minutes but And she said 90 minutes great and so here we are So we're gonna be covering a lot of ground in a fairly short amount of time so what we're going to do is we're going to go broad rather than deep and I Also have some exercises because I think talking heads can be pretty dull so Which may mean that we don't have a lot of time for questions So I've tried to balance that but I just wanted to give you some warning in advance We're going to go fairly quickly and we're not going to go into a ton of depth on each one of these things Okay One of the ways we can achieve This of actually doing these things simultaneously is by doing something that Agile proponents have suggested for quite a while and that's have a cross-functional team So we can have a team where we have we oh my goodness Wow I Love mauve I really do so we can have a team where we have customers and Testers and programmers actually working together in the same room. How cool would that be huh? and if we did that Then it would be possible for the customers to be doing some planning at the same time as the programmers are doing some developing And that's one of the ways that we get those simultaneous phases So just to get things moving Can everybody stand up please? I recognize that this is this room is a little bit crowded But what I'd like to do is get the customers on that end of the room which is to to your right that way So everybody who thinks of themselves as a business expert or somebody who works primarily with understanding what the software should be doing go over there Nobody's nobody's moving and everybody who thinks of themselves is sort of technically oriented or a programmer go over here And if you're none of the above Pick a side up against the wall. Yeah. All right. Take a good hard look at the people across the room from you Give them a glare These are the folks that every day you get to work with so Customers that's everybody here. Please spread yourselves evenly amongst all the tables boy There's and if you see a computer there if you like it, it's yours Commitment that goes with the computer All right programmers The rest of you on this side of the room go ahead and spread yourselves evenly among the tables What we're looking for is about the same number of customers and programmers at each table So spread yourselves out So that there's about the same number of customers and programmers at each table now I got some You'll have a chance to talk to each other in a moment. I sort of threw these terms out without defining them I'm using these terms in the the XP since the word so by customers I mean on-site customers people on the team who are business experts who might be product owners business analysts Subject matter experts interaction designers anybody who's responsible for helping understand How what we're going to deliver and how that maximizes the value of the overall product? Programmers are those folks who are actually going to do the technical implementation I actually put non-technical people in that category as well just for the sake of convenience So technical writers go in there as well, but these are the people who are actually Creating the product whatever it may be and I think of their responsibility as minimizing the cost of both creating and Maintaining the software so if we're maximizing value as a team and we're minimizing cost as a team presumably that's going to give us a nice return on investment and Testers now I have a peculiar way of looking at testers I think that if we're going to do simultaneous phases We cannot have anybody testing the software before we release it not in a manual way Because that grow that cost grows over time So in that world Testers are not actually testing the product to make sure it's okay to release They're helping the team understand if they're actually doing everything they can do to create bug-free code And we'll talk about that more a little bit later. So we have planning analysis design code testing and deployment We need to do these things all at the same time. Let's look at them one at a time. So first up is Continuous incremental planning and requirements if we're only doing a little bit of task planning at the beginning of the iteration And then we're doing planning throughout the rest of the iteration That means we have to be doing planning in a way that's both continuous in that in other words We're doing it all the time and incremental and here's how I look at it for the stuff that's coming up really soon We're gonna have lots of detail about what's in our plan for the current iteration We have that all broken down into tasks and we're gonna be working on those tasks for the stuff that's coming up in the future The near future we're gonna have this stories Small descriptions or Holding places for conversation about what it is we're gonna do Further along I use a concept known as a minimum marketable feature some people call these epic stories or just motherhood stories or big things but these are things that are Are sort of bigger ideas about what we're gonna do if a story is draw a squiggly line under misspelled words a feature is We have spell checking and then vision is What it is that we are trying to accomplish? What is the value of this product to the company? Why are we doing it? How will we know it's successful? And you'll notice that all four of these things are present Simultaneously, and this is what I'm talking about when I'm talking about doing continuous incremental planning We're actually gonna be looking at all these levels simultaneously And I'm actually including requirements analysis in here as well because as we're looking at the vision and turning it into MMS We're having to do some requirements analysis to figure out how the vision turns into features and we as we take the feature and turn Into stories we have to do some more requirements analysis to understand how those relate And then when we're actually doing the work we need the customers on site to answer the detailed questions about What color red is the squiggly line? Is it PMS red? That's that's actually a color description That's not an insult to anybody in the room Is it is it, you know bright red or is it dark red? I did business cards once and I asked the printer what he thought he said well It's great except for this PMS red and I was so offended by what he was saying But it turned out he was just describing the color of the The name of the color So So let's just see how this works So during the iteration we develop the software We knock off all the tasks Which frees up some space for the next iteration so we bring over stories and Break those down into tasks and then during the iteration We've got some space in our backlog This is sort of a Kanban style approach and that we've always got a fixed amount of space allocated for each of these things so we pull The next MMF over and turn that into stories and if we've got a little more space We'll pull a bit a few more stories out of the next MMF after that and that frees up some space in terms of our roadmap So we look at our vision and we say what feature fits and we pull that out of our vision and we keep doing this over and over and over always looking at certain Distance ahead in terms of level of detail and always keeping as as work is done always filling in the gaps So this is how you can have your on-site customers Continuously planning without having to do a big Planning iteration or a iteration zero where you're going to do all your plans up front You you look at in detail at what's coming up soon and less and less detail things that further things are out And then as work is done you fill in those gaps Another way to look at it is like this I actually made the other slides because every time I showed this slide people get confused But I put it in here for nostalgia reasons. I'm sorry Yes, well, this isn't very beams I drew this But it kind of looks like his thing so the idea here is that the closer you are to story completion Here's complete to make it more confusing times going the other way than we're used to here's when we're done with a story and The further away we are from completion the broader our view is and the less detailed we are So when something is three months away, we may only have the rough vision of what it is that we're producing When we get closer will have features and stories and then when we're actually working out we're going to work out the exact details So our vision may be produce a word processors or compete with Microsoft Sort of like starting a land war in Asia not necessarily the smartest thing to do but features would include spellchecker tables inline images Stories of course would be things like squiggly is underneath the words an actual specification. Well, what color? What's the ratio of the? White space to squiggly How do we actually want the software to behave when when we right-click that squiggly? How's it going to work? Clear as mud everybody understand this point Good So we're going to do an action and activity What I'd like you to do is is and I want to thank Diana Larson for this idea I asked her what what kind of activity can I do about this and Diana said how about conference attendance? So everybody understands conference attendance. You're all here. So obviously you made it So so think about conference attendance throughout the year And if we think in terms of these planning horizons, that is the further something away is the less detail We have and we get more and more detail as something gets closer What kind of planning horizons you have for your conference attendance? What's your conference your company's overall vision? How? You know, do they say everybody gets 10% of their time at a conference or some other training? Why did they do that and what's what's their vision? We don't need to get a lot of detail. I'm gonna give you about five minutes on this What are the features? So which which types and numbers of conferences did people decide on for this year and when was that decided? When did you decide it? When do you decide on which conferences that people go to and then one of the reservations actually made? Does everybody understand the exercise? Okay, so I'm gonna give you about five minutes to talk about that go and introduce yourselves to each other and Go ahead and work on this Very quickly. What's what's one thing you'd like to say about your conference planning? Can you be more specific? Turn it down the list the more we started to talk about each one of them It seemed like we were just kind of getting warmed up What what details? What the details were? I didn't share this with my team so I'm gonna get in trouble for saying that I felt a little confused about the definition of the areas that you're talking about Like I wasn't seeing eye to eye on one vision Okay, is that because I didn't define those or just do you think that's a natural consequence of of this kind of Anybody else one thing you'd like to say Customers asked a lot of questions programmers gave a lot of answers One more at first we thought we didn't have much differentiation in that time scale between the vision side of the details I said, oh, it's just random people go and they want but as we started talking about it We found out that there is Differentation with it seemed random. There is some vision there is some things that happened six weeks before and the Actual reservations get made at the last possible moment before the price increase Define that this pattern didn't hold Okay, so so for you even though you didn't realize it if didn't think so at first you did see that there's an Overall vision that's been defined. It may not be very clearly expressed and there's I Be happy if those went back down again And The actual conference decisions were made about six weeks in advance and the reservations were made at the last responsible moment Is that is that a fair summary? Okay Well, this was just a warm-up to sort of get you used to thinking in these terms I'm going to give you five more minutes and now I'd like you to pick at your table pick one Of the projects for one of the companies represented at your table and do this exercise again for your real software projects So what are the planning horizons for a real software project for one of your real software projects? When is the vision defined and vision may not ever be formally defined But when is the right the broad idea of what the project is meant to do to find how far in advance? When are the feature decisions made? Winner the detailed decisions made I'm calling those stories, but you may not call them stories on your project but the detailed decisions about what the software is supposed to do and then at the most granular lever when are the tasks defined and The requirements fleshed out If you have time talk about What benefits those planning horizons give you and? What one change you could make To further improve your planning approach now like I said, this is a short session So I'm only gonna give you five minutes for this so get through as much as you can This is in a group at your table. So at your table pick one pick one project at your table so Last week Diana Larson and I did a course called the Art of Agile Delivery and in that course We asked our students to develop software end-to-end from scratch using simultaneous phases in 490 minute iterations and we felt pretty cool that we were doing this because what happens by the end of this course is that They start out the students start out really struggling with this concept by the end. They have no problem So Alistair comes along just as he does now did now and took it away and binged it again and Did a course did a session yesterday where he had people delivering in nine minute iterations And this is why Alistair and I don't get along and so that is why we're doing five minute exercises So so one thing I've learned is that You can deliver in any size time boxes. Maybe maybe 30 seconds would be short If you get used to delivering in that size, so I apologize for the short length of these sessions But the alternative is to hear me talk for 90 minutes and I don't think we'd enjoy that Yeah, and and really there's the ulterior motive So Who did any tables get all the way through all three questions So what what one thing could you do to improve the planning you're planning? Shrink your time and talk to a real customer what Those of you who got through question one What kind of planning horizons are out there? What are you seeing? One one year six months Okay One year for what? Okay, one year for the vision. Did you get to the point of talking about features and What was the time frame on that one? Eight weeks. What about stories? One to two weeks. Okay, like I said, this is gonna be a broad but not deep topic But I just want to give you an opportunity So looking at this to recap if we're gonna do simultaneous phases then we have to do planning all the time We have to do continuous and incremental planning And one way to do so the only way I know is to have a cross-functional team with people on it who are really devoted to Doing requirements analysis and planning we call I call those on-site customers and a lot of people in agile world call them on-site customers and If you try to plan everything advanced down to the last detail You can't do it. You won't be able to do it all before you start development if we're doing simultaneous phases We're starting development at the same time. We're starting our planning and Actually to get to I was just pointing this keynote I think you lose track of the big picture So by having these multiple levels always in mind and by pulling things into the lower levels as you finish iterations I think that gives you the opportunity to One do the simultaneous planning and to keep that your eye on that big picture, which is a problem that I see in a lot of agile teams and Does anybody have any insights they'd like to share as a result of this discussion? What what stood out for you in in this topic? It'd be nice to have formal. It'd be nice to have So I mean everyone wants to have a plan we have a plan, but it's not executed well So we have to have execution and planning at the same time right have to have planning and execution at the same time any other Things that stood out for you. I Think time at the end you know once you finish your project some gap before development starts on the next one to sort of Get people On track. I'm not talking about about an iteration zero But let's say there's people who are working on the vision for the next project We're not necessarily in the team working on the current project There needs to be some way to transfer that without just start the work Before that Preliminary vision was created. Yeah, so there's a Communicator so what you're saying is there's at the beginning at the very beginning before you establish all this you need some sort of project kickoff and I Think I think I would agree with that and I know Diana would agree with that and one way to do that is project chartering Which I think is an important topic that I've completely glossed over And we'll continue to do so the next The next topic I mean we're we're covering a lot of ground here, so The next topic is we're gonna do simultaneous phases in addition to doing this planning constantly and the requirements analysis constantly Or whatever you want to call it some people really dislike the word requirements We also have to do our design and architecture in a continuous Incremental way and in the very beginning this was actually one of the big selling points of extreme programming and we called it evolutionary design and In addition to pissing off the creationist this confused a lot of people so So I've stopped using the word evolutionary and now I call it continuous incremental design, but it's really the same thing So let's just let's just Take a look sort of the traditional approach is we we imagine what's gonna come along each of these points is sort of an idea About what feature we're gonna have in our software so we imagine what's gonna come along We predict the future and we say this beautiful design will fit those needs perfectly and then we start developing and requirements come along and Mostly fit within our design because we've done a careful job and we've thought about what could come up and They all fit within the design we've created Mostly Every so often something comes along that isn't exactly part of what we planned anybody have this experience Yeah, what happens? Just look like that. Yeah, it's her. Okay. We'll we'll collude it in But no problem, you know more requirements come in but they mostly fit No, no worries. We'll take care of that. Like I said, they all fit within our Oh my goodness And And after a while In this case six months Your design starts looking kind of ugly and After two years, it's so bad. You can't even recognize the original outlines or maybe it's five years if you're lucky Does this look familiar to anybody at all? Oh? Yeah. Oh, yeah, lots of hands going up so that's the predictive approach and The idea in continuous incremental design is that we don't predict. We're not making any assumptions about what's coming along When something comes along We make a beautiful design that handles that case and That's it Then something else comes along and we make a beautiful design that handles that case And we just keep on going and then once something comes along that's Similar to something we've already done we can refactor we can look at our code and we can say hey This is just a general more general case of what we've already done and Make that beautiful and by doing this and we another one comes along we make that one beautiful and By doing this we get in the habit of Creating software That can handle anything that comes along So even though some of these dots this is the same Order and position of things that came along in our last slide Even though some of these are way outside of our expectations because we didn't create design for them in advance We don't have any design to collage We just create the design that fits in and the more that comes in the more it tends to come together And you may have noticed Once we've established a space well enough features come in and that's part of the system that we're already capable of handling Now I realize this is pretty abstract. So does anybody want to ask questions about how this applies in reality? Scott thought of was This all looks like in this design The assumption was there will never be any obvious dependencies between anything Therefore we can isolate these things in their own nice little designs We don't have to worry about it until something else comes close enough But everything else is far enough away So there's no obvious need to worry about there being any dependency between them So they don't have to be incorporated in the same design. That's right When when something comes up that's unrelated to anything else you just make that part of the system nice and clean now It's really hard to describe the complexities of real software development and real software design with lines and boxes Or dots and boxes which you know, it's a limitation of the format But the general principle here is that when a feature comes along we implement just enough code to handle that feature and The next time something comes along that's similar We modify our design to accommodate that as well next time something comes along We modify it a little bit more and by the third or fourth or maybe fifth time We're dealing with this part of the system We've actually got a nice general design that's still clean and because we are in this in the habit of Not predicting what's going to come along. We're actually capable of dealing with anything that comes along. I Saw a question over here Yeah You change your mind. Okay, so So which would you rather have this? Or this this one or two as my wife says she's an optometrist The question is does this take more time does does the approach of refactoring take more time? Yes and no But you notice when you had that very first feature the amount of stuff you have to do to implement it is pretty tiny compared to the predictive approach That takes less time The amount of time you spend refactoring is higher and that's actually why it stays clean if you don't refactor then you end up just You know doing the spaghetti monster approach Only all the time instead of after your design is compromised There's a fairly old book called Program evolution By Balade and layman that kind of talk about this they sort of say you use the word They sort of say if you don't refactor you end up with the first thing That's right because you never take the time to do the refactoring So it looks like you're saving time But you end up with a mess that you either then have to spend huge amounts of time to fix or Now you have to throw it away. You can't fix it. You go out of business or something Yeah, so the real problem is not refactoring but when I first heard about this evolutionary design idea I I was really skeptical and I Being so skeptical I made a point of trying it to see how bad it was so I could proclaim how bad it was and To my surprise it worked and it worked far better than the upfront design that I had used previously What I found was that I wasn't getting myself boxed into corners as we often do with our designs So although you can start with a big, you know the pretty picture of where the design is going to go and the refactor from there And still keep it clean I find this way to be more effective because there's less preconceptions And it turns out that it's a lot easier to add code to a design than it is to rip out stuff. That's wrong So if you don't have any preconceptions about where the software is going to go those you aren't going to be wrong about where the software is going to go Now unfortunately, I could talk for days on this topic alone The reason I've put you all at tables with both programmers and customers is because I'd like you to talk about this a little bit more And I realize I haven't given you a lot of detail But Alistair's still here. So we've got five minutes Consider one of your projects at your table and just think about which of that which aspects of that project were designed in advance And which out of which of those predictions turned out to be beneficial for you and which predictions turned out actually to be quite harmful or painful and If you have a chance think a little bit about what you could do to reduce the amount of predictive design in the future And since I haven't really talked about how to do that if you're not sure that's fine, too Many predictions about how the existing business was going to continue to function and the way our project was built was to Work under those circumstances where it became painful was when the business went outside of what a normal business model was went way outside Then our software was not there to adapt to the Change of the business model it was there to adjust And that was pretty painful when it went outside your your predictions. Yes, where else were those predictions beneficial? We had a project that was using map mapping on an iPhone in real time and there were there weren't really elegant solutions at the time So we had to make some predictions about how we thought Apple might choose to tackle this in future releases And so the choice you made it end up being right that they did go down the way We thought that they would go go down to solve it So now with the new release of the software we're now much further ahead and if we would have made So you made a guess and you turned out to be right. Yeah Where where have your predictions ended up being painful Well predicting predicting estimates for sir. What about design predictions? Where have those turned out to be painful? This wasn't related to the project we discussed but we've had customers bring fully developed wireframes and designs and iteration to Something has come to light that that changes everything, you know ground up. So all that work has to be redone Okay, so the wireframes looked looked like they were right and then everything changes and you have to redo everything classic one not from this table, but Using an app server and buying into the whole g2e thing to only go to a different app server The entire security framework was completely different than class loader is different So having all that work we put in for run right once from anywhere was gone So you put it right once run anywhere if you're lucky And so that the techniques especially when you're swapping out fundamental frameworks that the techniques you can use to prevent that change from being painful can be Sophisticated so and we don't have time to get into that now But did anybody talk about how you could reduce some out the amount of predictive design or really the amount of pain from predictive design in The future and I don't want to hear the answer think further in advance because we're trying to be simultaneous here Anybody get that for I saw you in our case I had an idea But he wanted to you know, he kind of suppressed the idea until he got a little further along Okay, so you had an idea of what could come up, but you decided to wait. I call this willing suspension of belief So we believe this thing's gonna happen But we're gonna just wait and see and sometimes we believe correctly and that's great And sometimes we turn out to be wrong and because we didn't act on that belief We're okay It's when we act on the beliefs and the beliefs turn out to be wrong maybe 10% of the time that it hurts Eliminates fear if you see a way clear, you know, actually So if you if you see that you how you could implement it you can wait on actually implementing it again It's often easier to wait to implement something than to put it in and have to take it out One of the techniques I talked about which I'm not going to talk about in detail now is called risk driven architecture Where you see these things that could come up and you do refactorings that make those parts of the system cleaner without ever and implementing the stuff you think might come up and this works for for internationalization For example, you haven't gotten internationalization yet You think it might be an issue in this in the future and you see that you've got date formatting all over the place You might clean up your date formatting without ever putting internationalization in and that's a way of reducing your risk without predicting the specific features that are gonna come along in the future and That's a good change even if that feature never comes along. Unfortunately. We have to move on so if we're doing If we want to do simultaneous phases that means we need to do our planning all the time We need to do our analysis all the time. We need to do our design all the time and Coding all the time, but we all know how to do that. We're pretty used to coding all the time So I'm not going to talk about that, but we also have to do our testing Well, I don't have any slides on it. So sorry Some of us don't know how to do coding all the time. Some of us like to sit and wait before we code but But I'm not gonna talk about that so testing is Something else if let me let me tell you a story Some of you have heard this story before but I'm gonna tell it again Imagine a project that's written in C. It's a multi-threaded or a multi-processor project running on an embedded system There's about 50,000 lines of code It's developed over the course of several years It's for for farm combines according to capers-jones of Average team working on this software is going to produce four and a half defects per function point which in this case would be 1035 defects they're gonna find 80% of them and they're going to deliver 207 of those defects to their customer a Best in class team again according to capers-jones is going to Generate two defects per function point which would be 460 defects in this case They're fine 95% of them that are deliver 23 to their customer Nancy van Schrundevert Happened just coincidentally to be working on farm combine software written in C on a multi-processor system Which is why I chose this example and she had the added bonus of being handed people for her team that were sort of there to Help her fail that she was given novices. She was Given people in the company who Were kind of hard to work with because Nancy had been talking about XP a lot and agile a lot and really wanting to try it and She was so persistent about wanting to try this that eventually her manager say okay fine Do this project with agile here will give you these people to work with good luck get off our back So given this environment you wouldn't expect her to do that well and of course She only found 59% of her defects Which according to capers-jones falls squarely in the malpractice category of excellence and She delivered 21 defects to her customer Which means that She had to be doing something really different in terms the number of defects. She was generating. She did that She was generating Two tenths of a defect per function point over the entire life of this project over three years. She generated their team generated 51 defects They found like I said 59% of them before they shipped to the customer and then the rest afterwards They had so few defects that they did root cause analysis on every single defect and turned it into an experience report Which is how I heard about this This is a really substantial difference. This is actually an order of magnitude improvement Which Fred Brooks will tell you as everybody is happy to quote. There's no such thing as a silver bullet There will be no order of magnitude improvement before 1998 in 10 years between 1988 and 1998 if I've got the time frame right, there'll be no order of magnitude improvement in In software development that leads to I'm getting the quote wrong. There'll be no single tool Process or method that will lead to an order of magnitude improvement in software quality or productivity But this is an order of magnitude difference. How how is that possible? That was rhetorical, but I'll take your answer Test-driven development well kind of actually one Fred Brooks said within the next 10 years and it's been 20 years So we got that in our favor and also he said no single tool and actually there's a whole bunch of tools We can use to achieve this kind of result and one of them is tools to reduce programming errors And one of those is test-driven development Simply the programmer knows what to do and does it wrong test-driven development will help prevent that so we'll pair programming So will being awake 80% of the errors in the system are generated by 20% of the modules. This is according to Barry beam We call these Well, we call these oh god, please don't make me work on that part of the software They breed bugs So one way to prevent this is to have slack built into your iteration We need slack built into the iteration anyway to deliver on time. What do you do with that time? fix problems refactor your code Create simple designs that are less likely to have bugs Use incremental design as we were talking about because it keeps your design simple and only builds design for what you need And when you come across a bug, whoop never mind refactor your code and when you come across a bug Fix it because if 80% of the defects are in 20% of the code There's an 80% chance that that bug you just found is in the worst part of your code that's generating all your bugs So fix the bug refactor the code fix the design problem that led to the bug in the first place You'll eliminate a whole class of bugs So these two these two categories of techniques will allow you to eliminate a lot of the programming errors in the software and of course it is possible that programmers are perfect and Software is not the programmers could misunderstand What it's meant to do and I call these requirements errors we like to have on-site customers actually talking to us and Looking at what we do providing examples of how How they expect the domain to work I used to call these customer tests because I worked on a tool called fit But I've actually given up on fit and I no longer believe that automated customer tests are necessarily the right thing to do But the examples that you get from the discussion at the whiteboard about how the software supposed to behave those are invaluable Involve your testers from the beginning of the project. They're more likely to see Obscure edge cases than your customers are so have them work with your customers to identify these corner cases that your customers won't think of and As you develop the software your customers are sitting there with you I'm using this in the XP sense of the word the on-site customer These folks are sitting with you. So have them review your work. They'll spot things if you're doing all this perfectly I expect that you'll create no bugs. Oh, thank you. Yeah, right. He was afraid to say it really loud, but I heard it It is conceivable. I mean there are I Mean maybe not on the programmers part, but it's conceivable that somehow Defects could enter the system because we make a mistake of some sort and I call these process errors In other words, we think we're doing all this stuff really well, but we're not actually doing it really well So when you come across a bug do root cause analysis on it ask why five times How is it possible that? This bug came in why did that come in what led to that us making that choice what led to us making that choice In a in our workshop last week There were spelling errors in one of the releases and we were incensed and and mortified that that spelling errors could Actually make it into this perfect software that we're having people build. So we did root cause analysis on it. Why? Why could we have spelling errors? Well, because we didn't care if the spelling was right was the answer Why didn't you care what the spelling was right because we didn't think our stakeholders our executive sponsors care That was me and Diana We care deeply Why didn't you think your your stakeholders care and then then we sort of went off into well They didn't care they should have told us that they cared. Well, no actually the answer was we didn't ask We didn't ask so you do this five wise technique and eventually get down to something if you push I mean the temptation is to shift blame and say well It's not our fault somebody else should have told us or that piece of software should have worked or that framework is broken And that's nothing we can do about it, but push and get down to what you can do To solve the problem and then fix your process Next iteration Everybody was coming up to us saying what do you think of this? Do you like this? Are you happy with this approach? And we were happy to have them do that. That's what we wanted So fix your process to eliminate whatever that root cause is of course You're gonna fix the bugs you're gonna write tests to prove that the bugs fixed You're gonna fix the design But you're also gonna fix the process that allowed this air air to come up in the first place and Then as your last sanity check Do exploratory testing on the stuff you think is perfect exploratory testing is this beautiful technique for generating Innovative tests and finding unique errors very quickly It's essentially a disciplined approach of writing a test script in your head executing the script Using the results of that to generate a new test script and this Explore that your way through the software using your intuition experience as a tester So this is one of the things the testers are doing on the team Something you won't see on this list is anything about test the software before it goes out the door At least not by testers Because if we're doing all these things really well the test driven development is giving us a comprehensive regression test suite and That should be enough to tell us that we haven't broken anything and all these other things should be caught enough to Tell us that we have not introduced any new defects And this is how we can actually ship software at the end of the iteration without having a testing phase Remember we're trying to do simultaneous phases here in order to ship software without its testing phase at the end We have to be fairly confident that there are no bugs In order to have be fairly confident of no bugs. This is the process. I use this is the tech the group of techniques that I use and Using this group of techniques I can say I can expect fairly confidently that the team will reduce will produce less than five defects per month That's what I want to see That's what Nancy saw. She had she had no more than two defects in her backlog at any time And I think they produced One or two defects at most in any given month Scott said One one team delivered and number 107 One team delivered 23 Nancy's liver 21. Is that what was found in the field and Nancy's team delivered 21 defects That were found by somebody other than her team to be a little bit of Ups in here She internally improved by order of magnitude with the customer so I'm nearly as many defects So from quality perspective she's improved much at all Yeah, from a quality perspective no difference at all. Yeah from a quality perspective. She was only best in class Remember that that 23 defects is what you'd expect from a best-in-class team now. She wasn't doing all of these things So I think if you combine some of the exploratory testing here, which will help you Bring up the or identify more the defects that you're releasing and fix those problems I think you can do even better So I hand here She did not have a best-in-class team But she delivered equivalent to a best-in-class team I don't think it's actually possible to deliver zero defects But I think that should be our goal that should be our attitude is that we expect that defects are for other people Customers found the exact same very close to the same number of bugs This idea of prioritizing those bugs and that exploratory testing Is there can you talk at all about? Sorry The idea that there will be bugs in there but the customers won't find them because they they're very obscure books as opposed to They found these 21 bugs that happen every time they use the software There may well have been defects in there that nobody found At which point it's sort of like shortingers cat if nobody looks at it doesn't matter If it's alive or dead Okay So I'm going to give you five minutes to think about testing Think about in your groups think about a project and think about which types of bugs are most common on that project and At your table if you can think of any projects that have avoided those kind of bugs How did they do it and using that information? What could you do to avoid those types of bugs in the project you've chosen and what's your first step towards making that change? So I'll give you five minutes from now Anybody starting to feel like five minutes is more than enough time You got two of them see there you go. I'm gonna ignore all the people who've grown at me so What what process change what kind of bugs do you have and what kind of process changes would prevent those bugs? Requirements bugs and what what process changes would prevent those bugs? couple one is a little bit more customer discovery at front of their own process Maybe some of the more in-depth testing techniques in terms of laboratory Yeah, particularly useful is this idea of customer examples where you stand at a whiteboard you go through the problem domain by Discussing concrete examples of how your problem domain works in practice for example One one team I worked with did very complicated Scientific software so we had they gave us big data sets and examples of the metabolites We were supposed to find in those data sets uh Brian Merrick has stickers unsurprisingly that say an example would be helpful right about now and when you're working when you're working with your Customers your on-site customers your subject matter experts That's the phrase to remember an example would be helpful right about now and this came from fit and Fits progeny which is fitness and cucumbers were similar to fit and other tools like it And I was involved with fit in the early days. I did the C sharp version of fit And what I discovered is that these examples have a tremendous value But the actual tests that you create with these tools tend to be maintenance problems So I'm not interested in the tests anymore, but I think doing that example standing at the whiteboard with your customer saying Well, what do you mean by this? Not? What's the rule? But show me how that would work in practice give me an example It's tremendously valuable What are the kinds of one one more answer? So what what defects do you have and what process changes would solve it? Way in the back A lot of the problems Hmm that's an interesting idea so rather than saying we're going to prevent these sort of bugs We're just saying it's it's not going to be an issue which This is the way you use our software Yeah, and that's that's valid sometimes when these bugs come up you say well I'm sorry. It doesn't work on that skate navigator 1.0 Thank you for car As I was talking with Alistair, I was reminded that I wanted to say in the beginning that none of these techniques are new The testing stuff I've packaged in a way that some people haven't seen before but none of it's new the continuous incremental planning That's Jim Highsmith adaptive planning The continuous incremental develop design. That's Kent Beck's evolutionary design this is stuff that's really been part of Agile and XP from the very beginning and this idea that we don't have a bug database because we're too good for that That's been part of this stuff too What's happened though is as Brian talks about as the joy has sort of left the agile community and people are just trying to Make anything work in their environment People are moving back towards this phase-based approach That's why I want to talk about it here to sort of inspire you to try these things in your project And it is hard if you have existing code. We're talking about the shining city on the hill We're talking about Camelot. What can happen? When you do all these things from the beginning if you haven't been doing them from the beginning getting there from here is harder and Fortunately, I don't have time to talk about that today So deployment is the last thing I've already given away the secret here We're not necessarily deploying every day although there is a blogger online who works for a company who used to work for a Company called I am view that apparently every time they check in their software is deployed automatically and I think that's really cool It deploys automatically. It's it goes to a couple of servers. This is a big application It goes to a couple of servers They have automated monitoring that says that looks at the traffic and if the traffic on those servers drops They figure something broke in a bad way and if it doesn't they deploy it automatically goes out to all the other Servers an hour later or something like that 10 minutes later. I'm not sure I'm not asking for that Really asking for for three things in order for you to be able to push a button and deploy at the end of every iteration One you need to have automated deployment. So you have an automated 10-minute build, right? Builds and runs all your tests all your regression tests your complete thorough suite of regression tests in less than 10 minutes. Yes Yes, okay. Now it's going to deploy to this the production servers as well If you can do the first part the second part is easy Second we really need to be done done with everything in our iteration at the end of the iteration Which means we have to have an understanding of what done done is we need to build in enough slack into our iteration And we need to plan according to what our actual velocity is so that we can actually deliver according to our iteration plan every iteration and when we see that we're not doing that because Mistakes happen. We're not expecting perfection here change your plan take stories out and make sure that what you do deliver is done done And on those rare and wonderful occasions where you can do more than you planned put a story in It's not enough though to just have stuff that's done and can be push-button shipped. It also has to be market-ready and this is Easiest when you have an established piece of software that's deployed live on the web or something like that And you don't have any hoops to jump through before you to do do deployment So there is a business issue here, but for those of you who are actually Deploying in a way where customers can just get the updates without having to do anything You don't have any regulatory requirements and you have a piece of software that's established enough that you can deploy every week incremental improvements I want to see you deploy software that's market-ready at the every end of every iteration And if you're not in that case at least make sure it's internal ready so that you can demo it to across your company So everybody can see it and that if you make major changes in product direction that you can decide to ship what you've got So in your groups consider a project Look at those three things. Are you able to deploy every iteration? Do you have automated deployment? Are all your stories done done and is your software market ready? and if if any of the answers if no is the answer to any one of those What would have to be true for that first node actually be a yes And what's the first step you need to get there? So I'll give you five minutes to think about that question that was only four minutes and The session is gonna close in two minutes, and I have a few last things. I'd like to say and I'd also like to hear from you So I'm I'm cheating So what's the first next step yet you need to get needed to get you to? Continuous deployment first next step I'm sorry Buy my book always a wise decision Others less mercantile Let's go over here Unlike the other stuff I'm talking about this can actually be applied to any project and instantly makes Programmers lives better and as you go further along makes everybody's lives better This is a great place to start if you're looking for ways to improve your process One more and then we've got to close first next step so Getting kind of done is done problem setting an expectation with the customer to say you have a certain amount of time to Give us back feedback so that we can mark this done is done because if you're waiting for the customer's response For it's done you're delaying the ability to deploy Yeah, of course, we're not waiting for the customer because the customer sits with us and is is there as soon as we ask the question, right? Yeah, be careful of being controversial or confrontational with them though If it's not done no matter, you know what rules you said it's not done and you don't want to shift defective software So I'm hearing the inklings of a customer behave or else and you want to be careful about that Despite how I got you all set up at the beginning. I really want you to all cooperate in a big happy family with flowers and bunnies and unicorns All right so that's that is a very brief view of Simultaneous phases we want you to be able to start your iteration take stories off the backlog and deliver to production a week later and The only way I know of to do that is to work simultaneously and I've given you a brief hint of how you can do that There are So that's that's the end a few more things. My name is James. Sure. I have a book. They're out of agile development As wisely recommended by our friend here of a website James sure calm. I'm on Twitter. I've emailed a phone And I'm happy to talk to anybody afterwards. Thank you very much for attending