 Fine on your table is some stuff that you're going to work with so that's the materials for the workshop Okay, so I'm going to start with some questions Who here is doing TDD in your teams? Okay, if you're not coding yourself if you're a scrum master of your teams are What is the point of defining a test before you start? Sorry Fail early You do what is required just what is required Anything else? You'll know when you're done. Yes, and you know where you're going to right? You've defined up front where you're going So what is continuous improvement? Yes these two things together So in this workshop away before I go there, how do we do our inspect in a depth? What is the process we use or you guys use retrospectives anybody doing anything else? Okay, yeah problem solving So typically in agile we use retrospectives From lean there's a three thinking and kaizen which is where the title of this workshop comes from and They're all come from something called the scientific method And what is that? There are many explanations, and I'm going to do it as visually as I can We start off by looking clearly at what our environment is and Then we question and analyze we look deeply into first we look at and then we look in From that we formulate an idea about how the system can be changed what would be valuable and then we implement our experiment and That would be in the course of our sprint or however, we determine our the plan Then we stop and we check our results. That's typically where our retrospectives come in right we assess the implications of the change in the system or Do we so the point of this talk is That I'm not getting I think this area over here From months to months or sprint to sprint however long your sprints are week to week We make a change and we see at the end of those sprint whether we have succeeded in what and We measure our success and then we move on to the next one but to me there's a lot missing in understanding the bigger context of Are we going in a good direction? Is this change that we've made valuable? Is it going to help us in the long run? So that's what we're going to be looking at the ideas from A3 anything in kaizen. Has anybody seen one of these before? Okay, I hardly recommend Claudia Peron's presentation. This is a kaizen memo. It's quite simple It says before we this happened. We had this problem. We did this thing and the effect was that It's nice. It's simple But it's kind of small and it's aimed at individuals of very small teams and it it it's It doesn't contain enough for the agile team on The other hand you've got the a3 report. Does anybody ever use one of these? You have okay, I haven't it's very detailed. It's plan plan plan plan do check act It works very well at an organizational level and particularly in a complicated environment where you can try to predict In a manufacturing environment what you can change and where where that's going to flow down So that's organizations and for individuals. We don't really have a mechanism for those for teams So what I'm introducing is an idea for developing that for teams So how would we look at it for teams? We want to stop and ask first where are we now and We at any given time Your team your product team is in a current state. It's current right right now It's influenced by a variety of factors team factors are things like Who's in your team? Do you have the skills you need? How long you've been together? Do you have a stable velocity? How how mature is the team? product factors are things like How well you know your backlog? Are you working directly with the customer? Do you think do things like prototyping? Though that's sort of in information about your product. How mature is that? Organizational factors how agile is your organization? How well do you respond to change? What's your decision-making process? Are you hierarchical or decentralized? And technical factors what your platform is is that the right platform is this a legacy? Are you working with legacy code? How comfortable are you to change your code? Along with skills to fit that so these are all interdependent and They also exist within something called the bigger environment over which we have much less control your markets Your competitors the environment that you're in Where should we be? So there isn't an answer, but we can decide on where we want to go by setting a target condition an Idea that we are over here and these factors maybe our product maturity can improve Maybe our technical factors are dragging us down a bit. We don't know So we've defined a target way and then to find a way to measure our progress because wanting to go somewhere is awesome But knowing if you've got there is Much harder Okay, so the simulation we're going to do It's a before and after retrospective We're gonna do to the end of one retrospective in the start of another one We're not going to do the sprint as a simulation I'm going to give you that information The focus is on creating a mental goal what happens in our sprint So I'm going to give you a variety of things that have happened and how your team is going to respond to those Then in the second retrospective we're going to review the goal and look at what happened and what changed and Then reflect on the experiment process itself Okay Any questions? Okay, feel free to ask questions So if you have a look how many of you have had a chance to read through this already Okay, there'll be a moment. Let me tell you about your product. It's a web application It's a B2C contract management site in the financial sector And you've got some social media features with the idea that you're going to grow relationships You're in a medium-sized company Who transitioned to agile about a year ago and you've got five dev teams at varying stages of agile adoption So you're one team within this. This is your organizational context basically, I suppose The context Information here is made up in those blocks of product technical Organization factors and you've also got information about the last sprint You've also got information about your retrospective goal. Don't worry about it for now So retrospective one study the problem and create a taste of all hypothesis So you've got five minutes now to talk amongst yourselves in your team read through the system the information and Just become familiar with the problem the guys at the back if you'd like to come and join one of the tables and participate That would be fantastic You just simply have to stop until something is resolved. There's a wait So until that you can't go forward and sort yourself out. So these are subtle distinctions Try it. Don't worry about being particular about them. Just try to work out what you think is happening So in your teams now Factors, I just want you to use the flip chart find somebody who's willing to be a scribe at your table and Have factors that will accelerate the rate of change and factors the things that are happening in the organization that making things Go faster and things that are making it go slower Okay, it's just one way of analyzing your situation and you've got another five minutes for that Any questions? I'm gonna be walking around if you want me. Just give me a buzz. Well, you know wait No, just use one page we're gonna Probably have to turn over later to use all the paper But yep those two factors within those factors. What's making things harder? What's making things change faster? What's making things change more slowly? Yes Okay, so you have a look if you look at this the backlog is clearly defined and stories are well-drawn So that means things will be quite predictable So that's not it will reduce the rate of change, but it enables you to work in a comfortable way Okay Or not also that's So you've all had a good time to think about what is happening in the system What I want you to do now is pick it's one of the symptoms there are many in that Example pick one that feels familiar to as many of you as possible and Identify this is a problem. We have right now and Then define a target state This is where we should be with this particular set of factors So whether it's about your backlog or about team Relations or whatever it might be that seems right that seems familiar you have a little bit of experience with Describe the current state and define a target Yeah, a target state like the long-term ideal and again two three minutes talk amongst yourselves pick the pick one and Write down this is what is now. This is what we would like it to be The long-term ideal is is An overarching thing. It's not what you're going to achieve in the next sprint. It's a big picture So I would do it every six months or so maybe every three months not more from more often than that Gonna have something different current state the number of bugs is affecting our velocity So we need to improve our quality across the board and your target state The more specific you can be the better and Never have more than two open bugs is a possible the chances of you having no bugs ever is zero We work in software. There are a byproduct of software development. It's it's going to happen But to be able to manage them. Yeah, so that's an example possible one The retrospective goal is part of the formulating idea section as well But because of time constraints, I'm going to give this to you So previously you've spent some time and you know you've decided as your team already that pair programming on integration stories is the way you're going to What are the route you're going to use for the next sprint? It's only the next sprint remember So the relationship between the target and the goal is this Remember we had our current state. We had a whole lot of factors influencing it Now we've set the target Yeah, and we still got the same factors at play The goal looks at one or maybe more than one of the factors and says we're going to pick this area and Try to improve it. So and this one is pair programming is Mostly around team dynamics or it might be around your technical practices The hypothesis is What we're going to do next Hypothesis and do science is what my team members say every time we have a question do science on it by doing something we expect this result and This is the test area that we're going to look at so we've got a target condition And now we need to have a theory about why how to how the goal is going to help us reach that target condition So by doing something we expect this results Past conditions are we try it and we were right. So these are the symptoms. We see if we were right Fail conditions are we try it and we were wrong We didn't get the result if you don't land up getting to do it It's not a fail condition the experiment hasn't worked, but you haven't actually tried the experiment So then maybe you need to try a different experiment completely But a fail condition says we tried this thing and our expected result was different All right I'm going to do that in teams, but just for the clarity. So hypothesis lies in the whole area so you've got your factors that you're changing and The goal that you're implementing that will get you to the target area that the hypothesis Particularly ties your goal to your target state Says this is the action our improvement goal that we're going to implement and the reason we're going to do it Is because it's going to get us somehow closer to our target state Make sense So another five minutes in your team and then we're going to possibly have to run after this Technical skill like coding, which is the same thing as paper programming, right? We expect to improve our code quality and decrease the number of bugs you might have something like that You might have one sentence, but that sort of feel a past condition We note improvement and discoveries while we're pair programming and our bug can't decreases. We bring attention to bugs Our fail condition is we pair program, but there's still many new bugs being generated So you'll be able to see or your bug count hasn't changed or So We're not seeing an effect yet All right Everybody got something along those lines Thank you people So now we're going to do something like real life But it's not because I'm telling you what happened in it all of these things have happened. They are real events And how your goal is affected in a longer workshop. I would get you to do this yourselves You've got three week sprints in week one. This is the implementing your experimenters The development manager expresses interest in your progress So he finds out about your work and he wants to know what's going to happen with this pair programming is excited As you go along you discover a dependency on another team's architect Happen to all of you All right So this is going to have an impact week two comes along and you're busy grooming and you discover a Potentially large change that affects many stories on your backlog never happened to me So you're going to have to handle what how that's going to impact your project and Then you hit an integration issue and it takes you two days to resolve this between your social media and your Contract management section and you put a lot of work into that So it comes along and you make a breakthrough with an architecture change. So that's a good thing But the dev manager is unhappy that you're interrupting the architects team Yeah, so what happened? First off the dev manager was all interested in your progress This accelerates change in a good way if you had a bad relationship with your dev manager It might accelerate to change in a bad way, but in this case It's a good thing right and you hope that the dev manager will use your experiment to sell pairing across the team This doesn't feel like it impacts your project, but it does change the way you do things, right? Then you discover a dependency on another teams architect and this decelerates change because you slow down But what you do is you invite her to pair with you and with your team members so that you can get that knowledge across Your progress on your goal you have at least started pairing, but it's not as you expected it would be Second week comes around While you're grooming you discover a large change that affects many large and many stories potentially large This accelerates change also in a negative way because you're going to have to replan your release And you need more time from the architect Your integration issue hits you Also decelerates change because your team slows down, but everybody starts pairing and swarming so they learn a lot about the integration changes So the pairing on the integration issue does improve your knowledge You are still getting there with the pairing and you are still doing the pairing, right? So what happened in the third week? You made a breakthrough with the architecture change that will come as a result of swarming This accelerates change in a good way because you can get going again And you can take it into your release planning because remember we've discovered that change So the one thing impacts the other thing and you think the architect for all her help At this point tensions are a bit tight But the Dave manager is still unhappy that you're interacting with the architects team Which increases pressure and it may or may not change make change But it's something that's going to change the way you deal with it a Michael make things go faster or slower, but apps the anti But you discuss ways to work with her team in return because she's helped you you can help her and So your pairing your progress is that pairing has helped you resolve a difficult problem and it has made an impact on the project process And and because that's hard to remember I'm going to bring this around to all of you with all that information In the second retrospective Study the results and review your hypothesis So what happened in our check results? Let me have yeah, we can do this you've missed your sprint You have to replan your release But the architectural breakthrough will help save time You had to deal with some organization dynamics and you did manage to pair quite a lot Now you're going to come and review your experiment that you've just set up that was by doing something We expect this and a past condition health conditions what you want to check is where our assumptions correct and Which of the parcel fail conditions do we see and what does that tell us? Okay, for example In your hypothesis by sharing domain knowledge and technical skill while coding to improve our quality Oh, we we expect to improve our quality decrease. This is probably not clear to us yet Why because our goal didn't focus on bug counts So we didn't maybe measure our bug count We did pair but we might not have actually we don't know if we've reduced our bugs yet because we were so worried about integration Okay, so in your teams another five minutes, and I'm bringing you this so that you can look back at it if you need to You don't need to wait for the paper to start discussing that I get one of those back Did I give you three or two? Okay Pardon Just one just to share amongst each other you don't need one each I seem to Be a bit short and where is your hypothesis by doing something? Okay by doing that so in this where is your pass and fail Okay Yes, and and the expectation what's your expectation maintenance if not why not what happened in state? So what happened? You also want to think about how much closer are you to your target state and what might you need to adjust to get there? Two minutes because we really short on time I Both the outcome because normally in a respect you say we did we sort of did we didn't meet our goal Okay, did we need to do it again? Yes or no actually why and what what part of us failed or what part of the experiment? Not the people yeah, and which you can bring this into your retrospectives Do you look at when you have or haven't met them? Do you look at does that get us closer to where we want to be our big picture? It's the next short term cycle the next sprint Yeah I For a sprint, I'm looking at three to six months Yeah No So what happens is after you've done your initial set of agile ramp ups You start to tie to organizational goals You start to tie to bigger goals that are going to take you beyond the level of we are just doing agile too We are getting somewhere amazing and we can see if we're getting there or not And if we're not we can see where we want to change what little factor we can try to play with It's an experiment. It's business. So it's not it's but it's fun Checking what is happening and moving somewhere for it is fun. That really is the end Thank you very much for your very very active participation really good rest of the conference If you want to get in touch with me, that's how you can find me That's my blog my company senses the user group, and I'm on Twitter All right, if you want to have a question it is just before quarter past And So your goal is probably a little bit less smart For a long-term goal you want to have it you want to be able to know if you've achieved it But it might not be quite as specific because if you have a two type it's important to have a type for a sprint You can or cannot see if you can see what's happened But you might have something lucid and I do it three to six months not less than three months This is far too much overhead for sprint to sprint So what you could do if you've got lots of teams like they've got five teams is At a release level one team can take on we'll look at this side or you know, you can make it a bigger collaborative thing So when you're trying to do something and you Unsucceeding because of your organizational structure Being able to give Evidence as to why this will help you and why you need the change is very important Then sometimes you can make that change and sometimes you can't but you might find something else It's a nice a good way to cooperate But the thing that the test gives you is something to say this is what we're trying to achieve And we can't because of this this is where we've hit a stunning block You've got clear. You've got the words for it. Yes Thank you