Good morning everybody. My name is Darren Davis. I appreciate you coming out this morning. This is my first trip to Bangalore but I think my fifth trip to India I am by no means an expert in India but I seem to have more experience of it than most of my friends back in the United States and so when they ask me about it I tell them well the thing you have to understand about India if you really want to understand India you have to understand that roughly 80% of the population is Hindu roughly 14% Muslim 3 to 4% Christian and a hundred percent cricket so the fact that you are all here this morning today during the semifinals between Australia and India is great testament to your dedication to agile and I appreciate it. I am the director of software engineering for Providence Health and Services. I'm part of their strategy and innovation group. Prior to that I worked as the I managed the development and mobile development and web development teams for a small coffee company called Starbucks which I think you you have a few Starbucks here in in India now. Prior to that back in 2006 I was a development manager for a company called Corbus. Corbus is a media and image licensing company owned by Bill Gates with a really remarkable ability to lose money so I I worked for Corbus for probably eight years and in that time it was never profitable and yet every year I got a five-figure bonus so when Bill Gates went from being the richest man in the world to being the second richest man in the world I like to say that I played a part in that just by working for Corbus. Incidentally I guess he's now back on top as number one because I no longer work for Corbus so I'll leave that to you to figure out. So 2006 summer of 2006 our sustainment engineering process was in a shambles and I when I say sustainment engineering I'm talking about what's essentially that developer gulag you go to where you have to do all the support and maintenance work on existing systems you don't get to do any of the new fun stuff you do small feature enhancements you do bug fixes that's that was our sustainment process and it was a mess we were running it as a series of waterfall-like projects fixed scope releasing every quarter I used to liken it to like scooping a load of socks out of the dryer and trying to crab walk it up a flight of stairs without dropping anything. Needless to say it was disappointing for all the reasons that you would expect a waterfall like process to be disappointing things we could drop from scope we'd run late we wouldn't be able to do as much as they wanted often when we did those things they weren't exactly what they wanted three months ago right so all kinds of heartache and a group of us were starting to talk about how we could pull this process out of the tar pit make it functional I was on the team that was doing that now at some point during the summer one of our team members a guy named Rick Garber and I'm gonna mention a few names during this that you've probably never heard of but that's that's kind of the point one of our teammates Rick Garber he went and we listened to a talk by a fascinating beguiling Scotsman a man named David Anderson who talked about how he had solved some of the very same problems on one of his teams at Microsoft using the a con bond like method based on the theory of constraints and the works of folks like Goldrad and Deming part of his process part of his method was to eliminate explicit estimation from the process and that was the thing that that attracted me first because I I've always disliked the process of software estimation I've always likened it to voodoo right it's just magic sometimes we at best it's a guess at worst it's a lie but some of the other concepts that he brought some of the other theories I thought were very very compelling as well I mean blew my mind to think of software as inventory that could go stale that's crazy it's crazy idea but it makes sense right particularly in these long waterfall cycles or these long development cycles what you start with at the end what your need is at the end or at the at the beginning is maybe not what it is at the end because the market changes the opportunity shifts right that blew my mind I never thought of it that way I never thought that it would be possible to make idle certain resources in order to get better systemic efficiency and the theory of constraints kinds of kind of proves that out so a bunch of us read his book we had a lot of impassioned conversations we were we were almost like religious converts you know our eyes shining with revolutionary zeal ready to remake the world or at least our sustainment process so we started designing our very own con bond based system now it took us a few months it extended well into the fall of 2006 and sometime during that that process David actually joined the company as the director of engineering I began reporting to him I'm gonna name some names here there will not be a test you don't need to to remember them but also on the team were Domenica DeGrandis Mark Groty Larry Cohen Rick Garber and Steven Weiss again a whole bunch of folks you probably never heard of David guided us through the rest of the process and finally about November we had we settled on a design a design that had his blessing so we trained our team we trained them in the in the theory of constraints and con bond systems in general we ran through simulations we we we populated our cues and with a fair amount of excitement and a little bit of fanfare we launched the first significant con bond based system that we were aware of it promptly went nowhere for months it went nowhere that was not our plan so obviously it was a little disappointing now keep in mind that the system we built was based on David's first book agile agile management for software engineering not a subsequent network not the subsequent work of other people in the industry of sort of embraced con bond and and taken it to where it is today there were there were no real practical examples of how to implement his theories in his first book right and and we designed our system based on the same way he had designed his at at Microsoft which he told us had been a great success and yet our process was quickly proving to be a non-starter it was very frustrating for everybody involved it was frustrating for the developers and and testers all the software engineers because they couldn't see where things were in the process it was very frustrating for our customers because they were only seeing a very thin trickle of work out of this grand experiment I'm gonna say it again the con bond we're talking about at this point the process we're talking about at this point there's no resemblance to the con bond that we know today it's an entirely digital process we've got 25 work items in TFS team foundation server scattered across 25 separate queues with this incredibly complicated web of transitions and reasons for transitions between various states we so over engineered this process and and maybe that's what was actually leading to some of the complication now according to the theory according to the theory that we all heartily embraced it should be a self-managing process it should have been a self-managing process all right that you just as a developer or an analyst or a a tester you focus on your queue right just focus on your queue something comes in you pull the work in you do it when you've got when you've got capacity you move it on right we designed it specifically so people just had that kind of telescopic focus on their particular queue and yet it didn't seem to be working they were they were complaining they didn't have any any sort of global view of what was going on I would like to say that we were we were hurtling toward disaster but that really implies way too much velocity I mean the truth of the matter is we were grinding to a halt the system was beginning to collapse under its own weight now in February of 2007 I got called into the CIO's office guy named Steven Gillette he's now president COO of Symantec I think down in down in the Bay Area in California and he said to me if you don't fix this I'm gonna have to fire somebody which you know it's a pretty motivating thing to be told I suppose I didn't actually think he meant that I had to fix it but I certainly believed that I was the one who would get fired if it didn't get fixed as it turns out actually he was talking about firing somebody else but that's a story over cocktails I think so I got together with David's leadership team we all got together and we said okay well what can we do to get this thing unstuck at the point at this point we're not trying to fix the process we're not trying to fix the process because we hadn't realized yet that the process was what was broken we were we simply I think naively thought it was just a problem of combustion right if we could just get the machine firing if we could just get it rolling downhill that it would get it would it would take off and we could just manage it the same way that we had we had originally designed so in order to get things unstuck we decided we would implement a stand-up now maybe it surprises you to think that we didn't have a stand-up you know it's an agile methodology we didn't have a stand-up our only experience with stand-ups to this point had been the stand-ups in our previous sustainment process where the team had heard about agile so they wanted to implement stand-ups and these had degenerated into these 30 to 45 minute daily morning marathon slogs it becomes very hard to stand up for 45 minutes and I you know if I've ever been dogmatic about anything in all this process stuff it's that your stand-up should only be 15 minutes long if you did if you stand-ups longer than 15 minutes I believe you're doing it wrong there I said it so we decided that we would implement a stand-up just to get things running we would do it for a month we'd run it for a month and once things got started we'd we'd go back to letting managing it the way we'd originally designed now I volunteered or insisted on running the stand-ups because I didn't want it to go longer than 15 minutes I knew that if I ran it I could keep it moving we'd get it done 15 minutes tops we'd be out of there now I'd never run a stand-up before I have some experience being on stage in front of people but I'd never run a stand-up for engineers and I don't know if you if you agree or not but engineers can be a very very difficult audience very very challenging they don't let you get away with much let's just say that so I didn't know what I was gonna do I've never run one before I had this idea that since people were complaining that they had no idea where things were in the process well we'll show them the process we'll put a board up and we'll put the work up there and they can see it but that I didn't you know I didn't really have an idea okay what is it gonna look like and I went in and I talked to some of our senior devs these were guys who were fairly high level in the organization they had out title of architect and as luck would have it actually they'd been spending the entire week that week doing a color domain modeling exercise I don't know if you know what color domain modeling is but it's using color-coded post-it notes to collaboratively design architectures to represent your system and it allows for very quick change to be able to iterate and iterate and iterate and iterate rather than have one guy go off for several hours and work on a Vizio and then hand it off and you know to others for for comment so they just been through this process this workshop with a guy named Daniel Vacanti and I came in and I said hey you know I want to do this thing they said okay yeah sounds like a good idea yeah go do that and one of the guys and guy named Kirk Kwame he said oh yeah you could use different color post-it notes to describe different kinds of things in the system right he just spent the week doing exactly that made a bunch of sense so I went that home went home that weekend I thought about it and came up with a very simple design now this is back in 2007 so the most common color of post-it note back then was a yellow this was in a time when post-it notes were not as evolved as they are today where it's very decadent there are all kinds of colors and shapes and sizes of post-it notes are very limited so yellow was the most common we'd use those for features things that people had asked us to do that's what we we'd use yellow to represent that we would use blue to represent bugs because both blue and bug began with the letter B and that was about as deeply as we thought about it right I mean it was that it was that kind of simple so that's how it began we started on Monday I got to work a little bit early I drew up some fairly crude cues I wrote up some post-it notes put some information on and put them in the right place and waited for people to show up now that first day we had told people to stand up was was actually optional you didn't have to show up to stand up unless something was assigned to you and if something was assigned to you then you better be there to explain it if need be but that first day most of the team showed up and I don't know why I mean it may have been because they wanted to be a part of something going on some new experiment it may have been because they wanted to feel like they were part of the team it was probably because the stand-up happened in a fairly public place and when I'm up there waving my arms is a little distracting and hard to do anything else but participate whatever the reason most of the team showed up that day and for the rest of my time at Corbis would be a pretty large and inclusive group so the first most pressing problem we were trying to solve and in fact the only problem we were trying to solve at that point is why stuff wasn't moving through the queues why isn't it moving through so to that end that's where we focus that's where we focused our our stand-up it seems obvious now I think when I think about it it seems obvious to that focusing on blocking issues is a pretty significant component in a stand-up whether it's a scrum stand-up whether it's a Kanban stand-up at the time we didn't know right it just seemed obvious so that was our focus over time we sort of refine the questions a bit but it really came down to is there anything blocking you that isn't represented on the board if it's not on the board and it's blocking you we'll get it on the board of all the things that are on the board is somebody specifically tasked right now with clearing that that block and you need anything from me the pointy-headed boss in order to get those things unstuck right that was that was really the focus and we didn't spend a bunch of time doing other kinds of what I think of as open mic night what we call open mic night in the u.s. I don't know if you know this you you know you put a mic up on stage and people take turns coming up and doing their little song and dance that's that's you know how scrum stand-ups always struck me you know here's what I did yesterday here's what I'm doing today we didn't focus on any of that you know we started making some assumptions we started assuming that you're an adult and you are a professional who takes pride in what you do and you're going to yesterday you did your job and today you're going to do your job and what I want to know is what isn't working in the process what's not right what are the exceptions let's assume that things are working and let's focus on the exceptions and that's what we ended up doing we always kept it under 15 minutes always often we would keep the stand-up under 10 minutes don't waste people's time but an interesting thing started to happen we would break up you know we'd say all right anything anything else all right going once going twice thank you everybody have a great day and people would start to cluster in twos and threes and groups and start to collaborate they start to have conversations there was an energy in the room there was an energy coming out of the stand-up that hadn't been there before people felt engaged they were leaning forward into the work they were using the board to plan their work this was all stuff we discovered right this was all these were all happy accidents we came across now I don't recall who came up with the idea of using pink sticky notes to represent issues I really I can't remember I wish I could I would buy them a drink because it was one of those very simple but brilliant I think innovations that help us helped us to stumble on one of the most significant benefits of contemporary Kanban and that is this visualization of the work in progress the inherent power of visualizing information now we didn't invent this right this if any of you know the work of Edward Tufti he's he's written books about this in the past that the quantitative or the visual display of quantitative information you know it's a it's a very highfalutin sort of title but it's essentially taking and being able to display in a meaningful way at a glance the state of a system and that's what we stumbled on in this Kanban process we could put a pink sticky note on an item and to even the most casual uninformed observer that clearly signaled that there was a problem you could stand way back and you could see the problem you could also see how things were moving through the system where their bottlenecks those became very clear what's the batch size of the next release you know those things became very clear from a distance but you could also then walk up very close to the board and you could see this developer is actually working on three different things we shouldn't have her doing that she should be focused on one let's help her refocus so you get different different levels of information different levels of data out of the same board again these were things we just sort of stumbled on and it seems obvious now but at the time it wasn't there it also became a focus of discussion and planning I mentioned this a minute ago our tester guy named Tom utter back who odd side note is also my brother-in-law and our build guy Doug burrows they would actually plan their work at the board they would use it to plan their work they'd be able to say well I can move this item in but that's going to take six hours of testing I should be moving it I'll tell you what let's take the one below it because that's only going to be taking me 30 minutes we can move that in they would they would strategize around the board it became a very useful tool it also became a great advertisement for people who are in the business you could walk you know our business owners could walk through at any time and see this all of it seems obvious now right wasn't so at the time so the process of prioritizing work this is this is what I think of as thunderdome this is getting a group of folks together to decide all right we have limited resources what are they going to work on next well this was a was done in a weekly meeting run by a woman named Diana Kolmets who played a vital role I think in really helping us codify all this but she ran the prioritization process and it was a representative from each of the various business areas marketing finance sales imaging they would get together once a week they went through several iterations like everything else but eventually what they settled on is this process of nomination where everybody would nominate items for the week to be worked on and everybody got three votes and then horse trading would go on if you'll vote for my item I'll support you on your item people would vote whatever got the most votes would we've moved into our engineering ready queue we'd start work on it now one of the guys a man named Drew McClain he was the VP of imaging he was a former military guy spent all his time in manufacturing it recently come to our company from Boeing which is you know airplane manufacturer so he was very familiar with all these concepts and he insisted that we include what's called a silver bullet which is an expedited request now we resisted this at first because we figured if we include a silver bullet in this everything's going to become a silver bullet right everybody want everybody thinks that their thing is incredibly important needs to be done right away but what we did is we put a couple of breaks on the process we added two rules we said yes we'll do this but on two conditions right condition one is that there can be only one one and only one expedited request in the entire process at a time not just in any individual queue in the entire process if something's been expedited and it hasn't been released for production you can't add another fairly simple rule right the other was nobody individually can decide that something is an expedited request or a silver bullet it has to be agreed to by all of the voting members VP of finance sales marketing whatnot so you had to convince your business owners and you had to come with a business case that said this was the reason it needed to be done what it did is it took it it took the technical team out of the business of trying to decide winners and losers and put that squarely in the business said you decide what we do next you as a business decide what the next most important thing is and then leave it to us to do the work it actually created a pretty solid feedback mechanism pretty quickly that and and we found that very few items got expedited I know out in the Kanban community there's a lot of discussion going on seems to be a lot of discussion going on around class of service and this starts to look a little bit like class of service this is where it began but we we did it in a very very limited way and we were always very nervous about it the other thing we got rid of was due dates right which again is another class of service you see out in the Kanban community we can have some discussion I think at some point maybe afterwards about the you know the the the pluses and minuses pros and cons of that kind of approach I I have some opinion about it but I'll leave that for I'll leave that for later so as I said that particular mechanism got very rarely used that silver bullet mechanism another interesting point that came up is really around service level agreements what was our service level agreement how did we report status how did we report the you know how how how what was our agreement with the business if they gave us something to work how quickly would we get it done now we sweated over this quite a bit in the beginning and established an SLA of 21 days from the time it gets prioritized for work to the time it gets released 21 days never made it once not once did we make a 21-day SLA we eventually bumped it up to 28 but we had to start somewhere right we didn't have any data we've never collected any data we had to put a stake in the ground start somewhere so we started with 21 days bumped it up to 28 eventually settled on 31 what we found though was that our business didn't care they didn't care that we weren't making the SLA because they could see where things were in the process they could see where they were we didn't there was no surprises it didn't get put into some black hole only to emerge three months later complete they could track it at any point and I think that kind of visibility that kind of feedback mechanism is really what got us off the hook maybe maybe it was because the previous process has been so dysfunctional that we'd managed to set the bar extremely low so this is just some this is some of the information some of the stories some of the things that happen when we were creating this process when we're working our way through this process what's the point who cares right ancient history happened 10 years ago why now why bother it's important I think for a couple of reasons and some of them are fairly trivial almost petty but some of them I think have a broader implication so let's start with the petty ones first I think I think that the people who did the work should get credit for the work right often history doesn't work that way I'm not I'm not so naive as to think that you know it doesn't the truth of the matter is it's easier to focus on an individual as being the father the progenitor of Kanban rather than think about all the aunts and uncles along the way right and so this is really just an attempt to kind of introduce some names to the record and make folks aware of it but also to make I think the point that we all have the opportunity at a very small very fundamental very daily level to participate in this kind of innovation and evolution of a process we all bring value to the process great ideas can come from anywhere I think it's also important because it illustrates the Gulf often occurs between theory and practice all right I'm a great fan of theory I love theory I really do but only in so far as it works in practice the the great American physicist a guy named Richard Feynman he said that it doesn't matter how beautiful your theory is it doesn't matter how smart you are if it doesn't agree with experiment it's wrong and that's what we were doing right we were experimenting and these theories that came in do they work in in practical fact well maybe there's some value there but they require people actually fiddling at the edges to make it work and that's what we did clearly David Anderson brought the intellectual framework for Kanban into Corbus and the theories as they apply to software engineering are really kind of compelling but Kanban as we know it in the industry today wouldn't exist Kanban workshops wouldn't be on the schedule at this conference you wouldn't be sitting here listening to me rant if a group of people hadn't been specifically tasked with making that thing work in the real world people like all of us in the room today people who are smart curious driven to succeed the solutions that we came up with work for us at that time in that context now I don't think anybody any of us were actually trying to create a development methodology that's not what we were trying to do we were just trying to make the system work so we wouldn't get sacked with regard to the innovations that made our system work that made Kanban sort of take off nobody was guiding the team nobody was telling us which things to do which processes to try which innovations to try next everything we did everything we did came from the team and was evaluated solely on the basis of whether it was effective or not anybody who tells you anything differently about the origin of Kanban is trying to sell you something the larger reason I think it's important is because I believe as an industry our focus is often in the wrong place I think we tend to focus on learning prefabricated methodologies like scrum and Kanban understanding the ceremonies and artifacts that define those approaches and becoming as well practiced at them as we can learning the recipes as opposed to learning how to cook we look outside our organizations and outside ourselves for consultants and coaches to come in and help us become better at these practices huge amounts of money are spent and made on certifications for various methodologies that as a way of adding legitimacy to somebody's opinion of what we ought to or ought not to be doing as as though there's a growing sense of orthodoxy around what is agile and what is not and what's the in the agile community I mean how many conversations have you been in or how many meetings have you been in where somebody has been in a sense set aside and told that's so waterfall right I mean you don't believe me how many people do you think would attend a waterfall India con conference and probably not a lot but I think sometimes we use that word agile like a club but it's my opinion that a scrum team or a Kanban team is a far less value to an organization than a team of agile thinkers people who are grounded in and have a very deep understanding of the principles behind agile but are empowered to question everything to experiment to fail to learn and move on and when I say question everything I mean question everything why do we reduce the work or why do we limit the work in progress if we have dedicated resources do we need to do that maybe maybe not if we're working in an MVP model if we're working toward a minimally viable product do we really need to do sprints maybe maybe not are we getting the kind of value out of our stand-up that we really think we are these are important questions to ask at the grassroots level to be empowered and empower our teams to ask those questions to try something new micro micro improvements on a daily basis so this is a bit of confession time here and I you know I may get I may get beaten up in the lobby over this but I'm not a fan of scrum not a big scrum fan but obviously I have a soft spot in my heart for Kanban right and I've used it to great effect at a number of organizations now as much as I love it it will not last forever either will scrum ten years ago the industry looked very different than it does today ten years on it's going to look very different than it does now its evolution and it's relentless as great as an idea may be it won't be the theorists that demonstrate its value it's going to be up to the men and women in the trenches every day people like all y'all in the room to prove the value and demonstrate those vow that the value of that theory to make that theory or those ideas work in the real world and that requires an agile mind so that's the end of my rant I'm sure we've got some time so if you have questions that specifically you want to dig into or challenge questions you have around what went down and why it matters or where we think the the the evolution of the process is going I'd love to hear it the team size so this was a sustainment it's the interesting thing so this was our sustainment ear engineering effort and we had said that as an organization we'll dedicate 10% of our team 10% of our teams overall capacity to sustainment to support and sustainment so there was no dedicated team it was a pooled it was sort of a pooled resource and the way it worked is that we established whip limits based on 10% capacity if we had 30 developers we had three you know we had a whip limit of three for example so there was no dedicated team the way it worked is that when an item came in and we got assigned to a specific developer because they had specific domain knowledge they would pick that item up work it move it on and then go back to their project work a little disruptive right it would disrupt the projects there was a little bit of inefficiency but that was the overall design so there really was no team size per se now subsequently we've used it in in project teams of varying sizes from very small just a couple of just a couple of folks up to projects that had 25 developers but we started to use we started to modify the process a little bit and get into something that was maybe a little bit more lean and not so much Kanban I don't know does that answer your question yes for us it was it was all part of this process of putting prioritization on to the business of creating a mechanism where they were responsible right there were rules of engagement but they were responsible for telling us what the next most important thing was they knew that they had that we had five slots open in our engineering ready queue and if there were three slots open that particular day that they could prioritize three things they had to argue among themselves as to what came next when we said you get one silver bullet we got everybody to buy in and the business self-policed we didn't really actually have to say that anymore right you had a VP over here in sales saying we've really got to get this done and the VP of finance saying I don't see the business value I don't see the ROI show me the ROI and I'll believe you right they became self policing it took some time and it took some evolution but by putting the focus over on them and the the business side it got us off the hook I don't know maybe maybe you've got other kinds of challenges this is I mean this actually gets to the point you know one of the points that maybe I didn't beat over the head enough that this is a process that worked for us and this is what we came up with in that time at that place your results may vary actual mileage may vary right that that I think it's difficult and probably the wrong way to go about it to say give me a boxed contained methodology that I can just adopt wholesale without doing without without thinking it you know from from the ground up some more grassroots what works specifically in your organization what does your culture support process and culture being very very intimately connected I could no more come to India and say you know how you guys can fix your traffic problems do it like we do in the United States right that's not gonna work right it's a different culture it's a different way of thinking well there you go see there you go I'm sorry you had a question I'd like to think that all my success comes from my charm you know that's an interesting question who knows I mean it's it's a difficult thing to kind of prize apart again it goes back to this this Tolstoy I would Tolstoy idea that all happy families are the same all unhappy families are unhappy in their own specific way right there's so many factors that can go wrong that it's hard it's hard to know you know it's all part and parcel of the same thing the queuing theory is interesting in that it works outside of prioritization when I first started doing when I was first introduced to these these ideas these concepts I I went home I was trying to explain them my wife and you know she was busy didn't have time wasn't understanding it didn't really care to understand whatever I don't know she's actually sitting over there so she can correct me if I'm wrong but I said okay hey look here's what I'll do in order to sort of model this and explain it we'll do the laundry using Kanban right no prioritization right but we'll do the laundry doing Kanban she's you know she's scratching her head gone I don't get it's no no okay here's here's how it'll work don't take stuff out of the dryer until you're ready to fold it and put it away now that creates capacity in the dryer you can take stuff out of the washer and put it in the dryer and then you can you know she's you know so I did that I did that for a couple of weeks right I ran it that way doing the laundry there's me doing the laundry you know and see there's the theory and then after a couple of weeks I went to her and I said look my love I'm very sorry I know I've been kind of crazy about this but I'm just interested in these ideas and you know I'm kind of excited about them and she said sorry you're doing the laundry so I think that the queuing theory works without the the prioritization right how you feed information into the front end is is a separate sort of consideration you can even do class service kinds of considerations up front as long as it doesn't affect that queuing mechanism yeah David let David left in January 2008 it continued through 2008 and then I left at the end of 2008 it continued as you know we had sort of institutionalized it at that point and it was again because it came from a kind of grassroots thing it wasn't a difficult thing to maintain that was the culture that was how we did it mechanisms were in place it continued to work very effectively where it got off the rails is when we tried to apply it to projects without modifying it somewhat and I think people like Dan Vikanti have done some work subsequently and others to actually apply it to more of a project-based thing now after I left after some other folks left we got a new CIO they don't use it anymore they're actually Corvus has gone back to a kind of waterfall model so sad ending sorry that's an interesting question I guess we does we design the process specifically around sustainment and maintenance in a pooled environment so being able to apply those to projects and do it effectively I think has has has been big I think one of the biggest contributions frankly and biggest improvements is some real codification of the analytics around flow and predictability there's been some great work done I think in demonstrating how you can get to a greater and more predictable system through better flow and better throughput so I think that's that's been some great work yes that's an interesting question I can only speculate about how Kanban as an idea came from from Japanese manufacturing into the into the US market it's maybe a coincidence and this is maybe kind of odd but I'll bring it up that David you know was very fascinated with Japanese culture and very exposed to that and and included in his theories other kinds of ideas that came out of Japanese manufacturing you know the elimination of waste and that sort of thing that came out of lean and the Toyota the Toyota manufacturing what's your second question though I mean the debt let's take the DevOps question separately but what was your you know it's interesting because Dominican Grandis who was on the team originally has actually been doing a great deal of work around the application of Kanban to DevOps I don't it's not it's not an area that I've really dived into but I don't see that anything that's inherently contradictory again it's a flexible mod it's flexible enough as a as a model that I think you can apply it in a variety of contexts whether that software development or laundry or you know DevOps or whatever and I think it brings me let me while I'm thinking about it to a point where people will say oh well it's very loose like Kanban is very loose and scrum is very structured I don't see it that way at all I think Kanban is very highly structured way of working it just happens to be very flexible and adaptable you can use it in different ways but the rules tend to be the same and the theory behind the rules don't change right women limit the work in progress focus on quality focus on flow and throughput you know those those kinds of things how DevOps affects that I don't I don't know that I don't see that I I see a contradiction or a risk there but I think the market or the the industry the the community of DevOps is going to have to to prove that out I don't know that sounds like a dodge doesn't it that sounds like I'm ducking the question yes I think that I think that what first attracted us to it was that that theory right with the theory that you can get to a probabilistic means of determining when software is likely to be done rather than a predictive measure rather than sit here and say we think it will take us three months say switching that around being able to say based on the data based on data we've collected we have a 95% likelihood of delivering anything you give us within a you know certain size within three weeks right that's our that's our and then you know one standard deviation out or two standard deviations out here's what it looks like I think that's what attracted it attracted us right and what drove us was really I think a belief in that in those ideas and a desire to make it work but then as it was originally presented to us it it's not as though the theory was incomplete but the practice that support of the theory hadn't been fleshed out yet and that's where we were able to contribute that's where we were able to engage and once you start to see things actually work there's something very very exciting about being part of something that you create right as a process you create and it was very much a grassroots effort very much us on the ground participating in doing this thing and seeing a difference does that answer your question and of course the fear of getting sacked yes yeah wow I mean that's it's everybody seems to want to know what's the future I I don't know I think it's not so much that Kanban or Scrum are going to fade into non-use I think it's that increasingly we're going to get away from these macro processes that everybody adopts and get into more dialects more flavors of things that are much more local and much more idiosyncratic things that address our particular culture right I think my experience has been that you cannot come in and lay on top of an organization a process which the culture doesn't support it just doesn't work it won't take root it won't be effective it just it creates a great deal of frustration and I think ultimately what what we need is more sort of framework around which to to to engage like a Kanban or a lean or a you know whether it's from or whatever and then allow teams to find local solutions within that that fit their culture again that sounds like a dodge to the question but none of us can predict can predict the future and I haven't actually participated to a great extent in the Kanban community mostly because I just went out and got a job and have been doing it you know in my own you know I've had conversations with guys like Dan Vakanti and the last time I saw David Anderson actually was in a restaurant in West Seattle in Washington any other questions yes that Kanban is useful for only certain things or in other words where you can't use crumb then go for Kanban really without understanding just have a board and you don't have the time boxing so it's Kanban so what are the different ways in which Kanban can be used along with scrum maybe even within a sprint we are experimenting with some of our projects that can we increase the effectiveness of sprint execution can we have says ground at the product level and Kanban for the teams so you must be having experiences with these kind of possibilities I mean my opinion is my yes my considered opinion is that you you don't it's not a binary world you know you don't have to do scrum or Kanban and it's it's just not that way that these are these are ideas frameworks tools things that you can apply and you shouldn't be afraid to experiment to figure out what does work to say and do it in a hypothesis driven way here's my hypothesis I believe that we can manage our product in a scrum like way but within that I want to track the work within sprints using Kanban and here's how we're going to do it and experiment see how it works see what you you know it doesn't need tweaking in order to actually be more effective and what does the team think how does the team engage and get ideas from the team again to my mind the whole lesson here is that we shouldn't be constrained to think about these things in a particular way and for me Kanban kind of helped get me out of that but I don't also want to then turn around and say well Kanban has to be done in a particular way right it just that feels wrong to me so again to me it goes back to experimentation it goes back to question everything do you need to do sprints right maybe you do maybe you don't so I don't know that that answer your question oh good yes I'm glad I could help yes yeah I I somehow suspected that this question would come up when I said I didn't like scrum you know I think it would be it would be interesting maybe next year to have a you know a panel discussion sponsored by absolute vodka you know and talk about the pros and cons I just I feel it's less about scrum as a methodology and more a kind of religious adherence to scrum that that I that I find most troubling you know the unwillingness to say that doesn't work or it doesn't work within our organization I think a lot of times what happens is that organizations feel that if they can't apply scrum by the book it's their fault and not the problem of the the or the you know the inappropriateness of the the methodology I don't know I wouldn't really label it as being Kanban is better than scrum I would say that for some organizations it works better in some situations than scrum but that doesn't mean that organizations can't also be very very successful with scrum I just I happen to find it just it's too constraining for me I want to do things differently also I hate the style of stand-up I got to confess I hate the style of stand-up I prefer a stand-up that focuses on the work and not on individuals right focus on the baton not the runner and I think a lot of times we focus on what you did yesterday what you're going to do today as an experiment you want to try an experiment go back run your scrum style stand-up what did you do yesterday what did you do today what did you do that around the team and then pick somebody at random and ask them what the third person did yesterday and see if they can remember and then decide whether or not that information that time spent getting that information was well used but that's a little provocative isn't it any other questions again I really appreciate you coming out I know that you know even now India and Australia are doing battle do we have an update on the match does anybody I'm sorry I have no idea what that means because I'm from America but is that is that good or okay all right again thank you everybody thank you for your time have a good day


