 Good morning everyone. My name is Sean Dunn. I'm an Enterprise Agile Coach with IHS and this is my colleague, Chris Edwards. And he's also worked with me from IHS. And this presentation is called The Seven Sins of Scrum and Other Agile Antipatterns. And it was put together by Todd Little and the three of us. Todd's VP of Product Development at IHS. Most people have never heard of our company and that's okay. And what we do is we provide information, data and analytics to a variety of industries including energy, aerospace, defense, transport. We've got some team somewhere that breaks down iPhones and iPads and figures out exactly how much it costs to produce. So that's kind of cool. So most people have never heard of us but we do a lot of interesting things. We're from Canada, right there in Calgary. So that's where we're from. So a little bit of a disclaimer is that this is The Seven Sins of Scrum but there's not actually exactly seven. They're not necessarily sins and this isn't necessarily limited to just Scrum. But we did kind of break things into seven broad categories and what are we really trying to say? Well, the Agile Manifesto says that we are uncovering better ways of developing software by doing it and helping others to do it. And the authors I think had a really insightful way of doing this is saying we value these things but if you want to value something we have to be very aware of what things we are willing to maybe sacrifice. You can't have a value without having some kind of cost to it. So while we value the things on the right, we value the things on the left more. And so this presentation is based a lot of our experience of working with teams and identifying lots of, we call it anti-patterns. And what is an anti-pattern? Jim Copling described it as an anti-pattern. It's something that looks like a good idea but which backfires badly when applied. And anti-pattern sounds a little bit negative but what we're really trying to say is that we really want teams to be great. We work with teams and want teams to be great but oftentimes they'll adopt practices. They'll not quite understand things and it'll limit them. They'll just be good but we want to help them become great. So we were looking for what are some of these patterns that we've observed? And so this is the auditor's manifesto which is we value process and tools over individuals and interactions. It's everything flipped because that is while there may be value for items on the right, we have chosen to ignore them because they are difficult to audit. We only care about the items on the left because we can measure them and because we care about them we will make sure you do too. The format for this talk is going to be the sinner's manifesto which is what are some, call them potential sins. Some things that might be limiting. If you're doing these it's not necessarily bad but it might prevent you from becoming great. And so it might be okay in moderation. Everything's better in moderation including collaboration but in excess it can be an anti-pattern. So what we propose is some virtues on the right hand side that would help teams potentially overcome this. And agile is all about learning. By iterating we can learn, we can learn faster and we like this quote from Galileo. God has endowed us with sense, reason and intellect. He has not intended us to forego their use. So in everything we do in learning we want to apply our reason and intellect. So we do encourage everybody to do that. Okay, so the first sort of sin category is process and tools over individuals and interactions. And this is the only one that really is based off the manifesto. And the reason we have this first is because a lot of times we see companies doing agile transformation and they'll really focus on adopting these scrum practices and I'm using rally and therefore now I am agile. But really in complex software projects we want to bring projects to teams and allow them to figure out. So this is a great version of the agile manifesto from Alex Kravitzky which is blah, blah, blah, blah, blah, blah, blah, blah. Individuals and interactions over processes and tools, blah, blah, blah, blah, blah, blah. If you take nothing else away from the manifesto it's about individuals and interactions and teams and how they interact. And oftentimes we somehow get this gets missed. We get kind of focused on how do we implement the tool. So an often one we see is, okay, agile transformation. Okay, let's roll out a new tool and then everybody becomes really, really hyper focused on how do we use the tool properly. We need to be using the tool the same way. Teams need to be using the tool now as opposed to really understanding what agility means. And all these tools and processes are all in support of agility. They're not a means to them. And this relates to agile as a mindset. So this is a frequent thing we'll see where teams will get kind of hyper focused on agile is a process we need to implement. Even at this conference and even with teams we work with, I don't know how many times I'll hear quote unquote the agile process. And that usually causes a funny reaction on my face. And it's really helping teams understand that it is a mindset. These are values. And what do we mean by values as they influence behaviors and decisions on pretty much everything we do across software development. When you're sitting at your desk programming, you're making micro decisions on a moment by moment basis. And what are we valuing in each one of those decisions? And it's the values and principles from the manifesto. So it's understanding that these values really permeate all of our behaviors and decisions and actions throughout our work. So has anyone ever been part of a committee or group that was there to define some best practices for the company? So the word, I don't really like this word best practice because it implies there's no better practice. We've already arrived at the best practice. And it also kind of sounds like, well, every practice, this practice is good for everyone. You know, we have different contexts, maybe one team is co located and the other ones distributed. So how can we say that that the same practice will work best for both teams? So like Sean was saying, if we start from the values and principles and see are these practices enabling us to deliver frequent value to our customer, then really we can find what works best in each situation. And I mentioned at the beginning that Agile is all about learning, right? So what kind of value does that communicate to your organization where we say, we need to implement these best practices that have been somehow figured out elsewhere, right? That that's hugely disempowering where it's like there's there's experts out there who develop these best practices and we just need to implement it. The thing that really resonated with me when I really started understanding, you know, Agile and working with Agile companies was, ah, I can contribute, I can discover new things. It's not a society of experts who have discovered everything and I just need to follow what they're doing, but I can be a contributor to the expanding body of knowledge. That's a hugely empowering environment to be working in. Yeah, mob programming, NERSH doesn't like it, but that's fine. It was invented or discovered by a group of people doing everyday work slowly looking at what they're doing, trying different things. You know, we're all growing and involving our Agile mindset and processes and discovering new and better ways of doing things. And whether you agree with mob programming or not, it was invented by Hunter and it works for them and it works for them in their context and they discovered it through experimentation. And the really interesting question is what was it that enabled them to experiment with things? Like, what was it in their culture and their way of doing things that actually allowed them to come to new discoveries? Forget about what the discovery was or whether you agree with it, but that they came to new discoveries on their own. Yeah, and I have a friend that works at Hunter and I was asking him, oh, can you do a presentation for my company? You know, we really like to learn about mob programming and they're actually very hesitant because they're worried people are just going to take it and be like, oh, now we've implemented mob programming and now we are doing mob programming. And without, you know, if somebody just implements this new way... Best practice. Best practice without understanding what are all the things that led to it, they might miss the point entirely and implement something that doesn't work for them. And I think we covered this. The idea of one-size-fits-all versus context. So believing that we just have to take, you know, Scrum as it is out of the book or Kanban as it is out of the book and it will fit in all situations, in all environments, but really teaching teams to appreciate the context within their work environment and how to really understand and assess all these different techniques and tools that are out there and how they may apply or may not apply within their own context. All right, status over flow of value. The key to this one is really that a lot of times we are looking at metrics and things in our system that are really looking back. Metrics that are making us feel better about how we did but not giving us any information about how we can deliver better flow of value to our customers. So how can we look at different things that we're doing, all the different things we're doing and identify the ones that aren't really contributing to delivering value to our customer and eliminate them. And one way of doing this is always being kind of focused on the rear view mirror. Always looking back and the status is often about looking backwards, right? It's looking, well, where are we right now and how did we get here as opposed to, okay, what is it going to take us to deliver value and move forwards? And so much of it kind of comes from maybe a traditional project manager report of, okay, what's the status of things, what's the progress of things? And we want to try and get teams to shift the conversation towards, okay, what do we need to do next to deliver value and move that forward? Yeah, a lot of metrics we gather, you know, we do tasks and we gather estimates and a lot of this is focused around individual performance and not performance, not performance of the system itself. And what we really care about is how effective is the team at delivering value? Do I really care about the individual utilization of any one person on the team if my team as a whole is not being successful? So ask yourself what kind of things in your work environment do you do intentionally, maybe unintentionally, that might incentivize us behavior? Who uses tasks and keeps track of tasks and individual tasks? Is that contributing to a team taking ownership over stories or does it encourage individuals trying to complete tasks? Even individual ownership of stories is another way. It's like, well, I got my story done, well, wait a second, they're actually team stories. So becoming really self-reflective of things we may do in our workplace that might actually encourage this over the team taking collective ownership over getting things done. If helping Sean is actually going to make me deliver my task later and I'm going to get in trouble for that, am I going to help him? Probably not. I had a conversation with a team about that. So they're having their stand-up and someone was great on them for being transparent and forthcoming and saying, this user story I was working on, it looks like it's going to be longer than we first thought. So it might take a significantly large portion of time. And then the conversation just kind of went on to the next person. I was like, whoa, wait a second, wait a second, wait a second. So why is no one kind of volunteering to help? Like this was clearly the most important thing, like this was the highest priority thing and we thought it was going to be easy, which is fine, we were wrong, not a problem. But now what are we going to do about it? And the team members said, well, I can't help because then I won't get my tasks done. I'm busy. It's like, well, manager, if you tell me. And so here was a team that had been practicing Agile and Scrum but did not really understand the fundamental of the team ownership of user stories. They were still thinking in terms of individual work. So stories over strategy. I've come across this on projects before where teams will be working on stories but with no kind of understanding of why. And not only is there no kind of understanding of why, it's not connected with, okay, how is this actually going to meet some higher level objective within the company? Are we going to increase revenue, decrease costs, reduce risk? How is this story going to ultimately achieve that? And that makes a huge, huge, huge difference because you may split stories in fundamentally wildly different ways depending on what your strategy is. And so when the team doesn't have any concept of what that strategy is and they're just kind of like blindly chugging through stories, you can run into some situations where, hey, our output is huge. We got, you know, have high velocity, deliver lots of user stories but ultimately weren't connected with any kind of strategy. So on our teams, like, I've been a member of a team, I've been a developer on a team and we tend to encounter a large number of what I like to call, like, micro decisions. These aren't like, do I work on this user story or do I not work on this user story but there's little tiny decisions we make within user stories within items of work that without a picture of a grander picture, do I understand should I do this or should I not? And these things pile up very quickly, little small amounts of extra work. Well, I might default to, well, I better do it because, you know, if I don't do it then the customer might not be happy. So this leads to this, there's this thinking of we need to build these buckets of work but if we have a strategy that helps us decide what not to do, we can limit the amount of work done and still achieve the same outcome then we're actually going to be more productive and get more done. So if any of you familiar with user story mapping? Yeah, so to me that's a great tool. Jeff Patton's book, User Story Mapping, Read It, and it's a way of looking at workflows and how to deliver value to the user and ultimately prioritize your work and what don't I have, if I had to ship this today, what can I throw out the side to still deliver that same outcome? And so strategy should tell you what you're not going to do. If a strategy can't tell you what you're not going to do, it's not really a strategy. And we're sometimes guilty of this and features are a great example where we bucket things into features. User stories are kind of all related. So we'll bucket them into features and then these become these macro decisions. Well, do I choose this feature or this feature? Well, that's actually kind of a false decision, right? I have to get it all done anyway. I have to get it all done anyway. So I might as well just do them all. What decision filters can we provide so that people can make micro decisions? How do I choose between this user story from this feature or this user story from this feature to deliver value a lot faster? Which, as Chris mentioned, I've got to have it all. This all or nothing mentality over the idea of having minimum viable products and we've seen development teams who've been told, well, we're not going to release until we get this all done. Product management will say, we can't release until we get this all done. And then that leads to very lazy thinking and very lazy prioritization. And then guess what? They change their mind and you're partially way through and they're saying, we need to ship now. Can you have two top priorities? No. And so we were... Sorry, I didn't hear that. Could you say again, please? Okay, that's... Maybe we'll talk afterwards because I just want to make sure I understand your context correctly before I give a simple answer to that. So yeah, great question. It was if a product manager asked for an estimate for a big thing and then we give them an estimate and they build some plan off of that. What do you do in that situation? So yeah, if we could talk afterwards, I'd like to understand your context. Thank you. I touched on this a little bit, this idea of focusing on tasks versus stories. So tasks are a great thing if you're really into micromanagement because I can track people's hours. I can look exactly what their output is. Did you meet your estimate? You said this was going to take five hours and it took you six. What happened there? So this leads to focusing on individual output, individual performance rather than team performance, which by the way, you can do with stories. I've seen teams that, you know, here's Sean's story and here's Shane's story and here's Chris's story. So you can still get this with... But I think the idea here is what we really want to focus on is team value delivery. How are we as a team delivering value? So I would actually encourage anyone here who does tasks on their team, run an experiment. Just try not doing that for a while. Let the team figure out the details. I think we'll get to this, yes. Very good question. So the question was if we don't have tasks, how do we track things? How do we track progress? And I think we'll get to this. And it's somewhat related to a previous slide about status versus value delivery, like looking backwards as opposed to what can we do to move forwards and deliver value in the form of stories. So, yeah, we'll get to that. All right. Another one is following orders over understanding why. And we'll often encounter this in situations where teams will be very used to just, oh, tell me, you know, just you give me the user stories, tell me what to do, and I will gladly go off and do that. And why is that not a good environment that enables, supports agility? And here's my explanation. I spent 14 years in the Canadian Army Reserves as an Army officer. And there's this misconception that the Army is very, you know, we call it command and control. You give orders, you take orders, you do as you're told. That is wildly false. And the reason is war is this complex, changing, chaotic situation. And if someone tells you orders and you just blindly go off and do them, the situation's going to change and you're going to have to make decisions on the fly and you need to understand the bigger picture, the overall intent, because when you're told to cross a bridge and the bridge no longer exists, what do you do? You need to call back to headquarters? Well, maybe the radio's broken. So what do you do? You need to understand the bigger picture and that decentralize of control, that decentralize of decision-making speeds decisions. We talk about the micro-decisions that are made on the daily basis. So we really, really try to work with developers and coach them and help them feel comfortable with asking why. If you're a development team that has a customer embedded in your team, that is the greatest experience ever. Most of us don't have that luxury. But if we can figure out a way of injecting the mind of the user into our developers so that they really understand what the user's trying to accomplish, they're going to make much better decisions. I really liked... So I don't know if any of you saw the talk by Richard yesterday in the morning. He was talking about how they actually send out anthropologists into the customer's world so they can get a really deep understanding of them. I thought that was fantastic. So one thing you can do as an experiment is listen. When you go back to your teams, just pay attention and listen. When you're talking about user stories and doing backlog-looming or planning, listen to the types of questions that are being asked. What types of questions are developers asking? Are they asking what to do? Are they asking for definition on specifically how they're to implement something? Are they asking questions to help them get a better understanding of why you would want to do this? What outcomes are really being trying to be achieved? How do we do it, Tom? Halfway. All right, this one's one of my personal favorites. This isn't part of the manifesto, but this is actually Uncle Bob Martin, one of the original signatories wishes that this was the fifth value on the manifesto, craftsmanship over crap. There is a principle about technical mastery, but a lot of the original signatories feel that maybe they could have had a bit more emphasis on this. Because we can focus on delivery. Delivering value is great, but if what's under the hood is a pile of crap, then we are not going to be sustainable in the long run. Velocity over quality. Lots of teams have this belief that our job is to increase velocity. Velocity is this thing that we can just improve and improve and get better. In fact, if we're not increasing velocity, somehow we're not doing well as a team. We're failing as a team if we're at least not increasing or if our velocity is wildly varying. That's a bit of a misconception. Velocity can vary and does vary and doesn't actually even get better. We had a talk on that yesterday. The belief that velocity is what we care about when we actually care about delivering quality products that reduce the total cost of ownership over the total lifespan, that's more important than getting hyper-focused on this velocity metric. This is the testing period. I think this was made famous by Mike Cohn. Testing quality in versus building quality in. Going back to being busy, individual utilization, developers are always busy. Let's not waste their time with this testing thing. We have people for that. We'll just get them over here and we'll start building lots of manual tests. What happens? Manual tests are expensive. Now I'm going to have to do them a lot and now I have this giant regression cycle. Logically, we should automate them. We've got people that can build UI automation but they don't really understand the code so it makes more sense to just build some automated GUI tests and we'll just build an army of UI automators and we'll build this amazing test suite. What happens? They break a lot, they're slow and they're not really giving us any real feedback about when we break things in the code because the most optimal time to identify a bug that we inject is the second I write it. What do we want to do? We want to focus on building automated unit tests, integration tests. This is less important. They add value but they don't add as much value. There aren't many things I would say this about in Agile but I would actually say that if you're not doing some form of automated unit tests or integration tests that you really cannot be Agile. How many people here work towards some kind of deadline of some kind, like there's some date on the calendar that something has to be done by? Is that pretty common? Okay, it sounds pretty common. Here's a story that there was a deadline that the project manager ignored. This was the four Taurus. Four Taurus in the 80s. Product manager for the four Taurus took his time to understand the market, do market research, do all the things right to make sure that the thing they were building really would succeed in the market and he completely missed his deadline. He was six months late. But the car was a wild success in the market. He achieved the outcome of wild market success but what was the outcome? He missed the deadline so he was demoted. So what did the next product manager do for the next iteration of the car? He made sure above all else that he met that date and that car was a wild disaster. So by creating these dates we have this idea that well this is this is this firm date but in reality things are a lot more fuzzy than that. So understand your cost of delay. If you are one day late delivering this, what is the cost of that? In some cases and we talked to Spotify, we were talking with people from Spotify last year and they've got some things that has to hit the Christmas season. If it's one day after Christmas there's absolutely no value to it. It has a very steep cost of delay curve. If you don't get it done by that date, it's hard. Most projects aren't like that. Lots of ones if it's one day more but you can get this much more value then make it one day more. So understanding this context of what's your cost of delay curve is really important and not creating these artificial drops that don't really exist in practice. And one more thing I want to say on that is think about what is your organization reward? Do you reward people who deliver on their deadlines or do you reward people who build high quality products that achieve the outcome you're looking for? So I was talking about this gentleman over here I was picking on him. Did you meet your estimate? Why didn't you meet your estimate? Because what I was building was more complex. Okay, but you didn't meet your estimate. The questions we ask people imply the values that we care about. We tend to go to developers and say we need you to get more done. We go to testers and be like make sure there's no bugs in the software. So what are the developers going to care about? Are they going to care about the quality of the software? The developers are going to care about getting more code out sacrificing intrinsic quality for the long term. Testers are going to detect more bugs because of it and then you just end up with this again you've lost team ownership because now they're just pointing fingers at each other because you've asked them different questions and therefore communicated that different values to each group. So Ford, there was a knowledge in the company that if you deliver on your timelines that's how you're going to get a promotion. Nothing else matters. So what are people going to optimize for? So I think this might address the question. So there's this idea that in an iteration we need tasks and we need task estimates in order to be able to track the progress of the team on that iteration. So actually it's really easy to get my estimates to follow this line but that doesn't really tell me anything. All it tells me is I'm working. I'm busy. Still busy boss. There's a huge amount of variability in how long stories take. So I might take a three-point story and some of them will take me a day and some of them will take me a week. Maybe that's okay because in the long run it's all going to cancel out. What we really care about is the progress over a release. How much value have I delivered? How much value do I think I need this top curve and where do I think I'm going to be done? And this is a long-term forecasting versus sort of short-term management of tasks and hours and what are people doing. What we really want to do is trust the teams to get the work done and then forecast long-term where we think we're going to be at. Good question. I think it's coming up. That's our answer for everything. We'll talk about that later. So another aspect of this is we think we kind of cover this. Focusing on commitment and we need to make commitments. Commitments are the most important thing. Does commitment have any correspondence to what it means to be motivated and doing the right things? We really want to be focusing on value. Everybody has the same idea of what value is and are we all at every moment doing the right thing to be focusing and generating value? Generating value. Commitments can influence decision and I talked about fixed scope, fixed schedule. Those are all things that we can do that can influence decisions but are we influencing decisions in the way that we want? Are we influencing the right decisions? Has anyone been in a... You're working in iteration and you're getting near the end and I don't want to start a big thing so I'll go hunt down the backlog and I'll find something small and I'll work on it. What if that's a really low value thing? Am I just working on it? Am I working on it because it's valuable to the client and if I don't meet my commitment my boss is going to get mad at me. Iterations are artificial. We invented them. We made them up and that does not say they're not useful but understand what they're useful for because you can also use them in ways that influence decisions in a way that's suboptimal. We're not saying iterations are bad what we want to think is how are these iterations, how are these commitments influencing our decisions and do we understand those are the optimal decisions? What's that? I think we touched on this a bunch this idea of capacity planning which is all about looking at individual utilization what we really care about is team performance. I don't think we need to say anything else on that. The next category of sins is category number six which is illusion over reality. What kind of things are we doing to fool ourselves? We're not saying tasks themselves are bad they can definitely be used for good. Put in the wrong hands they can be used for evil. They're a micromanager's dream. In fact, I've seen cases where tasks enable collaboration and enable teamwork. I worked with a team where they were really uncomfortable to people working on a story but then we sat down and broke down the work that was involved in the story we're like, oh okay there's ways that we can collaborate and work on this together definitely there's value to them absolutely. You're delighting the product owner by delivering them something. There was something much higher priority that was next on the backlog and you had an opportunity to get a one day or two day head start on the next highest priority thing that the product owner determined was the next highest thing. I think the key here is yes. Now you're thinking about value delivery how do I optimize value delivery versus how do I meet my commitments and make my boss happy? I think with a lot of these questions it's great because it's like know why you're doing something. If the team understands why tasks are something that they want to do because it helps them do their work then great. The prioritization of the user stories was done because it delivers then great but understand why you're doing what you're doing. Great questions. This is yours. There was this comment about now that we're doing this this is a is everyone familiar with release burn ups not iteration burn ups? Is anyone not familiar with them? Good. A lot of times we'll do the release burn up and we'll get some kind of velocity on here and we'll look at how many user story points do we have left to deliver and then we'll sort of draw this horizontal line and then I will forecast and this is what I'm going to be done. If you look at this chart we have this continual scope creep it's kind of growing along the time just as we've been delivering the amount of scope that we have left has been increasing. I don't think scope creep is inherently bad. We're always discovering new value that we think we need to deliver. What's important is that the cost of the scope creep is going on to the development teams. This is really do we work on this is a business decision and what we want to do is find ways to be transparent to our business partners and show them the cost of the scope creep because if you can say if we continue adding scope in the way that we've been adding we will be done way out here would you like to keep doing that? So it's having those adult conversations as we have it with the business how do we enable what kind of tools have been used facilitate those adult conversations and help them make them aware of the consequences of the trade-offs of decisions. So you know people on this side want they want fixed time and fixed scope usually but what we want to do is find ways of having conversations with them to provide them options would you like to have this amount of functionality on this date or would you like to finish sooner or what kind of options do you want and what kind of ways to not push those decisions on to the development team we want to have these interactive conversations with the business Okay So another one is vanity metrics over decision metrics what kind of things are we measuring and why do we care about them and often times what we'll do is we'll measure things because it makes us feel good or makes us look good or something like that I've talked to teams within our own company they kind of come as this epiphany we do these things because it kind of makes the numbers work out right like they're making decisions making behaviors because they feel like oh this is how we make the numbers work and there wasn't useful for any decision that was the key they didn't understand what decision this information was driving and without having a decision information is useless if information doesn't influence any decision it's absolutely useless information so what do we really care about is decision metrics what decisions do we have to make at the individual level, at the team level at the portfolio level what decisions do we have to make and what information do we need and how do we get that and how do we make those decisions better yeah and one thing I'll add to that is Sean did a talk yesterday on no estimates and one of the questions you asked was what decisions are enabling are we enabling by gathering estimates I think we could go down a rabbit hole if we start talking about no estimates but I just want people to think about as an activity on their own it's a very hard one actually to take this concept of estimates and map it back to some underlying decision that we're trying to make and if we don't understand what that decision is are we wasting time gathering those metrics because it does cost last category organizational hacks over leadership so are we just putting out fires and doing little tweaks to our organization to fix short term problems or are we understanding the values and principles of our organization and how our current structures are not meeting them and embedding leadership into the company to solve those problems over time I really believe that we need to be thinking about how do we build a self sustaining organization over the long term if these are truly values and principles it's not just something the development team does they are embedded at all levels and we have to make sure that they get passed from one generation to another to another and that we can teach future generations of people and leaders at all levels really understand them because it's their job to develop the people underneath them in these values and principles and so we need to be sure we need to be aware of what kind of things are we doing or just kind of like organizational hacks to get around organizational dysfunction and start thinking about the long term is how do we build the organization that really internalizes us the path to waterfall is led by many many rational decisions I think I'm going to need more details of examples but maybe we'll take that offline afterwards we've just got a couple of minutes left so we'll just quickly go through some examples of organizational hacks for leadership and one is controlling input micromanagement what we want is controlling outcomes and managing outcomes and I'm an electrical engineer so I'm familiar with control systems and what you really want to do is create these feedback loops create these stable systems by using feedback loops which can handle complexity much much better than very input oriented systems Dave Marquette turn the ship around he talks about specifying goals not methods and this goes back to do we understand can I fill in the blanks fast forward a little bit certification over qualification this might be a controversial one we don't have a problem with certification I don't know how many letters after my name that I don't really care about I like learning and that's important to me certification is the byproduct of the learning unfortunately some companies can get a little bit maybe hyper focused on the certification and what that does is we encourage that this is something we value we value certification which if you've read the book about fixed versus gross mindset which is Carol Dweck and it can reinforce the fixed mindset I have the certification now I know everything as opposed to you want people who have the idea of there's so much more out there we want to learn and grow we're actually looking internally because there's a lot of buzz in our company about certification so we're looking at some different ones one of the ones we're looking at is IC Agile which is not well known in the industry so people are like is anyone going to care about this on my resume and so we ask if you don't learn anything if this isn't going to build your knowledge do you really care about the certification think about and understand what you really value in organization what things you're doing to incentivize or disincentive so our summary those were the 7 broad categories and the virtuous path is use retrospectives always do retrospectives improve incrementally and get coaching as needed and there's our contact information and this is Todd's book stand back and deliver he's my boss so I guess I got to promote it this is Todd's talk originally so we're adopting I don't know if I made it sound like IC Agile doesn't do the learning thing that's actually why we're looking at IC Agile because it has an embedded like learning aspect to it all right so I'm sure we start up loss of controversy I think it's the theme for today so there's lots of good questions we'd really like to discuss maybe offline and I'm sorry we couldn't answer all of them as part of the talk but we do want to have that discussion so please find us outside afterwards still listening to us ramble for 45 minutes that was fun we've got some time to take questions okay two questions or maybe we should readdress the questions that people have already had well I mean there's 50 minutes till the next talk so if people do want to go I don't want to but we'll stick around and ask questions yeah if you need to go please feel free now but we will stay up here and answer a couple questions oh sorry we've got a question oh in the service industry so in the service industry they're largely based on I don't work in the service industry I work in a product development company so I can't say I'm an expert on it what I do know my understanding is a lot of it is based on firm fixed price contracts firm fixed price contracts are fundamentally based on distrust in my view they are risk transference the company that is purchasing the once bids is saying I don't want the risk I want to transfer all that risk to the company doing the work because I don't trust them therefore I want to fix state I want to fix scope fundamentally at odds with the manifesto and customer collaboration over contract negotiation and a lot of the dysfunctions and waterfall we saw and how waterfall evolved in the first place was to try and make these types of contracts successful I'm thinking like IT organizations where people are evaluated on how quickly they close a request or a service request I've sent service request to an IT group you know they'll do exactly what I ask them to do because that's what they're being evaluated on did they meet my underlying need or solve it in a different and better way I think if you're building long term relationships and building trust over long term and you care about that and you value that then you can do that in service organizations you can build established relationships because people are happy with the ultimate outcomes they understand you care about their outcomes and the plan might change and that's okay but I think that's the type of environment I like to work in I'm not sure how about I'm not an expert on that there might be other experts here who can raise their hand and talk afterwards another question is there one to serve under okay thank you guys that was a lot of fun I hope you enjoy the rest of the talks today we'll be here all day all week thank you