 Before we start that are always the most awkward bear with us All right, I'm going to get started even if some more people show up because the stuff in the beginning Well, you know what it isn't that important and I want to get to stuff the end So good afternoon. My name is Howard diner. I'm from a company called big visible Working States You may ask what big visible is all about and I really don't know if I could tell you Basically we make business better Do all sorts of stuff as an agile coach actually end up doing a lot of other kinds of business consulting and Processed of mostly in software as you might expect That's about it Let me get started and you know, here's the entire presentation. Well, that was good. We could all leave now But I want to give you an idea of to get started about what we're going to be discussing and If you're here for a different reason This might be interesting to you. We're talking about QA We're talking about people in QA. How many people in the audience are in QA organizations Okay, how many people in the audience have a separate QA organization than a development organization Pay attention. You have things to bring back Monday morning Okay, this session is not about the QA people themselves very much. It's really about the Organizations, it's about the way that the structure in organizations has to change Right. It's about what happens. It's going to allow agile type testing to work. Well Right, it's also about When you go to your managers and tell them what needs to be done. This has a tendency to turn their world upside down Okay, so we're going to be talking about the type of mindset that we need Additionally, we have to understand the patterns of resistance. Who in here gets this picture? Okay, good. We have some EEs. What value are those resistors at? We'll talk about it later There will be some enigmatic pictures and if you have any questions just shout them out And we're also going to talk about the work that gets done and how the organization now starts to fit together Okay, so let's talk about an agile testing organization quickly. What's what's different about it? Well, the first thing that's different about it is that we're not talking about quality control Right quality control and quality assistance are two very separate things, but people don't don't get it Quality control is all about making sure that we inspect products and don't ship defective ones Okay, we use it in a manufacturing world Okay, we use it when we're producing goods in mass manufacture to get the cost down Right. It's something that we know the process. We can set up assembly lines We use large pardon me large batch sizes Right, so the amount of parts voice the amount of parts on the assembly line Is a large batch people get that concept? we'll talk about it and We want to make sure that we understand that software is very different We can't produce it the same way. Okay when we do stuff with blueprints And then take those blueprints and make them into products, right? We have everything figured out We know that if we follow the plan and we use quality materials that we can produce the same car Time after time Right, we can't do that with software. We need an adaptive process as you know So if you ever see one of these kinds of advertisements, you know things like guaranteed 50% reduction in your cost Don't just turn a ray run away. All right, this can't work In fact, we can't go back to the manufacturing analogy where at each Station along the assembly line. We add a small increment of value All right, there the reason is That the variability and what we're trying to put together So-called requirements the variability in what we use to put that software together with the so-called Frameworks whatever there's so much variability inside of it that we can't do a good job of estimating We can't go to a good job of knowing what we really need and this comes up This comes up when we start talking about software. I mean how many people have ever coded The same piece of software twice You know you build some system to do well computer aided design takes you three years and then you say hey You know what we want to build exactly that same piece of software from computer design doesn't happen, right? So it's different. Okay. We have to start understanding that when in a manufacturing sense We do our quality control at the end. We end up with this like big box of parts Right. We're looking at defects here We're looking actually at a big box of money We don't want to do that. Nobody wants to do that and this happens because of large batch in which we'll talk about Detroit used to be the big manufacturer of cars in the States. They almost went out of business in the 70s and 80s and 90s right they went out almost went out of business to Japan because Japan understood What small batches were in fact in the Japanese system if you look at it it looks something like this Right. You got an assembly line for cars We have the pieces that are going into the cars the inputs if you will that are delivered just in time Right when we have just in time we think about delivering our requirements just in time We know the most to make the best decision, but we're not going to talk about that really But what we are going to talk about is this end in line Right on the Japanese manufacturing the Toyota production manufacturing system if a defect occurs The worker pulls the line and the assembly line stops And then we go back and we fix it Okay, we make sure that we're always producing zero defects along the way Right now we have the same sort of concept in Agile right this happens to be like scrum looking at a project board Okay, we are able to have smaller batches We'll talk about this in a minute about what we mean by smaller and how small they can get We do our work iteratively We come back and check Right if at the end of a sprint Something isn't working We don't keep on going we stop we fix it So we try to incorporate those kind of values when you don't do that kind of stuff when you test at the end You end up with situations like this right this was the area on it's a French rocket 1996 what you're seeing is what you call a catastrophe at takeoff a Cato and It happened when they do the root cause analysis Because of some 64 bit integer being stuffed into a 16-bit integer and oops Something happened. Was that a failure in testing? Maybe was it a failure in manufacturing? Maybe right, but we will try to Kind of like with the lights off I mean in any case the Toyota production system We need to pivot in the same way when we're building and testing software Especially the testing part a lot of people talk about scrum in the building part People forget that there's tests that go on Okay, the two big differences Too big differences that we're going to talk about Are with the QC mindset when we get to the end of a release? What do we do? We start testing what happens if things don't go well Well, we write reports and we go back and we fix it. Okay to me This sounds like a task of Sisyphus right the guy it was a French I'm sorry a Greek myth mythological creature Okay, the king was being punished You have to push this big boulder up the hill and his punishment was the boulder would come down They don't have to push it up again forever and ever that is an epic fail Instead we start getting the proper QA mindset put together We're going to start baking the quality in as we go We always have to be ready to ship Right and until and unless we do that We're always going to be noodling around in the code when it comes time to release We're never going to be sure of exactly when things are going to happen We're never going to be sure if things are going to work in the field. We can't do that our Bacon's so to speak will get cooked QA what is it like in an organization? Well, I hate to tell you this but you're still going to be doing testing Okay, that doesn't go away. It's the approach that is different enigmatic picture This is what it looks like in a small plane when you're going to make a landing. It's called the approach The difference in approach is that we know that we're not going to be testing our way into quality And that's a very important thing to remember. There is no way to test quality into your product The only way to do it is to build the quality as you go The way that we do this is to make sure the QA comes in for the entire life cycle Right from the beginning another way of thinking about that is that we're going to bring testing forward And we're going to stop we're going to stop thinking about a separation so to speak of church and state Where you write code and then you test the code? Instead we're going to be thinking more like we build code together Now this is my favorite. Does anybody know what this is that that's being displayed on the screen per chance? Cucumber. Yes. This is a gherkin script Which then gets executed in cucumber. It's what it's a kind of an acceptance test Look at this. Well, this is what you should be doing Okay The difference is that instead of going and starting at the beginning when like no code is written What would a QA people do? Oh, we write test plans What's a test plan? Oh, it's the stuff we have to think about when we go about testing forget that I want BAs and QAs and developers right at the start Writing these sorts of acceptance testings are simple, right? You can read it. You can understand kind of what it is just by looking at it Right those three amigos BAs QAs and developers using the traditional enterprise sorts of terms when they get together and write this kind of stuff They don't need any stinking requirements documents. They don't need any stinking Specification documents. They don't even need the stinking story cards. These become your executable requirements Because they'll tell us if it's working or it's not so the question I want to ask you is if I'm saying that you don't need requirements anymore How come what's the difference between a requirement and a test? So let me see if I can give you an example. I Require that I burp a yellow jelly bean After I eat a red jelly bean followed by a green jelly bean That's the requirement build me a system that does that. How am I going to test the system? The test would say something like Eat a green jelly bean eat a red jelly bean observe was a yellow jelly bean burped That's the same thing There is no difference between testing and requirements And the earlier we can start testing the better things are because remember back from the manifesto We favor working software for comprehensive documentation If you want to call the acceptance test documentation fine. I call it code. I Say that that's code that proves for the for the cases that we are testing for that things continue to work Because we want to build this into a regression suite an automated regression suite That will constantly be able to tell us that we haven't broken anything with some unknown side effects and When we run our regression suite which we're going to run one way or another Every time we check in if we're doing things like TDD that means every time we've write a new unit test We can make and we follow the simple rule right. We know that software isn't working if the code doesn't compile, right? New rules if the tests are failing any of the automated regression tests are failing. It's as bad as the code not compiling Follow that simple thing and you're going to be producing quality software from day one That means that agile testers are actually developers that are developing tests Okay, there's there's no reason that a developer should have to look through a whole bunch of documentation And try to figure out what it is they're supposed to build Give them the test give them just enough information Collaborate with them. Okay, and then when the test passes, they know they got it right and the same thing goes for the testing There's no reason that the test person the QA person if you have to read through all that documentation to try to figure out You know what's different and then getting the QA people to Look at what's different from what was developed and forming a gap analysis. I don't understand the reason for it Okay Pictures might be worth a thousand words an automated test is worth a thousand pictures in a document The problem really is that it's very hard with words to sometimes describe what's wrong Very hard with just words having code that does it or in this case We're actually looking at pictures of a of a user-level acceptance That's the way that we do it But the important point here is that we need the automated test to either red or it's green That's it Once tests are automated that QC sort of a person doesn't have to You know worry about the fact they got this really long test plan with a whole bunch of manual steps That they have to run through which means they don't want to do it All right Because computers computers are really good at automatically executing stuff time and time again Okay, they don't need sleep. They don't complain. They don't they just do it, right? Computers are also really good at not getting bored When you're doing your testing manually, it's very easy for your eyes to glaze over and miss something All right, this is one of the problems about manual testing Here's a really important point When we start getting agile testers involved early They also learn about the environments that are necessary to run their tests inside of Okay, this concept then starts translating into what's commonly called nowadays DevOps The QA people on the team are the ones that really understand now How to make things work and how to migrate from one environment to the other perfect Because what we really need is more than what we just normally called working software, which is demonstrable We really need is not just continuous integration. We need more continuous delivery And it's so we can reduce that cycle time of getting there Getting our software into the hands of our users to get meaningful feedback Till we get to that point, we're always going to have some more wasted cycles Well, we're going to talk about more of the waste as we just a second As if you didn't know DevOps comes from developers and operations, but it's QA that really makes it makes it work good We're almost getting to the meaty part a Quick review of what kind of tests there are that are out there It's called the mechanical Turk. It was developed as a chess playing computer of sense It was developed in the 19th century and the kings and queens of Europe would play against this There was a little guy sitting underneath it in a closed box He was looking at the play going on through like some mirrors and he would move this rope this Whatever you call it the mechanical Turk People couldn't tell the difference that what looked as though this What do you call this this robot was playing chess, but he wasn't Black box testing means that we don't know what goes on inside the code. We only look at what the functionality is Okay, and you know as long as it responds to our stimulus correctly We don't care if there was a little guy on the other side typing out the answers Okay, and it tells us by the way if we built the right thing Okay, that our requirements were correct contrast that with white box testing, which is not really testing It's a coding practice. We also call those unit tests. We can look inside open up the hood See how the code works. We develop our test as we go So that we can make sure that we built the thing right You can make sure that all the alternatives and exceptions inside the code are reasonable Right, and we can continue to make sure that as we add new code that we're not breaking other pieces by side effect Gray box testing probably isn't too familiar to you. I think I kind of made the word up But gray box testing is in between it's these acceptance tests like these gherkin scripts Okay, acceptance test-driven development gray box testing We want to make sure that the developers and the business people the BA's or the product owners Whatever we're going to call them in our process are speaking the same language. We got to get a domain language that works We're going to write our gherkin scripts. I happen to like cucumber. There are other frameworks We're going to write that in that domain language now Everybody can make sure that we're all building the same thing that there is in a communications gap We're not going to talk about functional versus non-functional testing I'm sure everybody knows it but if we built a trading system and it could trade one share Every hour we need a system that trades 10,000 shares a second Well, we didn't hit on some of the performance characteristics the capacity the latencies all the illides are non-functional Generally outside of what we what we normally do a lot of QA people get involved in it It's also much harder to automate but we could talk afterwards if you want to about that the basic pivot Destroy the silos get business and developers together Collaborating right? Make sure that our code is always ready to ship. We should not have to have a long amount of time To get the code into the hands of users to gain feedback Okay, and when we do this testing becomes very deeply embedded very deeply embedded in the whole product cycle Okay, we're the product is saying what the things are that we need to build Becomes very embedded in the project cycle of how we go about doing that building and The important point is that everybody can feel safe that all the things that we've been adding move forward Fearlessly, we're always ready to ship Okay, let's talk a little bit about the lintel. This is where I want to get to Okay, and I'm going to talk about some wastes in particular ways dealing with work in process if you've heard of or read Eric Reese's book on Lean startup thinking You'll see this example. He took the example in it from a guy named James Womack who wrote it with Daniel Jones and Womack was back in the 90s. He was a guy that was Talking about lean in business Right? He was a kind of a consultant Back then when you want to reach people you didn't send them a big, you know spam of mail You know instead what you did was you took your flyers and you put them on envelopes and mailed it to people So he'd have several hundred envelopes that had to get mailed every every month He had two daughters. One of them was nine. One of them was five Decided to have a little fun one day. He said guys. What's up? Let's play a game I have to mail out these 200 newsletters Okay, and I need you to help me like daddy daddy daddy. I know how to do this. I know how to do this Okay, well sure. What do you want to do? We're gonna make an assembly line Okay, we're gonna we're gonna take all the flyers and then we'll fold them all up Put them a nice neat stack and then then we're gonna take all the things that are folded We're gonna put them into envelopes Right, then we'll take all the envelopes and we'll stack them up and then we'll take them off and address them And then we'll put on another neat stack and we'll put the stamps on them And then they'll be a stack and they'll be all ready to go and be really efficient You know, we're gonna have an assembly line. They built cars and stuff and kids actually will learn this really early on So James said well Gee, I don't know the way I usually do it is you take a flyer You're folding you put it in an envelope your dress that you put a stamp on it and you deliver it that works for me But you know what let's have a game. Let's try it. We'll both go ready said go who won No, the kids lost kids lost they lost bad How come that what you're not what you what's not intuitive is that there's a lot of waste involved in Folding the envelopes and putting them in a nice neat stack squaring it off Taking which one off and putting it inside of an envelope and then stacking up the envelopes There's even worse stuff that happens What if you take the first newsletter and fold it and then fold all the others exactly the same way and find out that The newsletter doesn't fit in the envelope oops Right you do them one at a time and you actually get much better performance This is called single stream flow technically, right So okay, so I'm talking here about the fact that you know you're able to learn as you go Right before we fold the newsletter found out didn't fit we fix it We don't have that large batch of stuff sitting there that has to now be reworked Okay, Scott Ambler Put together a diagram which shows the cost of fixing defects Against the length of the feedback cycle. I don't want to go too deep into this But basically the later you wait to get some feedback such as waiting until the end of all the envelopes are folded or Waiting until you doing acceptance testing Right the cost of fixing stuff is huge If you can bring that forward and start getting your feedback loop earlier Okay, and there's various ways to get it all the way back to like when we actually write the code With test driven development for example every time you shorten that feedback loop. It's going to cost you less money All right, so don't believe me. Let's talk about another way that that we worry about waste in development And here I'm going to talk about libraries We ever have a library Then we build a library, you know a kilometer away And we need to move all the books from one library to the other. How do we do it? Well one way to do it is to get a bunch of boxes Take all the books off the shelves put them neatly inside the boxes so you can stack the boxes up and not have them fall over Take all the boxes put them into hand trucks take the hand trucks roll them maybe down the street or maybe into a van Get the hand trucks in the new library roll the can trucks up, you know put them next to the shelves Open up the boxes figure out where all the books go now because you got to keep them in order It can be a really hard way to do it Right. There's another way to do it and it's called a book brigade and a book brigade Looks like this This was done in Boca in Florida United States little demo here. We lost audio There's a lot of loud music in the background and I love it how we follow the book It's a lot more fun than the music's playing It's actually occurred It's about a half a kilometer from one library to the new one Remember they took the book off the shelf start to pass it person to person It's a true single stream flow this goes right in place and You will see that unless if you read the book that I reference in there unless you're Having to take the books off and put them in storage Book brigades are the cheapest and most efficient way of moving things under a certain set of criteria I thought it was fun. Okay, so why did I show you that other than the fact that I wanted to have a little music playing here? Okay, what does this have to do with software development? Well, it has something to do because of flow All right has something to do with the fact that when we start batching stuff up for QA The traditional way of doing our development getting a whole bunch of tests that we then give to QA to bring over the line Right, it's sort of like packing them into boxes Right, it's actually much much better to get rid of the boxes. We can get to single stream flow I love you, right, but if you can't get to single streaming at least keep it as a very small batch Okay, a small batch might mean that we do some user acceptance tests if people do that during the sprint Okay, not waiting until the end. That's the difference right, so Don't pack your stories into QA acceptance boxes. Do them early write them as executable requirements if you can Right and remember to treat any failure in your automated tests as if the code wasn't compiling Talk about a different waste Let's talk about Scrummerfall for a second and let's start with cargo quilting. How many people know the word cargo quilting excellent Cargo quilting was named by Richard Feynman who was a noble laureate at Caltech He actually was involved in Manhattan Project the Second World War about the atomic bomb from the United States Went on people start to learn of him more when he served on the Commission for the failure of the space shuttle Challenger and he was the o-ring guy Anyhow the 1974 commencement address at Caltech there was a lot of pseudoscience going on So Feynman comes up and says look guys Remember in the Second World War the United States was trying to get you know over to Japan The way they did it was they'd hop little islands in the South Pacific Every island that they'd land on they'd send out the Marines. They'd build a big airstrip. They make a big control tower These guys with headsets would come on To the natives who had never seen Westerners before much less technology Natives saw these huge birds coming out of the sky They'd land on this big strip of earth They'd open up their bellies and there'd be goods and things food all kinds of stuff that they got a they got a share of that too The war ended the United States picked up all of the all the materials They took it all home the natives looked around they said were those big birds So what they said is oh we must not be Must not be worshiping the bird god very well So they went out and they took bamboo and they built control towers They put coconuts over their ears, you know for headsets They marched around with sticks that they carved like they saw people marching on the base And they felt that if they did this well that the big birds would start coming down and giving them all the goods and services Well, it doesn't work that way guys All right, that's the cult of that cargo culting when we cargo cult We might be doing agile We might be coming up and asking three magic questions every day for 15 minutes Then going back and doing whatever else right doing agile doesn't work being agile is what does it? So we can do cargo culting. Here's the way you can take some notes if you want to do scrummer scrummer fall People have probably nervous laughter usually happens here. We could take a story and say okay We're going to split this story. I know you split stories in agile and scrum We're going to split it into an analysis story Then we'll have a coding story then we'll have a testing story All right, that's a good scrummer fall technique if you're looking for one another scrummer fall technique right is to take the story and Take it within the same sprint and have one set of people work on the analysis and then pass that off to others They code it then pass it off to others that do testing. That's another proven scrummer fall technique Please don't do that. What we need We need our cross-functional teams that can work all of the things at once Right if we want to be agile and we want to you know do scrum correctly. That's how we would do it Another vicious thing that we do. I want to spend some time with this. It's called matrixing Who here works in a matrixed organization? Don't be afraid. Okay. I Hate this guy Galbraith. He was up at Harvard in Boston, Massachusetts 1971 he wrote this paper called matrix organizational designs how to combine functional and project forms basically what matrix does is it takes your manager and Then assigns a whole nother set of managers and then says you can report To this manager for this project and you can report to this manager for this project and I'll still tell you stuff to do All right, so we added a lot more bosses along the way right, it's Comes From a from a desire to be efficient within our organization that comes from a guy named Taylor It was hired by Henry Ford when Henry Ford put together his first mass-manufactured plant in Rouge River in Detroit Hire this guy Taylor now Taylor wasn't isn't as bad as some people say he actually brought scientific method and Measurement to the workplace because before Taylor the way you got the workers to be more efficient was to beat him with a stick So instead Taylor comes and starts doing time motion studies and see reach But it's the efficiency that was the problem and too many times our managers now Try to make people that need to be creative to make them efficient. You can't be creative and efficient at the same time Right, this is kind of what it looks like in a matrix organization Right each person has like a percentage in which projects they're working on This is what it looks like in a matrix organization, right? You got a whole bunch of bosses Telling you how bad of a job you're doing Reason that that's a problem is that team members that are working are always task switching Task switching is an evil right it never allows us to focus Plus the task switching itself Takes time Right it and the time that it takes robs us Robbs us from forming true teams Right, so this is I always get his name wrong. So I'm gonna try to do it correctly Patrick Lencioni wrote a book called the five dysfunctions of a team and Basically what he says and this is the big diagram is that teams that don't form well will never never perform well Right if people can't trust one another on a team and they portray themselves as invulnerable When they don't trust one another on a team, they're afraid to start arguing with one another to get to the right things Which is called an artificial harmony when the people on the team are artificially harmonious They really can't make a commitment because they're afraid of Conflicting with one another so instead of making real commitments. They're ambiguous about what it is They're gonna do right once they're ambiguous then they don't want to become accountable The way that you avoid accountability is you have very low standards And once you're at that point where you're not accountable for anything you don't need to worry about results Instead when things fail you start pointing and saying oh it's his fault Okay, or the reason this didn't work is because of this external thing. It's not my fault people then start exploiting The situation for their own status and ego All right, so when software development teams are just kind of like put together with you know from a bunch of people that say Oh you guys you're a team to me that sounds like a pickup game. Okay, this happens to be basketball I'm sure it's the same in cricket. I know nothing about All right, I wouldn't want to be on a pickup game and try to play the pros I'm gonna lose every time the pros practice together. They learn their strengths and weaknesses They understand how to work with one another that they know one another. Well, they can become a high performance team And we need to do that All right. Oh, yeah, there's one more issue remember the matrix, right? We got all those project managers The second that something becomes untenable and somebody can't perform They're gonna tell their project manager. Who in the heck are you? This guy up here. He's my boss. He signs my paycheck. I'm gonna do what he says Right, so there's a real loyalty problem that starts coming up has to do with money All right, last but not least let's talk about task switching Now I'm not sure if the laws here are in India, but I know in the United States It's becoming like a heinous crime to text and drive as well. It should be right here are some statistics You know you're six times more likely to cause an accident Okay, then by you know if you're intoxicated. It's like having four beers 23 times more likely to crash. These are alarming type statistics. Yeah, people do it right The reason that you can't do it isn't because you haven't learned how to task switch Well, it's that your brain isn't made to task switch Okay, so Susan Wineshank talks about this a couple of quotes from her Okay, she talks about the fact that a task switch might take a tenth of a second But when you start adding up all those tenths of seconds It becomes really a big number right and task switching involves several portions of your brain Which I don't want to go through but basically what has to happen. It's just like when the CPU gets interrupted. We have to save some state put it away at a different part of our brain Readjust our focus to this new test to do Right and then get started with it Who in here has ever been in a debugger for you know two hours? They're just about ready to get the right result and then the boss comes in Oh, I got I need you for a second out here, right? Then you come back and you look to have no idea what I was doing two hours ago, right? Everybody I mean this if you coded this is going to happen to you there's another oh and Managers software managers sometimes haven't gotten that picture. They think oh this is software that people can juggle balls They can't it's the same as trying to text while you're driving This is much more important this diagram. You may want to remember this one, right? It comes from Joe Weinberg's quality software management system thinking And I just put it into a chart if you're working on one project you can devote a hundred percent of your time This was by the way, these were observations from awesome stuff that he did to observe how teams work If you're working on two projects the task switching between them is going to be about 20% To switch from one project to the other which means that you're going to become 40% efficient on Any one project that could be damning and that gets it gets worse and worse and worse He takes it out to five projects at five projects the amount of efficiency that you get I forgot what the exact number is like three or four percent He also says that your likelihood of actually completing any of these projects It's kind of random at that point because there's so much task switching that's going on So stop don't become another statistic stop the matrixing and that's how you boost productivity Let's tie it together now first part Bring projects to your teams and stop forming these teams to do projects in other words the matrixing thing It's wrong because it increases our whip Right, which means that we can't get the proper flow. We want to get down to single stream flow Okay, we also need to form teams that are efficient and can work with one another We also have to start favoring product increments not component increments Okay, and we understand the problem of big back big back big batch thinking Let me tell you a short story here There's a town of a town in Holland Dutch town called Drachten and In Drachten, so medieval town. They had a problem where inside the center of the city the flow of traffic was very slow and They also had a lot of accidents there. They were averaging around nine accidents a year in the early knots The people in Drachten, you know in the city council wanted better flow through the center of the city and They wanted to reduce the number of accidents So they got this guy named Hans moderman who came up with a really radical idea his idea to fix it Was to take all the stop signs out and take out all the traffic lights And somehow the elders of the city said, okay, let's give it a try what happened was an increased traffic flow and The accident rate went down from nine a year to one a year. Well when cars were invented in the early 20th century You had cars that were going, you know 40 kilometers an hour through the center of a city You had people walking at I don't know five kilometers an hour and they said well, that's a dangerous situation We want to do is make roads and put signs up there and traffic lights up there So we can control the flow of traffic. So when a driver is driving They know that they have the right of way and they can be safe and just keep on going They don't have to look around them and start making decisions Now we have that same artificial safety that goes on in an organization We put a lot of process traffic flow lights if you will to say we're gonna do this now We see what that is then we do that over and then we go over here instead if you can start taking out Taking out all of those gates Start loosening up the flow. You'll actually get better stuff going through your system And you'll change from a large batch mode into small hopefully single stream mode remember that all of lean Agile it requires sort of inspect and adapt cycle if you don't do it You're gonna feel like Bill Murray and Groundhog Day. Hope everybody knows what that is Never practice of methodology polytheism. Okay, which is this and that Right one d8 at a time guys what I mean by polytheism scrummer fall, right? We're actually doing waterfall and we're trying to do scrum at the same time It doesn't work pick something that works for you figure out something that works for you and throw the old way of doing it away Don't do two at once Finally start embracing the DevOps concept. It's not something you can just go out if you read the cartoon just buy a big box of DevOps All right, it actually is going to take some collaboration It's going to take the QA's BA's and developers the three amigos to start working together Right with QA starting to learn what has to happen in the DevOps kind of situation and then actually applying it And that ladies and gentlemen means that we're looking at the end We'll have some questions. We'll have some answers a little debate and then we'll depart Questions So Did you have a question? Yes I'm not sure how to answer that because it depends on how big of an organization it is in a small organization All of those defects that you're talking about Would get put into the whole mix of the backlog if we're talking about a scrum type environment Which everybody probably understands and then we would work through it all their organizations would look at those defects and say Ah, we need to scale because we need these people to do more development We'll have a different team to do the defects Maybe with the defects. They're all pretty small and you know, maybe the assumption is that they're all fairly quick What you might want to do is start up with a con bun so that you can learn you can learn where your whip Starts coming becoming hard. You can start learning what your process really is and then make improvements to lower it Right and then there's other ways of going about it But the important thing is that you've recognized that those defects can start becoming a large batch Right where we're going to take them to a change control board And we're going to decide on mass which ones we're going to fix next release and which ones were not think of it much more continuous flow And you'll be better off It may be part of your process of how you deal with them I do want to say that defects are wonderful requirements Because they say I did this this this and this and I got the yellow jelly bean and instead I want to do this This is a green jelly bean so we can write it away and know know exactly when the defect gets fixed It was a good question though. Oh, sorry take another one executable requirements. Yes Well, first of all, I'd like you to do it Monday morning, but you're not it's going to take a while Especially if you're not used to automation, you know and all that stuff Okay, but the first thing to start doing in that sense is to start learning about behavior-driven development That's the acceptance test that I happen to like Okay, if you're a Java type, you know Ruby type programmer The products look up or like cucumber if you're a dot net developer you're going to want to look up something called spec flow Same kind of ideas, right? Somehow you have to get started down that road because those are really great ways of capturing requirements Okay, and then you have to put them into your continuous build system once you get one anybody else. Yes, sir That's the problem The problem is that you know we're thinking in terms of uat and if you recall Scott's diagram We're waiting to do the testing when we're out here Right and just like the girls that were folding the envelopes They didn't find a problem till way late right before they're trying to ship and then they're pushing that rock up The mountain only to have it fall down every night So the way to get around that Okay, is to start that automation kind of really if I say things like a dependency inversion people kind of get the idea Right, we have an interface and our in our on our architecture We do a dependency and a version of control right one of the things that we start on is to make a test implementation that implements that interface in something that's either a fake or a mock some kind of a test double Right that will execute really fast Okay, so we don't have to worry about doing our end-to-end testing and having it take that long All right, so we'll typically test all the time You know with a mocked out or faked out interface then later on we start doing stuff in the middle of the night Over the weekend to run more of the things end-to-end all the time Again QA knows this stuff because they're the ones that are responsible for trying to get to work in that testing environment That becomes valuable knowledge for DevOps Sir I don't know the ratio it all depends on the developer right if the developers are really capable developer He's going to be able to produce code and unit tested faster than some QA's are going to be able to you know work and actually Do run the test against them so you're going to have to find whatever works for you This is a situation by the way where something like a con bun would help Because we would start seeing where things are involved and we're where we're getting a whip Pile up and then we would know to fix that by adding more QA people But this that's getting more advanced here than what we want to get to in this Yes, ma'am the DevOps isn't anything that's that's weird, right? It's not a person Right. It's kind of bringing in the operations people to understand what's going on When development is taking place? Okay, so that they get at more advanced knowledge of it if we're if I'm talking about QA getting a mindset of bringing testing forward I'm also saying operation should bring operations forward if you will and get involved earlier on Rather than throwing documents over the wall. Okay, we're done. Here's your here's how you take care of the system Doesn't work as well gotta get pretty granular doesn't it? Because we actually will have to put together test cases that you can verify and actually run through it and That is a problem a lot of people who like to write stories Like to be kind of vague. Oh the last me questions while we're doing development though We'll figure it out. It's actually a very vague and that vagueness Isn't good for trying to make commitments Right if you're in an organization that wants solid commitments You don't know how to commit to something if you can't really understand it and the faster you get towards Understanding exactly what it is to say that I'm done The better off you are the faster you do it the other side effect of this by the way is that once you start having a whole suite of unimplemented I'm sorry automated regression suite scripts, you know those gherkin scripts You can actually do a fairly decent job of seeing how done you are Right because you every script says it works or it doesn't as the number of working scripts starts increasing You're getting closer and closer to where you have to be to be actually completely done with a release That's a kind of a side benefit that you might get out of it Sure as QA relevant at all that's actually a really great question Because on a on a real scrum team and or let's just say a software development team and delivery team The roles should get fuzzed out Eventually you might not know the difference between a developer and a QA person because they kind of do each other's job sometimes It's also a really good reason that you want to do it as to upskill people So that it becomes a path of a career path You don't want to get pigeonholed as a QA person all your life perhaps you'd like to do other things or at least be exposed to it and It's a really useful concept to work with so yeah Sometimes I can't tell the difference between QA and development and that's a good thing depends on the typical definition of acceptance test driven development is At like a controller level, okay business logic level I believe there's a lot of value in actually doing the automation all the way up through like a selenium Okay, but using like a page object as as the mechanism that I'm actually doing my testing against Because I want to keep the problem with doing automation at the presentation layer is it kind of become very fragile so if you do it start looking into things like page object for selenium or other ways of Abstracting, you know, so that it's not so fragile. All right. We are done. I want to thank you very much