0 00:00:07,200 --> 00:00:12,000 After watching this video, you'll be able to list the five practices of working Agile, 1 00:00:12,000 --> 00:00:17,200 explain working in small batches, define a minimum viable product, understand behavior 2 00:00:17,200 --> 00:00:22,720 driven development, understand test driven development, explain how pair programming works. 3 00:00:24,320 --> 00:00:31,200 So let's take a look at what it really means to work in an Agile fashion. First, you want to work in 4 00:00:31,200 --> 00:00:36,800 small batches. We get this from lean manufacturing. You don't want to make a big batch of something 5 00:00:36,800 --> 00:00:41,040 and then find out that you did it wrong because that's a lot of waste having to go back and change 6 00:00:41,040 --> 00:00:47,280 it. Next, you want to use minimum viable products to figure out what does the customer like, what 7 00:00:47,280 --> 00:00:52,480 doesn't the customer like. And then you want to use practices like behavior driven development 8 00:00:52,480 --> 00:00:58,400 and test driven development to improve your testing of the system from the outside in and 9 00:00:58,400 --> 00:01:03,760 from the inside out. And then finally you want to take advantage of pair programming. This came 10 00:01:03,760 --> 00:01:08,560 from extreme programming but pair programming is critically important. So we're going to look at 11 00:01:08,560 --> 00:01:16,800 each one of these in turn. Working in small batches-- let's say I need to mail out a thousand brochures. 12 00:01:17,600 --> 00:01:22,240 And the steps are you need to fold the brochures and then insert the brochures into envelopes, 13 00:01:22,240 --> 00:01:26,240 and then seal the envelopes and then finally stamp the envelopes with postage. 14 00:01:27,200 --> 00:01:32,560 So let's say that we're going to do these thousand in batches of 50, right, big batches, 50 a piece and 15 00:01:32,560 --> 00:01:37,600 assume that each step takes about six seconds to complete. So I can do about 10 steps per minute. 16 00:01:38,400 --> 00:01:44,080 And so we do the first step folding, right? And at 10 for a minute, it takes me about five minutes to 17 00:01:44,080 --> 00:01:50,160 fold 50 of them. Then I move on to the next step. The next step is inserting them all and again, 18 00:01:50,160 --> 00:01:55,440 if I could do about 10 of them per minute, and so it takes me five more minutes, plus the five 19 00:01:55,440 --> 00:02:00,080 minutes from before. Now I'm 10 minutes into it. I've got them all folded and inserted then I 20 00:02:00,080 --> 00:02:05,520 move on to step three sealing them all, right? So now again about 10 per minute I could do another 21 00:02:06,240 --> 00:02:12,160 50 in another five minutes. So I'm up to 15 minutes, right? Wall clock time. And then 22 00:02:12,160 --> 00:02:18,720 finally I get to step four and it took me 16 minutes to get my first finished product right? 23 00:02:18,720 --> 00:02:23,840 The first one where I had things that I could actually inspect it and see what the quality was. 24 00:02:23,840 --> 00:02:30,640 So, what if the envelopes had no glue, right? It would be 11 minutes before I figure out that 25 00:02:30,640 --> 00:02:34,400 something went wrong. What if there's a typo on the brochure? I have to go all the way back 26 00:02:34,400 --> 00:02:40,560 to the beginning, right? So, this is just very, very wasteful working in these large batches like this. 27 00:02:41,200 --> 00:02:45,920 Now let's look at the same example with single piece flow. And again, assume each step takes about 28 00:02:45,920 --> 00:02:51,840 six seconds to complete. With single piece flow, I fold, right? And put them in the envelope and 29 00:02:51,840 --> 00:02:57,040 seal them and put a stamp on them and the first finished product is in about 24 seconds. Now I 30 00:02:57,040 --> 00:03:02,800 can inspect it see if it works, see if it's what I thought it was, and then let the rest of the flow 31 00:03:02,800 --> 00:03:09,680 rip. Now what if the envelopes had no glue? Well I would find out after, uh, maybe 18 seconds, right? 32 00:03:09,680 --> 00:03:15,280 And if there was a typo in the brochure, after 24 seconds, so it's very, very important that we don't 33 00:03:15,280 --> 00:03:20,640 work in two larger batches so that we can get fast feedback and that we can pivot and understand, 34 00:03:20,640 --> 00:03:24,480 you know, do we need to do something different and then make the changes that we need to make? 35 00:03:25,680 --> 00:03:31,520 So let's talk about minimum viable product. First, let's understand what it is not, because there's 36 00:03:31,520 --> 00:03:36,800 a misconception that a minimum viable product is like phase one of the project or, you know, 37 00:03:36,800 --> 00:03:42,000 the first beta or something like that. And it's not. This is not what a minimum viable product is. 38 00:03:42,000 --> 00:03:47,920 A minimum viable product is the minimal thing that you can do to prove a hypothesis and gain 39 00:03:47,920 --> 00:03:53,040 learning and gain understanding. The difference between these two is that the first one is all 40 00:03:53,040 --> 00:03:57,120 about delivery, right? What am I going to deliver? But the second one is all about 41 00:03:57,120 --> 00:04:03,920 learning. What can I learn? What can I learn from putting out this MVP and get feedback 42 00:04:03,920 --> 00:04:10,000 and then maybe make the next one even better? So it's important that at the end of each MVP 43 00:04:10,000 --> 00:04:17,600 you decide whether to pivot or persevere. Let's look at an example. Here's a team that's developing 44 00:04:17,600 --> 00:04:22,800 a minimum viable product for a customer that wants a car. And so, in the first iteration, they deliver a 45 00:04:22,800 --> 00:04:27,280 wheel. The customer's like, "What am I going to do with a wheel? I can't do anything with this?" Like, 46 00:04:27,280 --> 00:04:31,920 well, we're working iterations, we're trying to be agile here, right? And so the next iteration, we'll 47 00:04:31,920 --> 00:04:36,640 give you some more. And they give them a chassis and it's like, okay, "I really can't do anything 48 00:04:36,640 --> 00:04:40,640 with this." And then finally, you know, they give them a car with no steering wheel and then 49 00:04:41,360 --> 00:04:48,080 eventually they get the car, right? And so they get this coupe. That team did not understand 50 00:04:48,080 --> 00:04:51,520 how to create a minimum viable product. They were just doing iterative development. 51 00:04:52,240 --> 00:04:58,560 The second team understands the value of creating an MVP. At first, they give them 52 00:04:58,560 --> 00:05:03,200 a skateboard and the customer's like, "I asked you for a car and you're giving me a skateboard." 53 00:05:03,200 --> 00:05:09,360 Whoa, whoa we're testing the color. How do you like that color red? Is that the color you want? "Oh yeah, 54 00:05:09,360 --> 00:05:15,280 red's kind of cool but you know it's really hard to steer." No, we'll fix that in the next MVP and 55 00:05:15,280 --> 00:05:20,160 then they add a way to steer it and the customer's like, "Well, okay, you did give me a way to steer it 56 00:05:20,160 --> 00:05:25,120 but I can't go very fast. I need a better form of locomotion." And then we'll deal with that in 57 00:05:25,120 --> 00:05:30,800 the next MVP. In the next iteration, they give them pedals. Somewhere along the way while the customer 58 00:05:30,800 --> 00:05:38,560 is riding on that motorcycle feeling the wind in their hair they decide, "I want a convertible." In the 59 00:05:38,560 --> 00:05:43,120 first instance, the customer got exactly what they asked for months before because they were just 60 00:05:43,120 --> 00:05:49,440 following a plan but in the second instance the customer got exactly what they desired 61 00:05:49,440 --> 00:05:55,200 because they were working interactively with the development team and in the end, you develop 62 00:05:55,200 --> 00:05:59,440 something that's a little bit different but it's closer to what the customer really, really wants. 63 00:06:01,280 --> 00:06:07,680 Behavior driven development is when we describe the system from the outside in. This is usually 64 00:06:07,680 --> 00:06:13,360 done at an integration testing level, right? So, this is where we're taking the customer's 65 00:06:13,360 --> 00:06:18,880 view of the system usually when you're doing BDD testing, you're doing it against the user interface, 66 00:06:18,880 --> 00:06:24,800 right? You're doing it against the thing that the customer sees to see if the system behaves the 67 00:06:24,800 --> 00:06:28,640 way it's supposed to. So, if it's an e-commerce system, when I put something in my cart, does it 68 00:06:28,640 --> 00:06:33,040 behave the way I want? When I transfer a cart to an order, does it behave the way I want? It's 69 00:06:33,040 --> 00:06:37,920 really taking an outside-in approach. It's not too concerned with the things going on underneath. 70 00:06:39,040 --> 00:06:44,720 The cool thing is it uses a single syntax that both the developers and the stakeholders can 71 00:06:44,720 --> 00:06:50,160 use to describe the system and agree on the behavior of the system, on what the system does. 72 00:06:50,160 --> 00:06:57,200 So, let's take a look at that syntax. It starts with these BDD feature scenarios. Where I say, 73 00:06:57,200 --> 00:07:03,680 "As a sum role, so, I want to know who is this for. I need some function, right? So what is 74 00:07:03,680 --> 00:07:09,600 it the functionality that we actually need so that I get some business value?" So, now you know 75 00:07:09,600 --> 00:07:14,240 who is it for. Is it for the customers? For the system administrator, right? Who's getting the 76 00:07:14,240 --> 00:07:19,840 value out of this what do they need and why do they need it? And that's the beginning of your 77 00:07:19,840 --> 00:07:25,440 feature file. And then you start running through scenarios and here's where we use this common 78 00:07:25,440 --> 00:07:32,560 syntax. It's known as Gherkin syntax after the Gherkin pickle. And it goes something like this: 79 00:07:32,560 --> 00:07:37,760 Given a set of preconditions, right? So, that kind of sets up the scenario-- given that this is true. 80 00:07:37,760 --> 00:07:43,920 I've got two items in my cart. I got three items that I order, whatever. When some event happens, 81 00:07:43,920 --> 00:07:50,320 right? So, that's the thing that's under test. Then I should see some observable outcome. So, using this 82 00:07:50,320 --> 00:07:56,560 given when-then syntax, developers can understand it, stakeholders can understand it, everybody can 83 00:07:56,560 --> 00:08:02,800 understand this common syntax that when I have something in my cart and then I clear my cart, you 84 00:08:02,800 --> 00:08:08,400 know, I should see nothing in my cart. So very, very important to have the syntax in these BDD 85 00:08:08,400 --> 00:08:17,600 scenarios. Test-driven development is testing a system from the inside out. Unlike behavior-driven 86 00:08:17,600 --> 00:08:22,720 development. It is concerned with the internals of the system, the single modules. Usually this 87 00:08:22,720 --> 00:08:27,680 is called unit testing, right? And this is something that is unit test case driven and we want to make 88 00:08:27,680 --> 00:08:33,280 sure that given these inputs I get these outputs at a small module level. I don't know if when I put 89 00:08:33,280 --> 00:08:37,920 them all together I'm going to get the behavior I want. That's kind of BDD but for TDD, test driven 90 00:08:37,920 --> 00:08:43,520 development, I'm just testing the system way down at the unit level and so you write a test 91 00:08:43,520 --> 00:08:48,720 case first for the code you wish you had and then you write enough code to make that test case pass 92 00:08:48,720 --> 00:08:53,280 and then you start all over again and refactor. So the workflow goes something like this: 93 00:08:53,280 --> 00:08:58,960 I write a test case. You might say, "You write test cases before you write the code?" Yeah this keeps me 94 00:08:59,760 --> 00:09:04,640 featured on what is the code supposed to do. When I call this, how do I want to call this? What are the 95 00:09:04,640 --> 00:09:09,920 parameters I think I want to pass in and then what does it do for me? So, you write the test case first 96 00:09:09,920 --> 00:09:16,080 then you write enough code to make that test case pass and then once it passes then you can refactor 97 00:09:16,080 --> 00:09:21,120 the code because now you have test cases to keep you honest, you'll know if you broke anything. 98 00:09:21,120 --> 00:09:26,960 Now, because when the test case runs and it fails it usually turns red and then when it works 99 00:09:26,960 --> 00:09:33,360 correctly it turns green; we tend to call this Red, Green, Refactor. Watch a test case, write a test case 100 00:09:33,360 --> 00:09:38,800 watch it fail, make just write enough code to make it pass, and then refactor make it-- you might not 101 00:09:38,800 --> 00:09:42,560 have made it very elegant just to make it pass-- now you can go back and you can add all sorts of 102 00:09:42,560 --> 00:09:47,520 error checking and whatnot make it a little more, uh, robust and then run the test cases. Make sure 103 00:09:47,520 --> 00:09:55,280 you didn't break anything. Pair programming. Pair programming, you might say two programmers working 104 00:09:55,280 --> 00:10:00,960 together on the same thing, uh, and the first thing is: I'm paying two people to do one job? 105 00:10:01,600 --> 00:10:06,400 But actually it works out really, really well because what you're doing is you've got one 106 00:10:06,400 --> 00:10:11,360 person writing code and then you've got another person who has another set of eyes on the code. 107 00:10:11,360 --> 00:10:15,920 So the question is, would you rather find bugs in production? Would you rather find bugs while you're 108 00:10:15,920 --> 00:10:20,320 writing the code? It's a lot cheaper to find them while you're writing the code, so having two sets 109 00:10:20,320 --> 00:10:25,120 of eyes, they check each other and they go back and forth. It's not just one and then the other. 110 00:10:25,120 --> 00:10:29,840 Usually in 20 minute increments, right? Somebody's writing code, the other one is watching and they're 111 00:10:29,840 --> 00:10:33,760 not just watching. Sometimes they're looking things up, sometimes they're discussing. "What do you think 112 00:10:33,760 --> 00:10:38,000 I should call this variable? What do you think I should call this function?" Right? It's two sets of 113 00:10:38,000 --> 00:10:44,080 minds working around this code and what happens is you actually get higher quality code at the end of 114 00:10:44,080 --> 00:10:49,360 the day, right? The code quality goes up because two people have already checked it and so when 115 00:10:49,360 --> 00:10:54,560 you say, "I can't afford to pay two people to write one piece of code." You can't afford not to pay two 116 00:10:54,560 --> 00:10:59,280 people to write it because writing the code is the cheap part. Debugging it, maintaining in production, 117 00:10:59,280 --> 00:11:04,000 that's the expensive part and so if you want the expensive part to get cheaper you want to have 118 00:11:04,000 --> 00:11:09,040 your programmers do pair programming. It's also very good to put a senior programmer with a junior 119 00:11:09,040 --> 00:11:13,760 programmer. Now the junior programmers can see: How does the senior programmer approach the problem? 120 00:11:13,760 --> 00:11:18,480 And so they learn, they get mentorship, and then the senior program can see how the junior person 121 00:11:18,480 --> 00:11:23,600 is making out. Or you get people who are unfamiliar with the code working with someone who is. Now you 122 00:11:23,600 --> 00:11:27,760 get more people learning the code because they they're and they're getting like a tutorial from 123 00:11:27,760 --> 00:11:33,200 the other person. So pair programming is really, really great way of bringing all your people on 124 00:11:33,200 --> 00:11:39,440 your team up to a certain level. In this video you learn that working in small batches means 125 00:11:39,440 --> 00:11:45,840 delivering something useful quickly, an MVP is the cheapest, easiest thing you can do to test the 126 00:11:45,840 --> 00:11:50,640 hypothesis and learn. Behavior driven development makes sure you're building the right thing. 127 00:11:51,520 --> 00:11:54,240 And test driven development makes sure you're building the thing right. 128 00:11:55,360 --> 00:12:05,600 While pair programming enables you to discover defects earlier and increase your code quality.