Hi, everyone. Joe for Jasby's casebreaks.com coming at you with 2022 Panini Dauners Optic Football Random Team Break Number 6, the last filler, the only filler we got to do to unlock that next break. Top 12 will get teams at the end of the break. But first, the break. Big thanks to this group for making it happen. All the teams are in. Let's roll it. Let's randomize it two out of six, eight times for names and teams. One, two, three, four, five, six, seven, and eight. Two out of six, eight times for the teams. Oliver Jerry Harrison, Jr. is fired up. Jerry Harrison, Jr. does not like the way this game ended. All right, there's the first part of the list right there. No fillers in this quick little pack break. There's only four cards in this break. And there's the second half right there. Let's alphabetize, and let's print. That's coming up in the next video. All right. Thanks, everybody. Let's see what we got in here. We got a orange Tom Brady, 107 out of 199. OK, a Brian with the bucks, and a rated rookie trailing the Berks for the Titans. All right, now let's flip back over here. Let's gather everybody's names one through 30. I'm a man. I'm 30. And we'll match up with these teams right over here. So it'll be the top 12 after eight, six and two, eight times. Good luck. One, two, three, four, five, six, seven, and eight. Now, from 13 through 32, no go. Sad times, but I appreciate you getting in. Top 12, though. Happier times for you, because you're in the next break. Simon is in. So is Nathan, Sean, Tristan, Simon, Brian, Sean, Ed, Nathan, Brian, Brian, and Simon. The teams on top are the pricier teams. There you go. Even happier times for that group on top after eight times. Let's match up with the team. Here's how it shakes out. Check that. Simon, you got Buffalo, Brian with Detroit and Green Bay, Nathan with Seattle, Ed with Tennessee, Sean with Dallas, Brian with Carolina, Simon with Jacksonville, Tristan with Chicago, Sean with Indianapolis, Nathan with Denver, and Simon with the Los Angeles Rams. And we'll put Optic six next to your name so you know you won that in this particular filler pack. I'm Joe for jaspeascasewrakes.com. I'll see you in the next video for the break.