I’m great.
Todd: Just to kick us off a little bit before we get into things, maybe tell us a little bit about yourself and what brought you to Agile 2013 here.
I am CEO of Net Objectives, I formed it back in 1999 and back then I actually formed it on the basis of design patterns and object orientation, but really pretty much for the last 13 years have been just as much in the process space with Scrum, Kanban, Kanban method, Lean. Really our business is helping other businesses manifest more value, and I just keep looking for what’s missing, what’s known, it’s not so much as extending the state of the art to me as what do we know that we are not taking advantage of, what are people in the industry not taking advantage of where it should be able to be used and manifest it in their organization. So, it’s kind of a guide of knowledge I guess and that’s our mantra, how do we take things that are understood but not being utilized and help other people discover their paths themselves and drive from business value is a big thing for us, how do you actually manifest value in the market place faster than just focusing, say, on the teams, which is good, but it’s like the engine to your car, we like to look at the whole picture.
2. What in particular drew you to Agile 2013 this year?
What I like about Agile 2013, to be honest, there are just so many smart people here, I just love talking to them and I love talking to a lot of the consultants, and I love talking to people and hearing the stories and their successes. I was talking to somebody last night and he was “oh, Al Shalloway, I am so glad you are here” and I learned a lot more talking to him, just hearing how he does things, innovative things, that’s what I love, I love chatting. I hate to admit it, I’ve only been to one session so far and yet I have been learning so much by chatting with these folks and I would say that is the main reason. There are incidental reasons, I do like to give my own talk, I am doing a Kanban talk tomorrow, I do like to drive business from it. But it’s really mostly the ability to chat to practitioners and to consultants and for people to get excited if I’ve got something good and tell me if I’m doing something wrong, when I am doing something wrong, it seems about 50/50 but it’s a good blend. So, I learn a lot that way.
I’ve been through all the Agile methods, I was big on XP when it came out, I still love XP, I think XP as a set of engineering practices, is brilliant, and I really like Scrum, but I’ve felt like after a few years of great success with Scrum, then starting around 2004-2005 we started having trouble scaling it, I realized that Scrum is this great team method but the methods that work at team level don’t help it scale. Then I got into Lean with the Poppendieck's work and then Kanban, having actually helped get the Kanban conferences going and LKU going and things like that. But all these methods seem to focus on one aspect of the problem, they all seem to build from certain axiomatic truths like things are to software, like gravity to building to bridges, things like delay causes waste, delays and workflow are a bad thing, overworking people is too much, not having teams is bad, and things like that.
And what I’ve seen is that all the current methods seem to focus on one thing, instead of looking at how do we improve Scrum or how do we improve Kanban, let’s say, let’s look at what Scrum pulls from, like teams are good, iterations cause a certain discipline on people, you’ve got to be done after two weeks so people who are not done because people who are not don't, they don’t have the discipline or are almost there, you can’t lie in Scrum, it’s not done, you don’t have it tested. Kanban is great in that you are now attending to flow, you’re attending to removing delays, you’re attending to not being overworked, you’ve got explicit policies. So both of these approaches take from axiomatic truths that are out there, but they are packaging it in a particular way and instead of making a hybrid of the two, which admittedly is partly what I’ve been doing for a while, it occurred to me what if we take from Scrum what we’ve learned, not about Scrum, but about the methods it pulls from, about the ideas, about the concepts it pulls from, about why getting quick feedback is good, why having teams is good. Now, what if we go to Kanban and say what have we learned about these axiomatic truths from using Kanban, why is managing queue size good, why is managing flow good, why are explicit policies so good. And then kind of throw away both Scrum and Kanban so to speak, but keep all that knowledge of these axiomatic knowledge and then say, well, what if we created a new method, what if the people who know Scrum and Kanban are really good at it and now understand these axiomatic methods were to come up with, what would we build now if we knew back then what we know now? And that’s what I mean by the Lean-Agile method. I’ve actually started working on this, there is actually a fair amount of details and I am actually going to announce on our website next week, this is not a proprietary thing of Net Objectives by any means, I am actually starting the Lean-Agile project which is getting some other thought leaders working on this and it’s done under the sponsorship of Net Objectives, but it’s really meant to be an open forum, to distill these ideas and since we’ve been doing this a lot ourselves, it’s natural for me to have a little bit of a structure and control to it.
But, anyway, there are two problems with this and this is interesting, this is something I didn’t notice these two problems, I was talking to Curt Hibbs, he’s a really great guy that I have known for years, and I was telling him about this and he said, “this is interesting but it’s not going to work” and I say “why not?”, “well, people want answers, people want to be told what to do”. Now, a lot of consultants think that’s a really bad thing about people. And maybe I do too, but the truth is people want answers, they want to be told what to do, so if we are going to respect people and that’s what they want, how can we give them something that gets them started? People also need to know how to take it to the next level. So the next two pieces of this is how do you then package what we know about Lean-Agile to fit somebody’s context where it more or less fits the context, the way you look at things and how do you go teach them how to go learn the next piece? I give one example so this isn’t so abstract. So, one of the big differences people point to between Scrum and Kanban, which to me isn’t the big difference, but it is a difference, at least in appearance, is whether you have sprints or not, whether you have iterations, whether you have a hard time box. And it looks fundamentally different, but really you could do time boxing in what would be equivalent to Kanban, Scrumban is kind of like that, but in my opinion the value of sprints, I mean the hard sprints- you are done after two weeks, is that you actually add discipline to the team, they can’t say “well, we are almost done”, “almost done doesn’t count, are you actually tested at this point?”, it puts pressure on the team to get the testing and the development done, it forces them to get smaller stories, you can’t have a two-week story because you might not get it in in two weeks, so it pushes it down to two days, three days maybe, one day would be better, so there is a disciplinary side effect that’s powerful and positive when you say you are doing sprints. Well, do you need that? Not really, if you’ve got experienced developers, most experienced developers I know actually know to work in little pieces because there are a lot of technical reasons it’s better. Is there a cost to the sprints? Yes, there is, so there is a cost to this discipline, you have to close it out at the end of the sprint, sometimes there is overhead with that.
The estimation, a lot of people point to the estimation, but estimations are more abuse than a cost, there are ways to do estimation I am not going to get into, if you are interested shoot me an email, to do much more efficiently, with much less time. So, if you look at a team that’s about to start, you don’t necessarily have to say “you have to figure out what to do”, you can just ask them a couple of questions or have them self-ask a couple of questions. Do you need the discipline of sprints? Yes, we do because, or are sprints going to create overhead? If I’m in an up situation, sprints might be useless, I got one-day jobs and I got to bundle them together, so the intention of the sprint besides this discipline is to help us come up for air, so to speak, and see if we are heading in the right direction. By the way, you can do that in Kanban just as well with Cadence, most of everybody I know who does Kanban does Cadence, every two weeks you can run a retrospection, every two weeks you can demonstrate, every two weeks you can take where you are and see if you want to change direction, you don’t need a hard sprint for that. So, I am not talking about doing weekly or every other week check-in. But why sprints, why not sprints? And then, well, does it make sense where I am, so that could get you starting points. But that example is also good for a second piece, Curt told me I was messing that up with, which I love this feedback, I appreciate what Curt said, how do you go to the next level? And this is something that I just realized, I never thought about this before. Scrum and Kanban both tell us how to start by looking at some things but they never tell us what to look at next and they say “oh, that’s ok, it’s just a framework, add to it”, but the problem with human nature, problem with the way humans are, maybe there is no problem at all, we survive because of this, we learn that when the saber-tooth was coming at us we didn’t worry what kind of tree was to our right, we focused on things.
And when methods have us focus on something, even if they don’t say “don’t focus on anything else”, our nature is to not focus on anything else, and even though you can say “they should focus there, we didn’t tell them not to”, the reality is they are not going to. And I say that not out of some theory, although I just mentioned there is a lot of theory that backs this up, I’m actually now seeing the theory to match the experience I’ve seen, people who do Kanban don’t look at teams, people who do Scrum tend to not look at Lean and flow, until they run into a wall a few times and they come to a conference like this and somebody says “hey, look over here”. I’m suggesting those things should be in whatever method there is, so if you have this constrained start so to speak, here is where you go and here is what you attend to, and part and parcel to that has to be “ok, you made these decisions to start with these things and by the way here is the checklist to look at when you overcome those things two months out from now and you will want to look to see if there are other practices”. And I personally think this can be codified, I think there must be 50 people in this place that if we got together, we can take 10 people and get this together, but there are hundreds of people who can get together and lay all this out, it’s known stuff. What’s complex about software development is not the mechanisms, it’s not the laws, it’s how people learn and how people apply them, but people follow patterns and I think we’ve seen these patterns and I think we can do that. So that’s my big thing I’m up to now, one of a few. That’s what’s going to be announced next week, I don’t know when this is published, this may be in the past, but the week after the Agile conference, so look for it on the Net Objectives site.
Because we are tribal in nature. I’m just laughing because I’m thinking of this story I had with a client, they were doing Scrum and they were in a Lean course of mine and they were explaining that the director, the manager of this group, about 25 people and their team lead was there and he said “look, we’ve got about 8 people in the UI group, we’ve got an 8 person mid-tier group, 8 person database group” and he was saying “in what I am learning about Lean, this doesn’t make any sense, I should have cross-functional teams, I shouldn’t have all this extra layering and communication between them “ and I said “actually, Scrum says you should have cross-functional teams, if you are doing Scrum, why did you organize this way?” and he said “well, the teams wanted to be organized this way and they are supposed to be self-organizing” and I said “yes, but it’s self-organizing cross-functional teams, so that means they are cross-functional and then they self-organize, why is that?”, so I said “well, why did they want to do this?” and he said “they said they’d be more effective, like the UI people need to have a consistent UI”.
You ever had different DBAs working on different databases, coming up with different schemas, it’s a real disaster. But I know people and I have kids and for those of you in the audience who either have teenagers or have been a teenager, you’ll know what I am talking about, people don’t tell you what's so, they tell you what sells. And it wasn’t really that they would be better, imagine you had two database people and they have to make an adjustment to the schema, are they not going to talk to each other? You’ve got two UI people and they have to make different changes to similar screens in the same UI, are they not going to talk to each other? Of course they are going to talk to each other. But the reality to UI folks is that to them UI people are the most charming, intelligent people and the database people are the only ones who understand what the problem is here, not those programmers. And of course, the programmers are in between these two bunches of groups, so people don’t really get who is really driving the show, and I'm of course being facetious here. But it’s this tribal nature, we really have to understand the tribal nature of people, we like our tribes, we enjoy our tribes, and we feel comfortable in our tribes, if I am doing Scrum, why would I join a Kanban tribe, Scrum is where all the sharp folks are, Scrum is what tell me what to do and there is just this natural affinity. Now, we don’t do this consciously, it’s why it’s so insidious, it’s not conscious, it’s not bad, it’s just how we are, it’s terrifying or at least a little bit threatening to oppose our identity or question our identity.
If you ask somebody “what do you do as a process?” will say “I do Scrum, I do Kanban”, we’re always thinking about what the most effective method is and we are questioning our approach all the time, because that doesn’t sell. “What do you mean, you don’t know what you’re doing, you’re always questioning it?” It doesn’t sound cool, it actually is cool, but it doesn’t sound cool. So I think that’s why, I think this whole issue, it’s been cool to belong to a tribe and it’s been cool to promote something, we want answers and it’s scary. So I guess what I am proposing is to maybe give a set of answers in a way that is maybe not so frightening, maybe we don’t need the tribe so much, maybe the tribe is that I’m in this tribe of discovery while I’m doing good work, and I can appreciate that’s scary, it’s been for me, I’ve got this veneer of I’m an intelligent person who knows what he is doing and I am cool, except that doesn’t seem to work so well, it keeps getting shattered over and over again, so I’ve learned to just live with that, and have it be disruptive and move forward, but I think we have to acknowledge that’s where people are and I am in the fortunate situation as a consultant, losing a client is a lot easier than losing a job, so I am really having an easier time with it. I’m not saying I’m better and I’ve overcome all this, but I am in a situation where I can adjust to this perhaps. So, I think that’s a lot of it, it gets to be your livelihood sometimes and then it gets to be threatening to look at it otherwise.
5. [...] How do you differentiate those two approaches?
Todd's full question: How do you differentiate, from one perspective that sounds like something everybody should be doing, we don’t necessarily know all the answers and the approaches, we are going to figure that out, at the same time on the flip side, other people in the organizations you might go into and say “hey, that’s already what we do, we let the teams self-organize by department because they are just figuring it out and trying it”. So, how do you differentiate those two approaches?
I haven’t actually had that many people tell me that. Most people tell me “oh, we have some camps doing Scrum, some camps doing Kanban” and they try to decide which one is better and you get this polarity right there and they tell me that. What they often tell me is I’d like to do this, so this is actually what makes me optimistic, and I am not going for uniformity. People always tell me “oh, we should get together and we should all be nice”, we should be nice, and we should all have the same views. I disagree completely, I think diversity is good, I think we should be nice, we should be respectful, but nothing wrong with diversity, nothing wrong with crazy ideas, so the question is I think the community is really ready for this notion of doing just what you said and when people actually do it that will be wonderful. Now, if somebody tells me they are doing it when they don’t think they are doing it, I am ok, I say “well, let’s look at what’s working, what are you looking at, what are the challenges you have” and I can simply ask them “have you looked at this” or “have you looked at that”. See, I don’t claim to be smarter than anybody, I’ve been working for 43 years in this field, doesn’t make me smarter, it means I’ve seen more things and there is some power to that, there is some power to seeing more things, you see some patterns that somebody who hasn’t been around as long hasn’t seen.
And actually the biggest pattern is that the only thing that stays the same is change and the way people embrace it, the way people resist it, the way people hold on to their own method, so I think what we want to do is suggest to people some things they maybe haven’t seen and if they are doing that I don’t need to challenge them, if I think now they are not doing it why would I bother telling them, all that’s going to do is get them defensive. Maybe I’ll just throw in something “have you considered this” and then if they haven’t considered it and now they don’t, there is nothing I can do about that, but if they are truly doing that then it’s a good thing, I’m happy when people are moving forward. I can tell you for a fact as a consultant, the best clients are those that are so far ahead of everybody else, those are the dream customers, the dream customers are the ones who are doing better than you, and all you can bring them is some things to try or ask them questions. The ones that need you, I'm happy to work with anybody, those are sometimes not the best clients, you don’t want anybody needing you, you want to work with people that are learning and moving forward, so when somebody says they are I sure hope so, that’s great.
That’s a great question. It’s actually a key piece of this. So we want to understand first what the starting point is, so I would suggest that there are about half a dozen things that everybody should do, I mean everybody, there might be some exceptions, but I haven’t run into them yet. So, working with smaller things is typically better, shortening feedback loops is better, having teams is better. Now, if you can’t get a full cross-functional team, and in larger organization you usually can't, there are ways to get the equivalent of it, we don’t have time for that, but again, look at our website, shoot me an email, we’ve got all sorts of ways of doing this. So, you take these half-dozen practices and you say this is a starting point. Now you have some of these what are the differences between Scrum and Kanban, as an illustration, actually one of them is explicit policies that’s in Kanban, that’s one of the things everybody should do, I don’t care who you are, what you are doing.
Then you look and there are a few question marks, a few variations because it’s context dependent, culturally dependent, how does work load map to the capacity of the teams capabilities, so you ask a few questions and you get one of half a dozen starting points and now you move forward, but actually the starting point you pick, you can say do I really know what people are going to run into, and you can say isn’t that predicting, isn’t that violating complexity and I would say no. Complexity says you can’t predict, but complexity doesn’t say there aren’t patterns to complexity. So we’re here in Nashville and it’s raining every now and then and it’s kind of been in the 60’s, 70’s, 80’s and I predict with full certainty that in December over a week it will be cooler than now. Now, I don’t have detail here, but that’s a pattern, it’s cooler in the winter in Nashville than in the summer in Nashville, it’s going to rain more in Seattle in the winter than it will in the summer. So, when people start this way, several different things might happen but not that many different things. So, you would write down what those different things are, you could say when you get to this challenge, or when you would overcome this limitation that you put this practice in, now you should look at things.
I don’t mean this to be a totally prescriptive educational method because that really won’t work; what you really do is start inducing people to think for themselves, start to come from their own experience and I actually think that can be done, I think a coach can actually accelerate their ability with this, but I think that is partly what you need, where do I start and then what do I look for to get to the next level, following the Dreyfus model of I am starting as a beginner I want to be told what to do, but I am also understanding why I am doing what I am doing, I am trying to learn more and then you'll tell me when to get to the next level. Oh, now I am worried about this aspect I didn’t worry about it before but now I can see not sure about how to handle this, that’s a trigger to go to the next level and I think that can be documented. In other words it might be a big map, if I want to know how to get anywhere in the United States from Nashville in a detailed way, huge map. I might have a huge database, but if I want to go from where I am to where I want to go, it’s like the old AAA, you’re too young to remember, but in the old days when my dad used to take me on trips in summer you’d buy from AAA maps and there'd all be yellow outlines where to stop and where the restaurants were and where the motels were, now you have Google maps to do it for you.
But it’s like that, this huge database, but I only knew this thin line to go from here to there and I am going to make something that is provocative to some, but it’s been confirmed by a lot of others, we’re all in different places and our path of getting there is all different, but where we want to end up is not that different. Things like using minimal business increments to start, continuous integration, some coordination across teams, managing flow, managing queues, managing structure, everybody needs to do that to be effective. So, the thing to recognize is the ending point is not that dissimilar for all companies, the starting points are different, the path you take, the ability to change, culture, all those are different, so it actually is not quite that complex a problem, it’s not like I want to go from anywhere to anywhere, it’s more like I have to go from anywhere to about this location. And that’s maybe time for another talk about that, but I actually think it’s somewhat true it’s just as a side note why I am also interested in the Scaled Agile Framework is because it designates a lot of the ending points and a lot of ways of getting there, because we are seeing that ourselves in our own work with our method of going and doing large scale, there is a parallel there and I think that’s driving this, there are some things you have to accomplish. The question should be how do I get there and how do I help people think so they can get there, they have to understand it but they don’t necessarily need to do it all on their own.
That’s a great question.
Todd: For example, one thing you may commonly see teams that start off with Agile they do it on their own, they read a book, they start with two-weeks sprints and then they’re “oh, we can’t do two-weeks sprints, so we are Agile and we adjusted to four-weeks sprints”, but they don’t really necessarily understand why that is not such a good behavior that you are looking to do.
You just answered right there at the end, because they don’t understand implies that to solve this you need to do thin layers, what’s a little bit of understanding your theory and what’s a little bit of practice tied to it, the practices should always be tied to some rule, some understanding. Not all of this is how I like to do it, I do it because if I don’t do it this behavior, this axiomatic truth of software development I’m going to be running counter to. It’s kind of like hearing people say some framework that issue is orthogonal to our method, I say it may be orthogonal to the method but it’s not orthogonal to what you are trying to do, if you don’t attend to it it’s going to be problematic.
So what you want to do is every practice at some point needs to be tied to the reason of the practice and the principles under the practice, so you might start with just the practices. Say “do this for two weeks then start looking at are you working for or against this principle”, so you can start with practices but then give them something else to read and look at. It’s very interesting when you mentioned this, it’s funny that both Scrum and Kanban give you starting things, but they don’t tell you after you’ve started what’s the next thing you should look at and you need to do that. But you can phase that in, say, start with two or three weeks, try it for a month, try it until this happens, until you notice this phenomenon, do sprints until you start noticing they are working against you, then, now let’s look at some other issues, that would be an example, or look at the team structure until you’ve taken it as far as you can, now here are some other ideas. There is no reason you can’t layer this, take a good cook book for example, they don’t start with the most complicated thing in the world, well, one that’s trying to teach you, a cook book that teaches you how to cook, will start with some simple recipes and then it will build on their knowledge.
And they don’t say read through the whole book so you know all the things, they say try these simple recipes and then read the next few recipes, it should be like that. Now, following the recipes will never get you to be a master chef, but if the recipes are laid out in the right way and if they talk about why were adding this recipe and what the distinction is and what is different, you can become a master chef, actually I am a pretty good cook and that’s how I learned, recipe, recipe, recipe, recipe, then I began starting to wonder why is this better than that, what’s good about it, why this spice instead of that, why basil instead of sugar, they are both kind of sweets, well, one is a spice one is a sugar, but they both add sweetness, but in a different way, well, why? And when you start asking that, we've got to get out two year old back, why this, why that, why this, why that? Doled out over time you can learn, I believe you can, if you want to learn and you’re given the practices and why, what’s the objective and what’s in the way, you can learn. So I think this needs to be laid out, this is a fairly significant endeavor, and that’s why I am not trying to ride it myself, I wish I could, but I couldn’t for any reason because one person’s perspective is never complete enough.
So, again this is why we are doing the Lean-Agile project, getting a lot of smart people here and what I want to do is create a framework so we can start it and then let it grow based on the experience and knowledge people have and I think there are so many people out there, I think the industry has hit a tipping point where there are more people who would rather focus on driving this body of knowledge and knowing what to do, than they are about how do we improve Scrum, how do we improve Kanban. There was a tweet this morning about Lisa Crispin, I’m not sure I am going to get this exactly right, but it said “oh, I so wish we’d get rid of all the labels and just worry about what works”, yes, that’s why I am giving it a generic label that says Lean-Agile, how generic can you get that, Lean-Agile project, well, that’s horrible branding, good because it’s not meant to be branding, it’s meant to be an inclusive thing.
8. How would somebody get involved with that?
Shoot me an email. When I announce it I will say how to get involved, it’s an open thing, the information is totally open and available, we’re going to put it under a Creative Commons with acknowledgements and there are contributors, there are certain requirements for the contributors, there is no financial model, I don’t ever see that happening. I am not totally altruistic, I’ll be the first one to say that, I am driving this for value in the industry, but it obviously raises some exposure for Net Objectives, we’ve been doing stuff like this, I am happy for the contributors to get this, I think we’ll start adding blogs and webinars and things like that. To me, as we raise awareness on the power of what we can do in the industry, it's kind of the rising tide raises all boats. My opinion, Arlo Belshee, the guy blows me away, he was telling me some stuff he is doing, I was like this guy is so inspiring, I am so amazed and I love that he has the courage to say something that I usually don’t quite say, but I am going to say it. We are operating at about 2 or 3% of our capacity, most teams just work on stuff that are just creating messes that take away 60- 70% of their capacity and then we work on the wrong things, we work in the wrong ways. My belief is that if we could transform the software side and the business part that feeds it, we can raise productivity on this planet many times, the software industry by several times and that will have a positive impact if you think about all the things that software impacts. And if we can raise the productivity of the planet by 10 or 15%, now we’re not talking huge percentages, but 10 or 15% would be amazing the wealth of the country, the wealth of the world and I think that’s what we need to do.
So I am going to tell you a personal story because this is what actually drives me and I know people are driven by this, well, two stories because I have to give the framework. David Bernstein, an associate of ours, he used to work with us, and I made a comment to him, I said “David, I wish there were more crazy idealists like you and me that feel we could change the world”, and he said “well, you know there are”, and he mentioned a few people in my own company, and I said, yes I know but I am talking about out there and he started listing them all off, that’s cool, there are a lot of them here, because my idealism is this, I remember years ago that huge plastic mass in the Pacific the size of Texas and if you don’t know about this you should wikipedia it, google it, “huge mass of plastic floating in the Pacific the size of Texas” will probably get you something, and at the time years ago Bush made some comment we can’t do it because it’s too economically unfeasible, and I am thinking to myself economics is relative, to a kid $5 can be a lot of money, to me $5 isn’t a lot of money, it’s a lot of money what it would take to clean this up, billions of dollars, it is a lot of money, but what if we were that much wealthier, where five billion wasn’t a lot of money. Do you know what I mean? It’s possible if we were more productive and we focused on productivity we could do this. If we got the software industry working in a more effective way, we had a lot more productivity, I don’t mean 10% or 15%, I mean like 10x more productive that we could deliver, make software that much better doing more things, then it wouldn’t be that expensive to have a few billion dollars to clean up the environment, that’s the kind of thing I am interested in. And I am interested in a lot of people, I know a lot of people feel like this, I think that’s what keeps some of us nuts going. So I am looking for you people, come send me an email, let me know, I am interested, all the while while were building our business and working with people.
Todd: Thank you very much for doing this.
Thank you, Todd, this was a lot of fun for me.