Alan is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas. He is the founder and CEO of Net Objectives and also can be found on twitter @alshalloway.
Downloaded PDF of Transcription
Related Podcasts
Part 1 of 3: Alan Shalloway discusses the state of Agile!,
Part 2 of 3: Can Agile work at the Enterprise Level with Alan Shalloway?
Part 3 of 3: Shalloway on Teamwork in Kanban
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Transcription of the Podcast
Joe Dager: Welcome, everyone. This is Joe Dager, the host of The Business901 podcast. With me today is Alan Shalloway, who’s the Founder and CEO of Net Objectives. With over 40 years of experience, Alan is the industry of thought leader in Lean, Kanban, Product Portfolio Management, Scrum, and Agile Design. Alan is the primary author of “Design Patterns Explained.” Is that a new book?
Alan Shaloway: Well, actually “Design Patterns Explained” came out, first edition I think was 2001 then updated in 2004. But we borrowed some of the concepts for our latest book called “Essential Skills for the Agile Developer.” This book actually comes out of a lot of the work we do is, of course, teaching patterns and also the teaching Agile. It’s kind of funny when sometimes people, even in Agile… Some developers look like deer in the headlights. Like, “Oh, my goodness, what am I going to do now if I’m not planning ahead?” They worry about all sorts of things about maybe lack of design or at least not designing as much as they would.
What we found from our patterns and emergent design manufacturing and TDD courses is that there are a few techniques and understandings that if you take advantage of… That is not hard to do at all with making much more adept in the Agile space. In fact, in the pattern scores, which are not specifically here for an Agile, well, we talked a lot about how you use that into Agile.
There are three things in there that are very easy for people to take out in the real world. They differ in particular or are like encapsulating construction, just general asking how you test something before you use, but how would you test something before you build it, that gives you a lot of insights. And the third one is programming by invention, and these are very simple techniques.
We thought about it; we said, are there others? Are there things that you could do that a developer like maybe in a half an hour can learn one trick to make them better? We came up with a few little, over 14 or so, something like that and that’s what this book is about.
Each one is a simple 30?minute or so read to understand how to do it, something they probably do now but don’t quite totally understand the power of it or could take it a little further and the book was really designed as a quick lesson learned over… You can read one and try to practice and read another one and try it and practice so each one’s modular.
I think it can help people new to Agile in their design quite nicely, and it’s good even for experienced people as well. It’s not really a newbie’s book but if you’re wondering how do I do that now that I’m doing, how do I deal with my technical aspect now that I’m doing Agile. It’s really a good answer for them, and I’m hoping it’s well?received. It just literally came out the last week. But our reviewers thought it was very good. I personally think it’s a great book.
I know the techniques that are in there will make a big difference for people, so I’m really hoping people read it.
Joe: It doesn’t look like your typical airplane book. This is a pretty in-depth book, isn’t it?
Alan: It’s funny, even though a lot of these topics didn’t relate to each other, you can take one issue, like the example of how do I actually think about testability in programming… It turns out there’s a relationship between testability and by testability… I mean, how easy it is to actually test your code? It’s in there; there’s a relationship between testability and the quality of the code. In other words, code that’s poor quality is typically hard to test. Code that’s of high quality is typically easier to test. In fact, I remember telling myself… I’m sometimes a very slow learner. I remember telling myself many times, how I was going to test this when I designed it. After I wrote it and all that and now I’m testing it. Years ago, I would often come to this point. “Man, this code is tough to test.” I wish I thought about how I was going to test it when I was writing it, and a quick learner might have said that once or twice, it might put me 20, 30 times.
I said, “Oh, maybe I ought to start thinking about how I’m going to test this before I write the code.” When that really hit me, and I started saying, “Wow when I just consider how I’m going to test it, it changes my code.” Now that little conversation alone makes a big difference. So we talked a little bit about that, like one of the chapters on defining a test. I’m not talking even TBB here. I’m not talking about a Simslice and then writing it in the Simslice and then writing it. I’m talking about just asking the question, “How will I know I’ve done that?”
Now it’s interesting because people have done this at times. A pattern I’ve seen is that sometimes people do something really, really well, really, really smart, really, really great, and then they don’t do it again for a while. It’s because it worked at that time, but they don’t step back and reflect on it and see how it could work in other places.
So what this book is about, even though it kind of does go into these topics in?depth a little bit, it’s not really this big tone or anything. It really takes advantage of what people have done successfully on their own, and it puts it in the context where they can see why it works. It sharpens the saw so they can either; it lets them know what we use. Here’s a tool that you use, where you use it, and it is a lot easier that way.
It’s giving you something that you can actually read. I wouldn’t read the whole book in one sitting but you can read like a chapter in 30 minutes and then go say, “Hey, that’s a technique I can use and let’s go try it out, and then you try it out and you’ll see you’ll do better.” We intentionally kept it so every chapter you could pick up and go do it and be successful at it right from the beginning.
I think you’ll see that those small investments it takes to do the suggestions we’re making, actually it doesn’t take weeks or days even. It’s like you start getting feedback right away to add some power.
I think that’s where it’s really useful, is one thing that people tend to do when they’re in a time crunch and like who isn’t today, that you fall back to your old habits. Our feeling was, instead of giving you this whole book on one thing, if we gave you a little bit on something you can immediately apply and then that started getting you better quality and saving you some time and effort, then you can kind of bootstrap yourself into a more in?depth, better way of doing development.
This is like you pay a little, you get a little, you pay a little, you get a little bit of that and you can actually, I think make a huge difference in the quality of coding and not just like if it’s Greenfield, not like if it was just maintenance, just a different thought process that people are doing to some extent but not necessarily being reflective about it.
I want to be really clear when I say this, and I mean not everybody else does this. I, of course, know, I get something and I use it all the time. I wish that were true. I got some really embarrassing stories, but I’m not going to tell you here because I know we don’t have enough time.
But, I mean, I’m talking some major embarrassment about things I did once and it was really good, I’m proud of doing it once, but I’m embarrassed by… You did that growing thing 10 years ago, and you didn’t do it since? Why not? And literally, things like that, really cool stuff. It’s because if we don’t understand why something works and don’t have clarity about the context work, then really, good people do great stuff all the time, but sometimes they don’t repeat it.
So this is a collection of things that we’ve done that are relatively straightforward, the intent was, it’s got to be something somebody already almost knows how to do or is doing, something they can learn in 30 minutes to an hour tops and gets an immediate return. I think when people read the book they’ll say, “Oh, yeah, I knew that. Oh, yeah, I knew that,” and the whole idea is to gel it so they can actually then start doing it all the time, not just every now and then.
Joe: Well, it sounds like, then, each chapter is a PDCA cycle, and at the end of it you standardize your work.
Alan: Yeah, I think that’s exactly what it is, and it was designed this way. The book “Design Patterns Explained” was about creating a whole new thought process. So there, you needed to lay the groundwork; you needed to do some problems; you needed to try something. That is like a book; you take a few days to read and a few days to try and then the whole thing. But there are lots of really simple things that I like to call trim tabs. A trim tab is a device on a plane or a ship that with a little leverage makes a big difference. To me, a trim tab in development is something where you do some little piece of effort, and it makes a big difference.
People do this all the time, like one trim tab that people learned years and years ago is you don’t use constants, like these magic numbers. Like 10 is the maximum number, so we put 10 all over the place. Well, now people know that’s really dead. But if you do, like take the 30 seconds to make the cons of 10, then you don’t have a big problem of when your size changes. So that’s an example of some little things.
The things we’re talking about are obviously much bigger than that but they’re still trim tabs, because there’s something that with just a few minutes of thought, you can save yourself hours of trying and you have a lot of great clarity.
That’s kind of what this book… It was the highlight of this book, was like using that parental, what little thing we could teach, that people could actually get some serious value out of them. That’s really how we pick these chapters. These are the key points that are serious trim tabs in software development that people know, but I don’t think they… People know, but not everybody knows.
Everybody should know, it’s not hard to do. I think it will be a value even for people who are experts in doing it already. I think the value would be they could teach it better to others. I think even the experts aren’t doing all these things even though they’ve probably done it once or twice or something.
Joe: Everybody says you’re Agile anymore. Is that really true?
Alan: Well, I was just talking to somebody who says their team says they’re Agile because they could program, but they don’t do anything else Agile. Agile has been so miss?marketed. If you’re doing a daily standup, I heard you’re doing Scrum. That’s not Scrum. Agility is really… It’s so fragmented designs; I mean they’re different mindsets now. When you’re comparing Waterfall versus Agile, it was like, OK, well we’re not going to do the big phase day thing, we’re going to do all of our analysis in our design, we’re going to do it in little chunks and do them all in a swarm. Even there, there were different styles but mostly, Scrum was like real popular in XP for a little while. I think the problem is people really even though they know there’s no silver bullet, people kind of wanted to tell people what to do. I think one of the reasons Scrum got so popular is because you say, here’s a set of prescribed practices and if you follow you will get started then you’ll learn how to them then you’ll improve them and you make it your own.
But at the start when you’re really nervous, at the start when you really discover because you don’t know whether it’s going to work, you’re following some expert’s way of starting and it gives you a certain level of comfort. I think that’s why we’ve seen… But it also is a problem that if anybody does this, they’re going to plateau because at some point those prescribed practices aren’t going to be the best things for you.
Then you are seeing this as a Kanban community as well. I see Kanban is starting to become somewhat prescriptive to some people. Well, we always do this, so you do that and that kind of… Some dogma is coming in there.
So what Agile means in my mind is neither of that. Agile is really not about following any sort of prescription, but in your mind saying what I want to do is, I think there are really three things that you’re trying to do in Agile. One is a driver; you’re delivering value to the consumer quickly for the business. So it’s business and relations.
How do I get value out to the customer that the business is picked on? That requires the team, self-organizing, to figure out how to get that done. If you don’t have a team and sometimes it’s difficult, if you get a lot of special, it’s just something and it’s up to management to improve the structure within which the people can work.
So it’s kind of these three levels of business driving, management clearing the pact, you could say, and the developers are actually creating the value of the development team. It’s not just coders or testers, but it includes the analysts, it includes operations, includes support people, includes sales people, includes anybody who’s touching the software, how do they get that out there so it can be consumed. I think that a holistic view is listening from a good happy Agile community right now.
While I’m doing Agile, yeah the development team is doing Agile. Well, the development team is doing Agile, and nobody else and your company isn’t and there are a lot of problems with that and you see that a lot.
Joe: Now you always talk about Lean, Agile, how does Lean and Agile play? Is one the umbrella over the other or are they equal partners in your mind?
Alan: Well, OK. You caught me, Joe. I think part of this is marketing. I actually think Lean is the big mantra. I think Lean is about respecting people, having a systems approach, working at how it became a business, improve the structure, folks for delivery and improving the team organization. So I would say yeah, Lean is actually the umbrella for it all and we put Lean-Agile into it, because Agile has some other things that I think are actually implied in Lean but aren’t necessarily as explicit in Lean as they are in Agile, which is this cross-functional team notion. Steve Denning talks about, in his Radical Management book with how will you endorse, about cross-functional teams being able to create or delight customers.
Steve Denning management is about creating teams that can delight customers. So Radical Management is really saying it’s radical because you’re saying, well, we’re going to have teams self-organized. We’re going to direct them from a management point of view. But to manage by directing, I mean we’re going to play in the right direction but then how they get there is up to them.
I think this is the thing that’s often missing in the Agile community. You can create, I mean there’s no question, Scrum is a great process, it really is and the timing works out for us. Scrum is a great framework for creating a cross-functional team, or excuse me if you have a cross-functional team; Scrum is a great framework for getting that team to work together well.
I’ve actually never denied that. I’ve always said it. That objective probably has trained us much or more than anybody, but maybe one or two other companies out there and we’re still very active in the Scum training world. But what we suggest is Scrum is fabulous if you have a cross-functional team to use it to self-organizing and to deliver value to the customer. But what’s missing is how you really manage multiple teams across each other, what that means is how do you do product portfolio management, how do you decide really where the value is across all the teams.
The way Scrum is set up is if you have a value of the effort to return where a person getting lots of value in the first few releases and then it stars failing up. If all you’re doing, the worst thing to the customer, that customer is going to keep saying, “Give me more, give me more, give me more,” because to him, that tailing value, even though you’re not getting as much a return every time is very valuable. it’s valuable like him. To another customer, there might be something of much greater value that can actually be detected by business drivers.
You need the business driver to know where to point the guns, so to speak, and then you need the team, the self-organizing, cross-functional teams to do the job well, and that’s where radical management play.
You have these different pieces of, how do I create great teams to delight customers, how do I create a business to make sure the teams are working on the right thing, how do I get management so the teams can coordinate and work together well. In my mind, so I’m just good at one of those and not good at the others, and my company is really about transforming. We’re all working all sized organizations; we work for companies really small, on up to the thousands, but we know how to actually work with companies in the hundreds of thousands. That ends up being where we spend a lot of our time.
That’s where you need something bigger than just the Agile team?based approach, and that’s why again we call Lean-Agile to kind of present the idea of this overreaching bigger view.
I’ve heard some people say, “Agile is what you do in teams, and Lean is what you do at the enterprise,” and that’s wrong. You’re talking about a whole systemic approach, and when you work with systems, you cannot decompose them.
In other words, even though I’m talking about business and management and team, you don’t really have different parts of systems. If you decompose the system, it’s a teaser, those teasers are not the system, it’s like when they are put together. They’d be like say taking an airplane, let’s take a 747, break it down into pieces and then see how each of the individual pieces fly. Well, none of them fly on their own, but you put them together, and it works.
You can’t just say, “Well, this does this, and this piece does that and that piece does that.”
It’s the way they interact with each other is what makes it work.
Joe: I have to ask you because you’re a big proponent of Kanban and the last couple years you have been getting into it deeper. I never see a lot written or said about teams within Kanban. But you just said that that’s an important part of it?
Alan: Well, this is actually some place where Steve Denning has been very impactful on me because see, the thing is Kanban is very much geared toward managing your working progress and managing their flow. This is what I think where I’m saying that sometimes we get into follow particular practices and not thinking so much. So Kanban is phenomenal about improving flow, improving inter-team dependencies or things like that. I think we take our eye off the ball, and by that when I say “we,” I mean the Kanban community actually I think is missing a little bit here that they’re taking their eye off the ball, what you’re really trying to do is create great teams to deliver value to the customer and I think Kanban is wonderful for that.
I’d say most organizations that I’ve seen and I’ve seen is a very key point here because again, if you’ve got an organization that’s got very functional mid-management, very functional high-level management, has great working teams and they all know how to work together, it’s going to be great. But that’s not the kind of organization I want across, maybe because we do more than Scrum, so they come to us, so I’m not sure we have a scientific view.
When I go to the Agile conferences, like Agile Alliance conferences, I see a pretty decent cross-section of people there and almost all of them are having problems doing something across the enterprise. So the fact that Kanban can work when you don’t have cross-functional teams, it can actually help you function well and manage a working progress when you have dysfunctionality at management and business levels because of the visibility traits.
Because Kanban works there, you see a lot of people starting out with Kanban. But the fact is that it will work when you don’t have cross-functional teams or do not want to create cross-functional teams. I think most people will do Kanban are still using the teams, but they end up not talking about it, then I actually think it’s worth talking about because I think if you can create… If you have a bunch of specialists and they can’t work together or for whatever reason, the product portfolio managers are putting too many things on you and you can’t create cross-functional teams, Kanban is a great way to transition from where you are to where you have cross-functional teams and then you still use Kanban.
You still manage your working progress, you manage your flow, and you create visibility. It’s no less Kanban just because you could alternatively maybe use another process there. But I think we have sometimes lost sight of the fact that we want to use Kanban not just in managing your work but in helping people get team structures that are better. I think that’s really where kind of the future is going to be, is how do I, not just support people and to respect people but how do I really create the right team structure for them.
We’ve actually been doing this. It’s funny I started out saying embarrassing things about not doing things explicitly. We talked for years. In fact, my most popular talks recently have been how do you actually get a structure so that different teams can work together better? I think a lot of it is I’m just consciously taking it to the next level. It’s not just how can teams interact, but how the teams themselves form and work together internally as well as externally, how can Kanban do both of those?
Kanban is just fabulous. I’m a big proponent. I think it’s a very powerful method of transforming not just a team but a group and even an organization. But the fact that it will work anywhere because it’s a visibility in some of the change management systems doesn’t mean you shouldn’t be improving where you are just because you can make… You can make improvements where you are with the same structure, but you can make even bigger improvements if you use it to change the structure.
Joe: So you really believe that you can scale Kanban?
Alan: Oh, yes. This is actually a revelation I have. I was on the phone… I don’t know, I think it was one of these Twitter exchanges which are funny because Twitter, things are short; sometimes you really don’t get the whole point across. So we’ve been going back and forth. I can’t remember who I was tweeting with. It was interesting after about five or six tweets, I realized, we’re talking about two different things. He’s scaling up to 100. I don’t even consider scaling at a hundred. I mean, we started people, we started organizations of about 100 or 125 is about the most that you start with. That’s not scaling, that’s a beginning point sometimes.
Sometimes you need to actually make that all at once and really not so much Kanban but Kanban can as well. They have been trying with Lean, we just got in, and we just kicked off the team at no time at all because we gave them a consistent view.
So when we’re talking about scaling, first of all, what do you mean is going from what size to what size? But the other point is, we don’t typically think of scaling in the way most people think of scaling. Most people think of scaling as, we’ll start out with a pilot, and then we’ll expand it and we’ll bring it and branch it out through the whole organization. If you’re actually doing just what I said, I think it is dangerous. Now I’m not saying you don’t have to do a pilot; we do pilots lots of times. Sometimes we do start with a hundred; more often we start with just a few teams.
You might say who needs to build this business value? If that is eight people, great, it might be 25, and then we’d start at that level. We start typically as a pilot, the smallest group that we can get away with that can actually have business value, and that’s very often a lot more than eight.
Even when we do that, the first thing we looked at is the whole problem at scale. So what’s the organization’s challenge? Is it lack of business thriving? Is it management? Is it team technical knowledge? Is it team profit? Are they overworked somewhere?
So Kanban is a very good way to see the flow and the bottlenecks, impediments, whatever you want to call them, to getting stuff done. And then, out of that big picture, you can now go and look and say, “We got 300 people here and we don’t want to start with 300 but we can see there’s a big picture. If we can somehow get these guys over here, these two teams of 10 each, if we can get them up… First of all, we can see that they can live within the organization as it is and second of all, we can see that doing so will prove our point and will move us further toward getting another few teams.”
So scaling from the bottom up without a vision is not what we do. It’s not dangerous. But scaling from the bottom up after you’ve created a high-level context is very important. Again, why you might call it Lean-Agile; Lean to give you the overall view but then you might implement an Agile implementation at a few things but within the context of the bigger picture.
These companies that… They’ll say, “Oh, let’s be Agile and let’s do a pilot project” and they just pick one, we’re seeing this repeated pattern. This is another, sometimes on flow point of view. If you ever go, we noticed how we saw this pattern about those companies would take a pilot, they’d have great success. What happened through some part of the organization, they tend to get boundaries as they got past like the mid-management started or something.
Then it would just kind of crash. Crash is the wrong word, but it will just stall, and it would plateau. Then sometimes the company would almost what I’d call “reject” it. It’s like all the other parts of the organization now kind of talks about how bad it is and literally pushes it out. With teams that were used, never quite understood it, we just attributed it to jealousy or people didn’t like it. They were being threatened. And the more we mentioned this, people were talking, “Yeah, we got Agile in. We’re great, and nobody else liked it. It’s outside of our group, and they basically had a change in manager and they had to stop it.”
Eventually, what we noticed was that there was something going on where sometimes the Agile teams, the teams, the pilots that went Agile were doing great. They were doing better, but they were only a piece of the picture, and that the way they were doing great was literally harming the other parts of the organizations, and they weren’t at all sensitive to it.
So all of a sudden, it got really clear. No wonder these people don’t like it. From their perspective, it’s not gotten better at all. From the Agile team’s perspective, it’s gotten better. But if you’re not looking at the business delivered, the business value delivered, without looking at the business value delivered, and then you’re really missing the whole thing.
So this is the Lean’s optimized the whole and Agile might say, well we say the same thing but I like what George Bernard Shaw said one time ago, I hope I don’t bastardize this too much. He said, “You can ascertain what people believe not by their creed but rather by the assumptions they regularly make.”
Mr. Shaw is a very brilliant guy. He was a very brilliant guy. And what he’s saying is, if we look out in the world, we can see what people believe, not by what they say they believe but what are the assumptions they make. And the assumptions you see in the Agile community is, I can start a team, and they better file a project, and if it works, it’s great.
The worst thing is actually, no, that’s not the problem of the entire business flow, the entire value stream and it’s not good at all. The focus on the team, the assumption that we can work on the team, I think is showing the belief system that the team is the bottleneck and the team is the real important teeth and the team is what’s important. And you see this over-focus on the team, which is something I’ve been ranting about three years.
Yeah, the team is important but the team, first of all, is usually not the problem. I mean, usually that’s just where the problem shows up. If you have a gasoline fire, you couldn’t help, it’s all that gasoline. Maybe the problem is where is that gas coming from? Where do the developer problems come from? Very often, they do things that aren’t very good but it’s not their fault. It’s their being overburdened because there’s an unclear business direction or they don’t have the support they need.
So just focusing on the team here, not only puts I think the developers in the wrong situation, it makes it so that even when they solve something, you haven’t really solved the organization’s true challenge. So what happens is, you’re solving not the true challenge but a secondary challenge and after a while you’re going to plateau because you could only get so far until you get to the real problem that’s causing these other challenges. We see that overlooked way too often.
In fact, in my case when they talk about it, and that some people have described this because I have sparkly personality but when I describe it, people seem to think, “Oh, don’t talk about that. We’re getting the teams out. We got to focus on the team.” And I’m saying, “No, it’s that whole focus that’s the problem. Now you do a great job.”
You can do a great job of treating an engine but if the transition is your problem, I don’t care how good you get that engine. We will see some improvement but you won’t get the real problem, and I think that’s what we do. I think in the Agile stage, we end up spending a lot of time making engines run better when the transition is the problem.
Joe: Is that somewhat what Scrum tried to solve with the ScrumMaster and the project coordinator, is to make that team more functional and meld it into the rest of the organization or not?
Alan: Sort of, it does try to do this, but I don’t think it’s improbable not to do it. So the ScrumMaster is all of helping the teams self-organize and get their job done and then taking the challenges the team has, the impediments and saying, “OK, let’s go take these impediments to the organization and let’s fix them.” Yeah, that’s the intent. The problem is; I don’t think that works. I don’t think it works very well anyway. If you have dysfunctional management, talking to them about having to remove the impediments of the team is not going to get them excited. What you need to do is come from again a holistic view of how you’re adding value. So the intent is one thing but the fact again, I’ve seen a lot of companies that have impediments. Scrum has shown me impediments, but they don’t want to recognize them as impediments and two, even if they did, they don’t tell them what to do with the impediments.
So there’s notion that you can see some things and then stop quickly in Scrum which is a great concept, I mean it happened. Sometimes it’s actually is not true and that you sometimes forget just the way it is and then other times, oh yeah, I don’t know how to solve this, this are our impediments, but if it doesn’t give you any guidance. Now, of course, Scrum is a framework, so that’s as close as you’re going to get. So it’s supposed to be a framework where you put things in.
I guess what I’m suggesting is a framework while it’s important is not more important than the things you put in, the notions of how do you treat people, how do people change and how does work change if you don’t attend to delays? The content, the knowledge you have to use, that scale and large systems is very significant and taking an attitude that, well we’ll have this framework and we’ll get it started and we’ll find our impediments I just think sets us up to where you have a lot of heroism needed. People have to solve these impediments that show up. Now what you need is a combination of both the framework and what you put in.
To be honest, I think the framework is… Inner development is fine in many cases, but it’s not the best way to go in all cases. So I don’t want any dogma that says, “This is an approach you always take.” And time boxing, although it’s a great concept, it’s brilliant. In some ways, it’s a weak manifestation of flow but the reasons where time boxing is sometimes better than a pure flow model but you want to know both.
I think my complaint isn’t with Scrum, my complaint is if you try to now say this is something that will work everywhere, and you should always start with a framework and build it out. I think that’s the problem, and that’s where I think things go wrong because people try and tend to oversimplify.
I guess one last thing on this is, ScrumMaster’s role is kind of interesting. Because what the ScrumMaster is actually doing, I guess it depends on… There are different thoughts; there are different camps about the ScrumMaster too. So some people say that ScrumMaster is a peer facilitator and doesn’t lead or direct or anything like that. Actually, I disagree with that.
The other camp, I believe ScrumMasters are coaches. They’re doing servant leaderships, things that need to happen. And Servant Leadership, by the way, means you get coffee as often as you kick them in the butt. In other words, you get things for them, you make things work for them, and if you’re not doing what you need to do, you don’t want them to get away with it. That’s what real leadership is, servant leadership. Servant leadership means I’m leading, but I’m doing it by providing for the team.
Now, in my mind, that’s what a manager should be doing. The truth is, nobody knew I think in Agile, how to do that. I think the managers actually lead. Lean has an awful lot in this area of how do you get managers to lead. But Lean didn’t come along, the software scene anyway until after the Agile community came in. So I think what happened is the ScrumMaster, we meet up this whole new role that’s really an old role you and older roles as well too. I can’t get a manager to lead, but maybe I can get a team member to lead.
So we’ll just separate the team from the rest of the organization, have the ScrumMaster leaders and he’ll deal with getting impediments removed and he will be talking to the rest, then the product that comes along saying, we’re going to remove them also from the business chain and the team will just talk to the product owner.
Now, I’m not saying this is how it should happen actually; again you got some different fractions in the Scrum community. Some people actually have the team being separated with these two roles and some people say, “No, no, no. These roles are supposed to integrate with it,” and I agree, I think they should be integrated. But then the question is, what’s even strong now? That becomes pretty open?ended.
So there’s no overreaching mindset that people can use to solve these questions as they show up, because as they take the initial practices that you’re given, you get into this kind of non-thinking role that works at first but it doesn’t extend beyond the team and people can do it because actually it’s less threatening to them because it feels comfortable. We get very nervous when who we are and what we do is being challenged and Scrum gives you a way to… Say, “Why do we start this because that’s what we’re good at?”
In a sense, you’re making a big jump like you were told to do it, and that was a good thing. You go doing it. With Kanban, you have to kind of think all the time, that’s the whole idea. The Kanban works up there. You’re going to have iterations if you like time boxing. There’s nothing saying Kanbans can’t work with iterations. Kanban is basically Kanban put on top of the Scrum. What it does is it enables you to think and kind of puts pressure on you to think all the time. I’m seeing now some people are pushing back there in the Kanban community.
They never say we don’t want to think, but the reality is you start things from dogma coming. You start things… Oh, this is what we do in the Kanban world, and that’s a trigger right there. Well, that means they’re not thinking if they’re saying this is what we do.
Joe: I hear that Scrum has a pretty defined structure for team and teamwork in how it’s supposed to work and there are couple different variations of it. But is there such a structure for Kanban or is it just completely self-organizing?
Alan: Well, since Kanban doesn’t really talk about the team, Kanban talks about the floor work and there’s a lot of power in talking about the floor work. So what I’m adding… Creating cross-functional teams, that’s something I’m actually suggesting is should you use Kanban for. Kanban itself doesn’t talk about that. Kanban totally focuses on how this workflow from the idea until it gets deployed, and that’s what you think. Kanban doesn’t go to how the flow from the beginning to the end and Kanban attends to the system that people are working in. Don’t put too much work in at the front because it will clog things up, causes traffic jams and walking distance of that nature.
What I’m suggesting is that there is a pattern of success with cross-functionality. I’m not saying you should say Kanban is about creating cross-functional team but I’m suggesting that as you look for how you would succeed, one of the things you need to ask yourself for, ask yourself about is, how should these people be working together.
Yes, manage it with the flow and work in partners and things like that. But one of the things you should ask yourself is, would these teams be working together better as cross-functional teams. And if the answer is yes and I think the answer is almost always yes, then as you’re looking at managing the work you should consider how can I get as much swarming and collaboration as possible.
Now, Kanban will actually get you there without even thinking about it to a large extent because Kanban always have, you’ll get queues around the inbox. You’ll get the laser and handouts. So when you conform, you will see that things go better. So in a sense, the natural pressure of Kanban is going to be towards cross-functional teams.
I’m just suggesting you should make it explicit, we should talk about it because I think you’ll get there faster when you have some consciousness about why you’re doing what you’re doing and that where you’re going. I think knowing the goal and always may be questioning it to be sure you’re not going on some dogmatic journey is important. Again, going back to the essential skill book where I was saying conscious awareness of what you’re doing and why you’re doing it has a big impact.
I’m suggesting when I talk about creating cross-functional teams with Kanban… All we’re doing is creating conscious awareness to things people have seen themselves that we did a really dynamic teamwork and great managing their flow, managing their work in progress. It’s phenomenal.
Now, the fact that you can do a lot better when you don’t have such a team, by attending to flow and web and using Kanban to start working into this functional organization, well, that’s great. But let’s not get complacent. Let’s recognize that there might even be a better structure.
So one of Kanban’s weaknesses, per se, is its ability to kind of work in a variety of places. So if you don’t have cross-functional teams, well, that doesn’t mean you want to just keep working there just because it will work without a cross-functional team.
I think there has been some loss of this in the industry.
Joe: I always thought you wrote a great book that the pocket guide for Scrum Teams, is that applicable to the Kanban world?
Alan: I think it is to some extent, but I think it needs to be updated. The way that it’s applicable to the Kanban teams is it talks about challenging mindsets, and it really gets you thinking about why you’re dealing in other alternatives. But it never gets short of the time boxing. And it’s totally downloaded in the Scrum framework. So in my mind, if you actually do what we say in the Lean, Agile part you got for Scrum teams, in my mind what that’s doing is not Scrum. The Kanban mindset, the Lean mindset like the Scrum, it’s not as good as if it were a Kanban. In fact, I expect in another… We got some key things that we’re working on right now in my company but I expect that when we get a couple of those things on in a couple of months, our plans are to take that pocket guide and update it with what we’ve learned. It’s a couple years old but then what we want to do is create a Kanban pocket guide.
Talks about the practices but more important, well, at least equally important is to why the practices and what you do and also patterns of success. Because that’s something actually I do think it’s really maybe the most fun thing about my job is, we get to see many, many, many organizations both in the Scrum camp and the Kanban camp, successful or not successful, because it’s like just us.
I mean, I will say, most of the people we work experience really good success but we also deal with a lot of people in conferences we go to and I’ll be the first one to admit, not every one of our customers has hit the ball out of the park. So we’ve seen challenges and patterns of challenges, not just with our own clients but with clients when we go to conferences but because we have like about a dozen consultants and we do a lot of time talking to each other and cross training with each other.
All of us have seen lots of different cases and that power of having a collection of people like that enable us to be part of success patterns to failure and it really shows us not so much what’s wrong with like Kanban along with Scrum or along with Lean, but rather it shows us the humanity, how do people approach problems, what are the necessary? I mean, that’s the common theme here.
The common theme here is that there are people at the end of every process that are doing this. And when you see patterns of success and failure, you start realizing that people will do transitions in particular ways and that part of your method, part of you framework, part of your process, part of your mindset or whatever, actually acknowledge that they’re kind of a… Respecting people to do their job is not enough. You need to respect their humanity.
How did they… What’s the cytology? How do they like working with other people? That’s what I mean by the humanity, the tribal nature of people and what’s this vitality? How do they adapt? If you don’t pay attention to that, if you don’t understand the culture of an organization before you make your recommendation, then you’re really honestly nice and we see this all the time and it’s really one of the biggest ironies in the whole Agile community because Agile talks about respecting people.
All Agile does, they feel in most camps, say they respect people’s knowledge. These people are going to figure out how to do it. Well, I respect that. That’s great. Lean respects that. Kanban respects that. I mean, you’re kind of insane not to respect that. You’re in a different lose situation if you can’t trust your people to know the best about their jobs. That’s just like the foundation. But then, when you see, respecting the way people react to change. People don’t like big changes or respecting the fact that people typically are closer to the people they work with every day and not as close to the people over at the other groups.
How you’re managing your large scale transition, how are you attending to those two things and, to be honest, Lean and Kanban are the only ones that I see in the Agile space doing. XP talks just about teams and Scrum kind of pretends you can go from team one up and that the dynamics, they talk about, “Oh, well, it’s fractal, Alan.” That’s where the behavior higher up is the same as the behavior at the bottom, and that’s the rotten metaphor.
It is fractal, a fractal is structural. So like an example, you can look at subatomic particles, and you can look at how much space is there between sub-atomic particles and then go up to protons and neutrons. I’m talking about even sub-atomic. You can go to protons and neutrons, electrons.
You can go to atoms and molecules. You can go to molecules and cells, then go to cells in the body and then go to people and on the planet. Then go from one planet or the stars to the galaxy. Then the galaxy, the universe and you see this fractal nature in the relationship there. But you know what? That’s fractal structure. The behaviors are completely different at those different scales.
I’m suggesting that, when people work at the fractal nature of organizations and they say, “I get this little team of players and I’ve got a group team, and now I got a division and now I have a company,” and they say, “Well, these are just all teams,” I’m saying, “Yeah, they’re all teams but they all behave differently. The dynamics are different.” And missing that point is what I think the Agile community, particularly the Scrum community has been missing.
Now I say that with caution because people will say I’m bashing Scrum when they say things like this. So no! I’m not bashing Scrum. I’m saying Scrum is a great framework and a great place for it to work. But taking it out of works design to work, you know it’s not the place. I go to lecture at 3:30. I love my car. But you know what? It is horrible to learn to steer out of your life. I just don’t understand it.
If somebody would try to tell me that if I put a couple of pontoons on my car, a propeller and this was a great… It’s not a great boat. I’m saying it’s crazy. But that’s not in my lecture, a form of my lecture.
We got to work to see where the things are applicable and what I don’t like is when people say something is applicable when it’s not. I did get on my high horse on that one, I admit. But I want to be really clear, it’s not the method; it’s why are you miss?applying the method and why are you putting in a place that’s not the best place for it. That’s more of a mindset issue, naturally I guess what I rant about.
Joe: Does each part of the enterprise have to be Agile then to make it successful? Can it be different at each different layer?
Alan: Well, you want to business agility, so I would say each part of the enterprise needs to have agility. The purpose of agility is delivering incremental business value. And to do that, every level of the enterprise needs to have some agility to it. This is the one of the challenges then, is then how to unify different levels of an organization at different concerns, different skills, different motivation, different layers are being measured. How do you unify them? The way you unify them, in my mind is you give them something that they all have a vested interest in. This is why the value stream is so important because it’s from right up in the beginning when you decide what you want to do, where are you going to get the best value? Not to where it’s sold, but to where it’s consumed and supported and used. Everybody can get on the same page, so in a sense, you are creating now a new team. The team is called the organization. So in that sense, maybe teamwork is the right way. You don’t normally think of what’s beyond as a team whether you think of it as having teams.
At this high level of calling it a team is I think a misnomer but what you have created about it that your kind of team like is that everybody on the team has the same purpose. That you see this was a great company. Then I’m not, I can say what I’m about to say because this does not come from anything inside.
But you look at a company like Amazon or a company like Zappa, which is actually a subsidiary, but the thing that makes these companies rich, Zappa is a great company before Amazon bought them. What makes these companies great, if you actually look at it, is that everybody in that company has a view of getting the same result. And in Amazon’s case, it’s customer service.
You see this when you talk to the people, and this is actually where I got this, is talking to some people in years of work. You could see that yeah, they have this job; yeah, they have this role. Yeah, they have this team that they were working on. They have this accountability of the software but what they were really looking at, when we’re serving our customers, or they come into our site to buy stuff and get what they wanted in a way that was a positive experience.
Everybody there that I talk to has this. When you have that, now you have an exciting team. That is only created when there is a common vision. If what you’re doing is actually separating the components and making the components work better but still separating and then you can’t create really world class vision and teams.
That’s what I guess I’m really up to. I mean it’s not just about how do I make a company be three times more productive doing the wrong stuff? I mean, that’s useful, actually. I mean, they’re really, it sounds silly, but it actually is useful. I mean now they have a better shot at discovering what the right stuff is if they can get stuff done in less time.
What’s really exciting is how do you make your customers happy? How do you get them coming up with a great product? I think that just takes more than individual teams to do it. I think seeing all, if we put together teams first and then move up, that might work. They have at times, but it’s a very rare event. What’s interesting is that you look at the biggest Scrum successes, they didn’t happen that way. The sales forces are good example of Scrum’s great success story, but it was also mandated by the CEO.
You have a lot of pressure from the top creating the context of what was going to happen, and then the team is self-organized with a lot of help. Then they self-organize, in that sense a lot of coaching, things of that nature and you have a great success there. So Scrum there in a bigger context is things that make sense to me, well by itself, it’s missing a lot. It’s this other team, how do you create that high level and the mid-management to work? How you bind them altogether is essential.
Without that, you can see a lot of people succeed for a while and then it just kind of plateaus. I think that’s where Agile is starting to get a backlash now because they’re making teams Agile, but the business isn’t any better.
Joe: I can understand what you’re saying here because it’s just about like it has to grow organically somewhat that under that common clarity of mission for a lack of a better word there.
Alan: It does have to grow organically, but it’s got a good firm, it doesn’t just throw seed out into the farms and say, “OK, grow.” I don’t know what you’re doing. I don’t have this work. It creates a structure within which you can go; there’s a top vision. Even though, every plant now is going to do and send its roots down, around the rocks, not trying to go through the rocks. Each plant is going figure out how to do its best if you don’t have that context for all; then the plants aren’t going to be very well. I think that’s really, really the key. I think somehow we’ve missed this in the Agile community, and I think part of it is… I think the Agile manifesto is amazing. I really, really respect the people who put that there. Every one of them is just brilliant. A manifesto is temporal by nature. It’s saying, here’s where we are, and we need to make it break.
Well, you know what? We’re not where we were 10 years ago, and you can still hear people saying, “Well, I don’t define by the manifesto.” I’m like, “That’s insane, I’m sorry. It’s insane, I guess it’s coming here.” It’s insane. We’re not where we were 10 years ago. 10 years ago, it was brilliant. Now it’s missing stuff.
So we need to ask ourselves what is it missing? What do we need? What’s not working about it? That doesn’t take away anything from the great people who did it 10 years ago. It was phenomenal but it doesn’t last forever, and I think we tended to not think anymore again. You know, I’ve built this. You look in the manifesto, and there’s just a lot of stuff missing. If you look at what I’ve been saying the last however long we’ve been talking, you will see there’s a lot of this missing. Of course it was missing, didn’t need to talk about it back then.
What we needed back then is not where we are now. Building on the foundation of manifesto we can go to a new level. I hope nobody takes this as any kind of attack on that, absolutely not. It’s wonderful, but its manifesto by their nature of temporal and has to be re-looked at after a while.
Joe: I think that’s said wonderfully, Alan. What’s on the horizon for Net Objectives and Alan Shalloway?
Alan: Well, I think we’re getting more focused. It’s funny you say this because I just came back from… This is one advantage of being a CEO; we had a leadership meeting, executive meeting and we did it in Kauai, Hawaii. It’s one of my favorite islands there. And we were really looking at the industry leadership and our focus and one of the things where… We actually are global now, but we’re actually looking for expanding out into India, Asia, and China. A lot of our large accounts have training out there. I think you’re going to see more of that. I think some of the things I’m talking about are really included as well because we’re very much interested in how we can improve the management and the things. How do you… Lean and Kanban and Scrum make the management side better. We’ve been doing this for a few years already, but I think we’re getting more focused on the necessity and the knowledge of it. That’s really, I guess most of it.
The other thing actually is sometimes we’re getting resurgence on the technical side. It’s funny we started out as… I used to call us a design pattern company. We’re 13 years old now just about, and I remember, who I just totally love, just brilliant guy, and this was early on like we’ve been in existence year three.
You shouldn’t call yourself a pattern company, and I realized he was right. Patterns were the solution, but really are launched at how do we help our clients, how do we help people that have a software component. In a software component development firm, how do we help them move ahead when there’s a product?
Right after that, we went into Scrum and then cleaning up Kanban and business portfolio and stuff like that. So I see that, well, it’s funny. We kind of moved all the way up to the front of the value stream. We’ve been doing some big stuff with large companies, but what I see is missing again, is the knowledge about the technical side.
It’s kind of funny the essential field work comes up because even though Net Objectives, people think of us probably, I think mostly as like Lean and Kanban and all that, we are actually one of the strongest contingents of technical folks around. I’ve written an award-winning book in the past called Pre?Factoring, Scott Bain or a jolt?bringing book Emergent Design. I think the Design Patterns book is still right up there because it teaches you the thought process of patterns, not just what patterns and solutions are.
Kolsky is our 4th author on the Essential Skills book and he’s not that well?known but I tell you this guy knows as much or more than anybody about how to break stories down for testability, how to use tests in writing code. I’m actually putting a little bit more focus back into my roots I guess. I think a lot of teams, a lot of companies they focus solely on the process that they’ve kind of forgotten.
If you have seen a little bit of resurgence with XP coming in now more into scope which is really wonderful, it continues the integration, TBB and things like that. But there’s still… The technical aspects of Agile are still so overlooked, and we have such a great skill set. I think that’s one of the things I’m going to putting my focus back. Maybe I’m coming back full circle, and it may not be me, actually its probably be like Scott, Ken and Amir would have to do these more but I think we have to look strongly, so we don’t take advantage of what’s known in how to design.
We have just scratched the surface. We don’t have to really create anything new. We just need people to build on what was done in XP, what was built on in APDD that’s happening now and some of the things we built ourselves. The essential skills work is kind of also coming out because we feel that’s the other holistic piece. It’s not just them, it’s not just managers and not just process. You are writing codes, and you got to know how to do that. I think this is way overlooked.
There are a lot of really smart people out there who are talking about this and maybe helping the lead back. We may not lead it but at least add our voices to that. A lot of leaders out there but we want at least to put a lot more of our energy on this, so people recognize that we’re not just process folks, we’re not just business and managers folks. We are a force to be dealt with on the technical side.
Joe: Well, I wanted to add that the Net Objectives website is just pack full of information and even given up your email, you get very little information sent to you. I have to admit that you do a wonderfully, tasteful job of managing the information that people get from you and replying them. You do a marvelous job there.
Alan: Well, thanks. Our mantra has always been, from the beginning that we’re in service for people. Our values are basically service to the customers; serve value to us and value the industry is really the root core of our value. So we have a lot on websites because it’s like selling ice cream. What’s the best way to sell ice cream? Well, it’s not enough to describe how wonderful it is, is to give a little taste. So we’ve always thought that one way of serving people is giving them a taste. In this case, this information and yet we have to respect people. So we know people are busy. We try to do it anytime we talk to you, we’ll give you value. That’s an important part. That’s creating industry values, an important part of our company.
I think that’s really why we’ve been successful. Yet I think, it’s just the beginning. I really think the best is just ahead of us as we now move into how to really help guide the industry. For the first several years, I think we were more just practitioners, and we started having a role in guiding and we have a role we play in the Lean software systems consortium which has, does great, really they’ve done the best conferences I’ve been to, like 60,70 conferences I’ve been throughout my career.
Their three have been my top three and we spawn the whole bunch of conferences in Europe that I’m proud to see and I think we’re going to see more and more of this integration of ideas and the next one by the way since I mentioned the conferences was in Boston in the U.S. in May.
I think what’s really neat about the Lean Kanban community and Dave Anderson is organizing in the U.S. conferences is so brilliant is that he takes people who are really brilliant, but you don’t necessarily associate with Lean. Maybe that’s the other piece is bringing all these people. I mean, software development is an extraordinarily complex development and whether it’s IT or product development and because of that, you need to keep bringing in all these different aspects of things and not just have this super narrow focus.
To do this, is extremely uncomfortable for a lot of people. So how do you do this when you know you’re making people uncomfortable, but you get them to kind of go forward, and this has really changed dynamics. It’s exciting because it’s about transforming people. It’s about really having people’s lives work. I like what I do; there’s no question. My job is really interesting.
We’ve been financially successful. But what really gets me up in the day is really serving people and transforming them and I think that’s really what Net Objectives is up to.
I think that’s really what a lot of companies out there do, a lot of the great consultancies that are there, they know the real thing is service. I’m not saying that we’re unique although I don’t know think there are that many of us out there. I think that’s what really gets great servers, people really are into service. I think we got to just keep doing it and figuring it out, and that’s really kind of my mantra. I feel both humble and proud and happy that I get a shot at this
Joe: What’s the best way to contact you?
Alan: I love people talking to me, just alshalloway@netobjectives.com and check out our website, www.netobjectives.com. I’m on user groups. There is the Lean-Agile Yahoo group I moderate. I work on the Kanban Development Group a lot. I’m on a lot of the Scum communities because I see a lot of people struggling on things we help solve and just do a shout out or just send me an email. I’m happy to talk, happy to send information back. That’s just part of my job.
Joe: OK. Well, I would like to thank you very much, Alan. I appreciate the entire conversation here. This podcast will be available in Business901 website and also the Business901 iTune Store. So thank you very much.
Alan: I appreciate the feedback. This has been very actually fun and very enjoyable, so thank you.
Lean Sales and Marketing: Learn about using CAP-Do
Lean Engagement Team (More Info)