Dan Vacanti
Transcript
[00:00:15]
Okay. Um, Can everybody hear me okay? I hope everybody see me hopefully. Yes, so wonderful. Okay, and all worked. Alright, uh, bonsoir mesdames et messieurs. Thank you for being here. That's about all the French that you're going to get tonight. Um, I almost said, did I say bonjour, bonsoir? I I guess it's bonjour for me, maybe bonsoir for you. Um, so sorry about that. Uh, but but thanks, thanks everybody for sticking with us through these through the technical difficulties, apologize for the delay in the start. Um, the good news is that this is a fairly short talk, um, so we still should have plenty of time for question and answer, um, still should have plenty of time to to to do everything that we we need to do still.
[00:01:02]
So thank you very much for for sticking with that. Um, along the lines of question and answer, because this is a short talk, I think what I'll do is I'll just go through the whole thing and then wait until the end and take questions. I normally like to have a little bit more interaction as I go through this. Um, but I think it'll make sense for for us to just get get through everything that that that I need to say. And then let's talk about the most important things, which is what all of you want want to say. So so let's do that and without without any any further ado, right? Um, Let's get right into it. So the secret history of combat and and why it matters. First things first, um, I want to mention that this talk is based almost entirely on, um, on a talk and a a blog post that a guy by the name of Darren Davis wrote a few years ago. Now, my guess is most of you have never heard of Darren Davis, which is rather the point of tonight's talk. Um, we'll get into who Darren Davis was and is, uh, just a little bit later. But I wanted to make sure that you put a face to a name, um, right up front. We had a we had a little debate before this talk, which picture is better? Um, he likes the one on the left, I like the one on the right, so that's why we we included both. So this is, this is Darren, and the reason you need to know about Darren and and who Darren is. uh, because Darren was a a senior manager at a company called Corbus, C O R B I S, a company called Corbus in Seattle. uh, back in 2006. Um, and uh, Darren was on what was known as a uh, sustainment team, um, at Corbus. So sustainment was sustainment means at least in in in the Corbus sense of the word, what sustainment means meant was, um, small fixes, small enhancements, you know, um, hot fixes for production issues, things like that. So it was eventually essentially kind of a keep the lights on type team. This team would come together and responsible for uh, for, you know, software that was in production, making sure that that was up and running, uh, running well. Um, the sustainment process in 2006, if we go all the way back to 2006. The sustainment process at that time was um, probably most closely resembled what you might know as a waterfall process. They did, um, they did, I think three or four releases a year, they tried to, uh, they tried to do a release every quarter anyway. Um, they had big planning up front for what was going to be in that release, once they did their big planning up front, that scope was fixed and the whole team had to march toward that toward that schedule. Um, and as you can imagine, they almost never hit their release date. Um, they almost always ended up dropping scope, um, and almost always the customers didn't get what they wanted when they wanted, right?
[00:03:57]
So Darren and his team got together and was was tasked with the, um, with the job of kind of fixing this process. Because just in general, their their customers weren't happy with how sustainment was going. Some people who are on this team, um, one person, you hopefully you may have heard of before, Dominique De Grandis. Um, I believe she's spoken in France at some some other some point in the past. But Dominica Duranda was on this team, uh, another gentleman by the name of Mark.
[00:04:36]
And last but not least was uh, was Rick Garber, um, who was on, um, who who was on this team. And it was Rick, the the reason I want to call out Rick especially is because as the team was going through this uh through this process. Um, Rick went and happened to attend a talk at Microsoft given by a gentleman by the name of David Anderson. Um, and when, um, Rick was at this talk, Mr. Anderson was essentially explaining some things that he had done, um, with another team at Microsoft, that was essentially everything that the team at Corbus was trying to solve. Uh, so of course, this got Rick's interest and he was like, well, um, you know what? Maybe we should, we at Corbus, start looking at some of this stuff that Mr. Anderson was doing to help fix our problems. Now, I want to take a step back here, before we get too far down the path. I want to take a step back, I want to make sure that everybody understands, um, at this point in time, in 2006. Uh, what David Anderson was talking about was based completely on this book. I don't maybe you maybe people have heard of this book, maybe you haven't, but it was an Agile management for software engineering book. This was by no means Kanban, and in fact, we weren't even using the word Kanban, you know, at this time. But all of that that work, all this initial work to fix sustainment at Corbus, was based on, you know, on on this this uh, this particular work. So what the Corbus team did was, you know, they they started in, you know, um, taking a look at what was in this book, they started taking a look at what potentially could help, um, help their sustainment process. And over the course of doing all of that investigation, they ended up hiring Mr. Anderson as the senior director of software engineering. Um,
[00:06:33]
Now, again, I can't stress enough, uh, what you know as Kanban is nowhere near, um, what we were doing what they were doing at Corbus at that time. So not only was, you know, everything that they were thinking about based on this agile management book. But everything that they implemented was actually implemented in a tool called Team Foundation Server. Most of you have probably heard of Team Foundation Server, it's gone over it's gone through several iterations, you know, over the years. Um, but the idea was, the idea was, you know, the the initial fix that they came up with. the initial fix for the sustainment process that they came up with, was, um, they set up a bunch of these, these for lack of a better word cues in TFS, with each person on the team on the sustainment team being responsible for their own queue. And so what you would do as a as an engineer on this on or as a team member on the on the sustainment team, what you would do is you would log in every day and you would look at your queue. And from time to time work would just show up in your queue, and whenever work showed up in your queue, you were supposed to take that work, you were supposed to work on it, you're supposed to mark it complete. And when you did that, TFS in the background did all this kind of magic with transitions and things like that to move it on to whoever the next person in the process was. So, number one, and I got to be very, very clear about this, there was no overall visualization. No one person had kind of an end-to-end view of what was going on. As a as an engineer, all you saw was your own particular queue, and the idea was supposed to be that by just focusing on your, just having blinders on and just focusing on your part of the process. that the system was supposed to kind of self-level, right? It was just, you know, it was just the the work was just supposed to kind of kind of manage its own way through the process. Right? Of course, you know, that was that was that was certainly the idea. We we'll come back to how successful that was, um, you know, or not, maybe just just a little bit later. But so yeah, so so no visual at this point, no visualization, no explicit setting of work in progress limits, no end to end, no person had an end to end view of of what was going on, right? So this is the idea, this is the idea that they came up with, um, at Corbus. And so after after working on this for several weeks, potentially I think even a few months, um, in November of that year. Um, all that design was done, all their initial setup of TFS and everything, all of that was done. And Mr. Anderson blessed the result. said, hey, this is exactly what I want, this is exactly what you what we need for this sustainment process. Darren, go off and make make this happen. So,
[00:09:23]
what Darren did is is with, with, you know, some excitement because, you know, the team was was kind of excited to implement all of these new ideas. So with some excitement and maybe just just a little bit of fanfare, Kanban launched. So we're talking about the end of 2006 here. So Kanban launches.
[00:09:40]
and flops. Immediately flops. For months. Right? Um, Darren likes to say there's this there's a there's a quote that I love to attribute to Darren. Darren likes to say at this point that uh, you know, as part of this this this whole Kanban launch, um, that they were hurdling toward disaster, uh, but that implies way too much velocity.
[00:10:06]
The truth of the matter was that they were grinding to a halt. So in the old waterfall world, at least they were still getting releases out the door. Those releases may have been late, they may have been not had everything that their customers wanted, but they were still getting releases out the door. With this new brand brand new system that they had come up with, they weren't even able to release software. Everything grinded to a halt. Right?
[00:10:32]
So you can imagine that customers are not too happy about this. Right? And when customers get angry, because like I said, before they were getting work and now they're before they were getting value delivered and now they're not necessarily getting value delivered. And so when customers get angry, they don't call Darren Davis, they don't call David Anderson. They call the overall boss in charge of this thing, the CTO of Corbus, who at the time was a gentleman by the name of Stephen Gillette. So Stephen Gillette's getting all these all these angry customer phone calls. And so Stephen summons Darren. Darren gets summoned into into Stephen's office. And Stephen sits Darren down and says, You know what? Somebody is going to have to fix this process, or I'm going to have to fire somebody. Right? And you can imagine, you can imagine Darren's mindset when he's sitting in the CTO's office, saying, hey, I'm going to I'm going to have to fire somebody. Darren thought the implicit threat was that his job was at risk. Now, now it turned out it was it was Mr. Anderson who ended up getting fired a little time later, but that's that's for a completely other um, other time and another conversation. So it wasn't Darren's job that was at risk, it was it was actually David's job that was that was at risk.
[00:11:48]
So Darren goes off. And he's say, he's like, okay, we, we, we need to fix this problem, right? Our customers aren't getting value, even when they're not getting value, there's no way for us to go in and see where that value is, where that value is stuck, you know, what's what what what's happening, right? So, what Darren and team decides to do.
[00:12:08]
they decided to get together and they they're like, you know what, um, in order to fix this process. Dominica sticks her hand up and she says, we should might we should maybe start doing something called a standup. Right? Now, now remember, they were kind of Corbus was in this kind of waterfall world, they weren't doing anything that might resemble agile practices, not that a standup is necessarily an agile practice or not, but, um, So Darren so Dominica is like, you know, let's let's let's let's try to let's try to do something called a stand up. Uh, and Darren was like, and the team, the rest of the team agreed, yeah, you know, this is a great idea, let's get together every day and let's let's, um, let's talk about what we're going to do. Um, and it was decided that Darren was the one who was going to facilitate the standup. Now, over the weekend, before they were before they were going to start with standups. Darren starts thinking about these, he's like, okay. We're going to have the stand up, but what are we going to talk about? Right? So remember, I said, there's there's TFS and then there's nothing, right? So Darren's idea is, you know, we we have to. We have to get this stuff visualized. We have to get our work out there and, you know, out there and, you know, for everybody to see, you know, we we need to have this this single end to end vision of of what's going on, because I'm not going to stand up and in front of a computer, you know, start pulling up different queues in TFS and run a standup that way. So he's like, let's put up a whiteboard and we're going to discuss where where our work is and we're going to discuss any any blocking issues. Uh, now this is when our hero walks in. I I I know you you guys are probably wondering, um, when our hero will enter the story. So it's about this time, um, kind of serendipitously about this time. uh, that I was at Corbus as an independent consultant, um, and I was doing a class on on color modeling. Um, some of you may have heard of color modeling, domain modeling before, you know, this is where this idea that, um, you know, objects in a model take on certain archetypes, and when they take on certain archetypes, they, uh, they connect to each other in repeatable, predictable ways. That's not important right now. What what is important to know is that, you know, the the power of the visualization of color modeling and using color as one of those dimensions to communicate that that visualization. Kirk Quami, um, happened to be in that, um, in that color color modeling class, and he was also on this sustainment team. So at that point, Kirk put his hand up and he's like, Well, you know what? If we're struggling with what we're going to visualize and how to visualize it, why don't we just take a whiteboard and put colored post-it notes up on a whiteboard and we'll use that to manage our work? Um, and that is exactly what they did. So you can see this is this is a picture of the um, of the very, very, very first Kanban board. This is this is one of the very, very early iterations. I don't know if it was the actual first one, um, but it was a very, very early iteration of the first Kanban board. And you can see it's it's it's it's fairly crude. Um, but all that all the aspects of Kanban are there in terms of visualization and limiting work in progress and and things like that. And, um, it evolved not only, it didn't stay crude. because as they operated Kanban, they learned and and they evolved, and so you can see they went from kind of this version of a board to kind of this more version better version of a board. You can see much cleaner, much more obvious what's going on, you know, things like that.
[00:15:36]
The transformation was so successful that it was decided that, you know what, we we're going to take this Kanban process. and take it out of just sustainment, because right at this time it was only with sustainment and we're going to try to apply it to the rest of our our whole engineering, um, department.
[00:15:55]
So this is where our hero comes back in. Our hero gets called back, um, and and so my job is when I went back into Corbus, sometime later after the sustainment thing was done. was to take everything that Darren and his team had done and apply it to product or project work, right? So it's not only, it's not just maintenance work anymore. It's like, how do we do this? Um, Corbus was at the time trying to ramp up two very, very complex, uh, projects. The argument could be made potentially too complex. Um, but uh, Corbus was scaling their engineering team at the time, uh, you know, they were going through, um, you know, a team of about, you know, 6 to 12 or so individuals using a fairly ad hoc engine I think what could best be described as an ad hoc engineering process. Uh, and they were trying to scale that up to about 60 engineers, um, so, you know, 10, you know, five to 10 times the size of the team as well as a whole bunch of other consultants that that that they brought in. So I my job was to sit down and and this picture is with some of the team leads at the time. Actually, these these individuals, this is another thing to important to point out. These individuals at the time in the old Corbus engineering process were called architects. Their their job title was actually architect. But in this new way of working, they were going to be called team leads, um, because they had they had the domain knowledge and the expectation was that they would put together their own teams or subteams, subteams if you will, um, you know, to do this work. So we we changed their not only did we change their job title, we changed their, um, you know, their responsibilities right off the bat, right right at the very, very beginning. So, we literally got the team together because of that. We got the team together and we said, all right, let's let's just forget about how you're working right now. Let's forget about that ad hoc process. You guys are no longer architects, you're now team leads, let's get together and let's decide how do we want to work. And we did essentially kind of the same thing that Darren did with the sustainment team is we hijacked a blank whiteboard, uh, and as a team, we kind of brainstormed what that process what that process was going to be. Um, So, you know, I want to I want you to think about this this right now. Maybe those of you who maybe know Kanban or maybe have heard some things, you know, about Kanban before. You'll notice kind of the common thread between all of these things. There was no start with where you are now. It was both in both cases, it was pretty much let's let's hijack a blank whiteboard and let's decide how we want to work. Now, did that how we want to work bear some resemblance to how they were doing work now? Well, yeah, kind of, you know, because they were using TFS and things like that, but for the most part. we weren't handcuffed by, we have to start with where we are right now, we have to respect current responsibilities, we have to pursue incremental evolutionary change, we didn't do any of that. Right? None of that with the with with with the first that that first Kanban board. Um, And you can also see, you can kind of see the results, you know. So this is this is that scaled team that I was talking about, um, and notice all the happy happy smiley faces and and things like that. Um, you know, it was it was a tremendous success, even though we didn't do, and I would argue these things were never part of, quote unquote, quote unquote, Kanban. Um, most of you know that I cannot do a talk without having some some mention of class of service. Uh, because this is, you know, class of service is something, um, that I think gets gets mentioned a lot with with Kanban. even though again, it was really, really, really never part part of Kanban. These these are Darren Davis's words, by the way, these are not mine. I just want to get his words, you know, on the record. When it comes to class of service, it's he says, don't do it. It's like, like really, really, don't do it. Um, whenever we had these expedites or these things that showed up, they call us they call us these fluctuations and flows that ended up making things worse, not making things better. Almost almost always, whenever some type of new class of service showed up or new work item, you know, based on an expeditor or fix date or whatever, almost always screwed up. And as a result, we did everything we could to not expedite work. In fact, it was it was our kind of stated stated goal to design our process so that work flowed through as quickly as possible at all times so that there was no need to ever expedite anything. Um,
[00:20:30]
and of course, date driven requests were also eliminated early on, because we had a fairly predictable flow and because we had, um, at the time what we called an SLA. Um, now I think SLE is is a much better language, um, in terms of how long it was taking items to flow through the process, we didn't even need to have those date driven requests. So all of that class of service stuff, not only was it not part of Kanban, we tried everything we could to not use those things, you know, so here's maybe maybe my my favorite picture.
[00:20:59]
picture from uh from the whole presentation. You can see on this board, there's no there's no expedite lane. There's no there there's no no no any of that. So to review, and I want I want to be very, very clear about this. any of you who have done any work with Kanban or any, um, you know, any or have have any understanding of of what you think maybe maybe Kanban is. Um, things like, like I said before, you know, start with where you are now, um, you know, respect current roles, um, pursue evolutionary change. None of that, none of that was part of Kanban. In fact, the first Kanban system had absolutely no visualization whatsoever, it had no explicit setting of work in progress limits, all of these things that you you think that you know about Kanban, were actually the results not of a single individual. that maybe you might think they were, but actually were the result of this team. this sustainment team at Corbus, who came together, um, and developed these techniques, and their only goal was just to make their job better, their lives better. And it turned out it evolved into this into this this other thing, which I, which I think is wonderful. Okay. So why is this important? Why why am I even talking about this? Why why this is this is what 14, almost 15 years ago, you know, who who really cares? Um, you know, the short answer is it really isn't that important. Um, I mean, and in the grand scheme of things, in this era of global pandemics, racial injustice, you know, you know, economic strife, when we think about all the things that we're dealing with right now, who really cares about what happened you know, on a team at Corbus 15 years ago. Um, and that that's for the most part true. However, um, having said all that, all those things that I just mentioned about those things that you might associate with Kanban. I I just believe it's crucially important, number one, I just believe it's crucially, crucially important to give credit where credit is due. Um, you know, these are the people that made it happen. There's some other people in here like Diana Kolet, who was a project manager, Doug Burrows, who's a build engineer on the team, Tom Oderback. These were the people who came together. that made Kanban happen, the the Kanban I think that you know you know and know and love right now, you know, um, they were the ones who who had the ideas, um, who had who had the, um, the the initial courage to do the things that that they needed to do. And the thing is, it's not I don't I don't I don't want to I don't want to state this in the wrong way, but
[00:23:39]
it's not, it's not a coincidence that you haven't heard of most of those people before. You know, there has been. I I believe, um, kind of a a systematic attempt to have their contributions either ignored, minimized, trivialized, or outright stolen. Right? The ideas that they came up with, were never actually ever attributed to them. um, or actually stolen. So, so number one, I think it's important that
[00:24:04]
the people who actually did the work should get the credit for the work that they did, right? And it's it's it's it's it's been far too long that they haven't got the credit that they deserve. But kind of more importantly than that, um, although only only slightly so, uh, is the Kanban community over the years, I think has has kind of lost its way. Um, there has been there has been a again, an attempt to usurp, um, what what Kanban really is and what it should be and especially what the community should stand for. I guess again, in in in my opinion. And the thing is, I want when I think about a Kanban community, you know, I want a community that is really for the benefit of all and not just for the profit of one. You know, when we talk about, you know, having having these people who come together to have their ideas, um, to be taken seriously, um, I I think that is this that is of crucial importance. Further, you know, I want a community where people feel safe to participate. You know, free from any sexual harassment, free from any bullying. Free from, you know, from from the worry that I was talking about before that their contributions will be will be minimized, trivialized, or even just outright stolen. You know, I want I want to I want a community where there is a safe place, a safe, inclusive, diverse place where people can come together and learn about Kanban, um, and it's not necessarily just about lining the pockets of of a single individual. Um, I also want a community that recognizes that no single methodology. or framework has a monopoly on all the right answers. So many times we get lost in endless debates, endless uses debates.
[00:25:56]
around what's better Scrum or Kanban, what's better safe or Kanban, what's better, whatever. Who cares, right? Who really cares about that? Nobody has all the right answers. Absolutely nobody has all all the right answers. So I think we're we're better served by putting our our energy, investing our energy into building those bridges rather than than putting up walls. You know, creating this this this area where we can all learn together, right? Um, so just as kind of a side shameless plug here, we've a bunch of us in the community have got to have gotten together and launched an organization called proconban.org. And again, the whole the whole purpose of this proconban.org is to create a safe, inclusive, diverse community where you we can come together and we can do all of these things that uh that that I hope we can do. If I can sum that up in one sentence, that's that's what I've got right here is it's it's our aim to bring professionalism back to Kanban, right?
[00:26:58]
So I'm hoping this is this is kind of the call to action if you will. Uh, I'm hoping you will join us to build that community that I think we all want. If you if you're at a conference like like flowcon France, um, my my guess is you're interested in things like Kanban. Um, and if you're interested in things like Kanban, you know, the the invitation is open to everyone, uh, to join us in this, um, you know, in this attempt. to get back to where I think we need to be, you know, as as a community. And remember,
[00:27:27]
if you ever, ever, ever get a chance, if you're ever if you're ever out and about, if you're ever at a conference, if you're ever wherever. Um, and you happen to run in one of in into one of these people. Um, I want to make sure that as I want to do right now, I want to make sure that you say, say thank you to all of them, because I don't think we would be here uh without their contributions. So,
[00:27:51]
thank you, thank you to all of the the people who created Kanban, all of Darren's team and the rest of people. Thank you to Flowcon France for the invitation to be here. It was, you know, certainly my pleasure. Thank you to our sponsor tonight for for making this happen, as all of you know, conferences can't happen without without the the dedication and the help of of sponsors. But most importantly, thank you to all of you for taking time out of your busy schedule, um, time out of your evening, uh, to come and and discuss things like like like Kanban and and process and maybe maybe esoteric history. So.