Industry stories on agile, scrum and kanban


Published on

Eric is an Agile Project Manager who has been using Kanban for software development since 2007. He has worked with Scrum, XP and other agile methods for over the past 5 years, and has been managing software projects for over 10 years. Eric has his own blog, Corporate Coder which can be found at He is also a frequent contributor to

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Industry stories on agile, scrum and kanban

  1. 1. Business901 Podcast Transcription Implementing Lean Marketing SystemsIndustry Stories on Agile, Scrum and Kanban Guest was Eric Landes of the Corporate Coder Blog Related Podcast: Scrum + Kanban = Agile Discussion with Landes Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  2. 2. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsOn the Business901 Podcast I had the pleasure this weekinterviewing Eric Landes. Eric is an Agile Project Manager who hasbeen using Kanban for software development since 2007. He hasworked with Scrum, XP and other agile methods for over the past 5years, and has been managing software projects for over 10 years.Eric has his own blog, Corporate Coder which can be found at He is also a frequent contributor to Eric has been involved with ASP.NET since Beta 1. He currently is an Intranet Developer/Project Lead for a company in the auto industry in South Bend, IN. They develop using ASP.NET, Sharepoint, Project Server, Reporting Services and other Microsoft technologies. He is also the president and founder of MADNUG (the South Bend .NET User group), writes articleson Aspalliance (, and is the editor ofCrystal Alliance (, part ofAspalliance.Eric first caught my eye when I was reviewing the conferencespeakers and workshops being hosted by the Lean Software andSystems Conference held last April in Atlanta. I had noticed that hewas presenting a real life scenario of how an Operations Group’sKanban adoption failed to improve cycle times. The session endedup in a 5 Why session and a Q & A to discuss other situations thathad not produced results. I thought it was an excellent way tostimulate discussion and to learn more about Kanban versus thetypical “this is what we did” approach.Our discussion started with Agile drilling down to Scrum, the lasttwenty minutes on Kanban and what he has learned implementingit. Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  3. 3. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsJoe Dager: Thanks everyone for joining us. This is Joe Dagerthe host of the Business 901 Podcast. Participating in theprogram today is Eric Landes. Eric is an Agile project managerwho has been using Kanban for software development since2007. He has worked with Scrum, XP, and other Agile methodsfor over the past five years and has been managing softwareprojects for over 10 years. Eric, I first ran across you when youwere presenting at the Lean Systems and Software Conferenceand I have to admit I was very impressed.Because what you brought to the table was a discussion of afailure. And I thought that was very brave indeed to take thatsubject forward and talk about, I guess it was a Kanban failure?Eric Landes: Yes. Yes it was. Hi, Joe. Thanks for having me on.It was one of the things I had presented the previous year inMiami as well, kind of our success. And so I had been seeing a lotof chatter on some of the email lists about, as we really gain thisbody of knowledge about software development using Kanban itwould be good to see failures and where things arent workingquite right. So, that everything isnt just roses and a rosy picture.We understand that things dont always work quite right.And I think the idea is we want to learn from our failures, so itsOK to fail. So Im taking that attitude when I was doing thatpresentation as we wanted people to kind of learn from thosefailures or at least that particular failure.Joe: I give you a lot of credit for doing that. I think thats great.Now, you have a blog called "The Corporate Coder" and it can befound at Is there a certain theme for the blog ordo you develop that for ... based on LEAN software development?Is that what its all about? Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  4. 4. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsEric: For the most part its about what I do on the business sideof things and its definitely focused on Agile, Lean softwaredevelopment topics. There may be some more technical types ofblog posts I might put in there. But those are becoming fewerand fewer. I come from a developer background so I do like todabble in C# or whatever. Try and teach my son Ruby on Rails orwhatever. Normally its not going to be technical. Im probablynot as technically proficient as I used to be and its mainly underthat Agile and Lean software and thats kind of where Im at now.Joe: Being involved at Agile for probably 10 years I think orsomewhere close to that neighborhood. Explain for the peoplethat maybe do not understand Agile and is Agile really Lean?Eric: Joe, you could have a pretty good debate on that withpeople like David Anderson and Jeff Sullivan. But I think mostpeople would agree there are a lot of good Lean principles in theAgile movement. The Agile software development movementreally came about as a reaction to a kind of the command andcontrol as I call it or "waterfall method of software development,which really didnt take into account some of what I call Leanprinciples of valuing people, your employees, and looking forcustomer value. In the software development waterfall methodyou have a method that really states, we are going to gather ourrequirements up front. Were going to give them to the IT andwere going to spend a lot of time gathering those requirements.Were going to give them to the IT people. Theyre going to spenda while fixing them. We are going to get that back and we expectit to be exactly like the requirements. The problem with that was,we werent talking a lot to the customer to find out if theirrequirements changed.We really had these death marches at the end of some of theseprojects to get them done and we were really putting a lot ofstrain on software developers. So some people had come Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  5. 5. Business901 Podcast TranscriptionImplementing Lean Marketing Systemstogether they had been using some of these techniques, too, thatwere very successful for them.They involved things like, instead of gathering requirements andthen the IT group would go and huddle around, and do their workfor six months and nobody would see them. They did a lot offeedback loops between the customer or a marketing person andthemselves to get the, software that they wanted correct.So they started using tight feedback loops, they started breakingthings down into smaller packages and they also tried toconstrain expectations so that the developers, they would have todo the exact marches at the end of software projects where theyare just working around the clock and burning out, and so Iwould say, when it started out, probably the relationship betweenthe lane and agile was the idea of delivering value to thecustomer quickly and empowering the employees which I believeare two lean concepts.You probably would have some people saying that agile is notnecessarily lean for writing reasons but I like to believe that youcan definitely move from agile into a more lean, continuousimprovement kind of mind set but just because it do agile doesntmean you are going to move into that lean concept, if that makessense. So hopefully it was kind of a long explanation buthopefully that gives me an idea of the relationship between leanand agile.Joe: Can you really have seven day and thirty day iterations andget the customer feedback in short cycles like that?Eric: Oh yeah, absolutely. We are currently using two weekiterations so I use currently, Im doing a pretty fairly pure scrumimplementation which means, you have sprints and there came todecide what those sprints are, and within those sprints, yourteam commits to finishing x amount of stories and by finishing,we mean we can deliver that, we could actually, in this case, lets Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  6. 6. Business901 Podcast TranscriptionImplementing Lean Marketing Systemssay its a web application, we could actually deploy it to a webserver and you could use those features at the end of your sprint.So we are committing to two week sprints and we are saying wecan do, lets say for the sake of argument, five stories and we willfinish those at the end of this. When we say that, that means theteam, how big it is, is committed to delivering that and I haveseen time and time again, teams will be able to do that. The realtrick is, your stories need to be sized correctly and your teamneeds to be able to have reasonable expectations of what theycan deliver.After you have done scrum a while, your team has an idea of howmuch they can deliver in one sprint, but I have seen sprints ofone week work effectively to it. It just depends on the team andwhat they are comfortable with.Joe: To build the user stories takes a little bit of experience andsome trial and error because when you start out with the first,lets say scrum effort, you are going to make some mistakes?Eric: Absolutely, yup.Joe: You know that two week iterations may end up being athree week iteration and/or one fifth of the user stories not beingdone.Eric: Right. So, lets say on our first... The first time I really dida scrum implementation, we just totally miss what we weredoing. We totally... We over committed to our... What we coulddeliver. And so, when we got to the end, we had already set upexpectations for the stakeholders. So, thats one of the things youreally want to do with your teams is, to get an expectation thatthis is new. We are learning so hopefully you will take that into anaccount. If you dont have that luxury, in our case we have thatluxury, if you dont have that luxury you definitely want to havesome more training then probably we had. But, if you do havethat luxury you can go on with that expectation, keep lower Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  7. 7. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsexpectation with the stakeholders, with costumers. let themknow, at the end, you can commit. You have betterunderstanding of what you are doing and what you can committo.As long as you build that trust and start hitting your targets, youare OK. It is when you consistently dont hit targets that thecostumers tend to get upset. I should also add, I was not doingthis as a consultant. I was doing it as an internal group. Youwould probably have less forgiveness I guess if you’re aconsultant.Joe: As a consultant, we could probably come up with betterexcuses, because weve done it before, the excuses.Eric: There you go. Make sure you have some excuses in stockand you are good to go. But like I said, after by the second sprintwe did we really started hitting our targets and having betterexpectations of what we could deliver. So it turned out to bereally worked out well.Joe: Well a lot of my listeners are from the Lean manufacturingbackground so Agile may be a little foreign to them. We think ofagile more what I have heard from different people that it isreally from concept to consumption is a buzz word I have heard alittle bit. Can you explain a feature in a story to me.Eric: Sure. So, I am going to a couple of differences in Kanban.You can use feature and story within Scrum, as well. Mostpeoples do tend to use stories in Scrum. Usually, a term used... Aminimal marketable feature. Its the smallest feature we candeliver on software that is going to be used by the costumer.That makes a difference for the costumers.If you are in a software development shop and you have softwareor website that you are selling something digital like software.That feature is going to be something, say like a marketing Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  8. 8. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsperson is coming up, whereas if its an internal softwareapplication you might actually talk directly to the costumer andget that feature.The feature verses story, normally what I would say is thosefeatures normally break out into stories from the feature. You canalmost think of stories thats a smaller set of a feature if you willthat probably have to be grouped together, if you are actuallygoing to sell your software.Normally, what happens when you are moving from, say Scruminto Kanban... A lot of the Kanban teams are using their ideas offeatures. And then, the idea is, they want to take the featurefrom... Like you said, from concept to cash or whatever, andbring that through their system of software development.When I look at the differences between what we call like a Scrumor XP, and the Kanban process. The Kanban processes really arethe lean process that the software development uses. We arelooking at mapping your process as it stands. Seeing where thebottlenecks are, using a board to map your flow, see where thebottlenecks are, and then try and fix those bottlenecks as youdgo.Normally, youre going to use a lot of the Agile methods forsoftware engineering. Some people even use iterations duringtheir Kanban. But for the most part, youre looking in the flow ofthings. You arent really doing fixed link iteration, time-boxiterations. Youre doing more of... I dont want to say one pieceflow, because thats wrong.I mean, we would love to get to one piece flow. But I dont knowanybody who would claim that theyre doing one piece flow in asoftware Kanban. At least, Ive not heard of anybody doing that.Joe: Before I jump further into Kanban, I want to ask onequestion. We look at Agile as being the umbrella over all these Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  9. 9. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsthings. Scrum, XP. Are all software companies now Agile, or thelarger percentage? Where is that really in the time-frame ofthings? I think of a bell curve, is Agile over the bell curve? Is itmature now? Is it a mature product?Eric: I know Ive seen statistics that say... Well, I want to say 70percent of companies are doing Agile. But that doesnt mean 70percent of the projects are Agile, it just means theyveexperimented with using Agile. They may have one or two teams,out of all their software development teams, using it. Id say itsdefinitely a mainstream methodology. At this point in myexperience, I wouldnt say a majority of software developmentgroups are using Agile. But its probably getting there. Thestatistics are kind of hard to tell. Statistics say 70 percent ofcompanies are using Agile, but I wouldnt say that meanseverybody is in those companies. So, I dont know what a goodguess would be there, but its definitely mainstream.If you talk about Agile to management, they understand thatnow. So, its also a good way to bring in some of these conceptsthat are very similar. Like the Lean concepts, Scrum, and XP. Iremember, years ago, when I talked about XP, people thoughtthat it was dangerous or something. So, its a lot different now.Joe: Is there a time that you shouldnt use Agile? Or, youshouldnt be Agile, that you should use a waterfall project?Eric: That you should use a waterfall project. Ive heardarguments... In my experience, the projects I worked on... Iwould say, they all should use Agile. But you have something thatis fixed, and theres no variation in what youre developing... Weall know, the developers know exactly what youre doing. Thenyou maybe want to use waterfall, or you might want to mix insome waterfall methods with Agile. If youre doing something,say like, defense contracting or something. Ive heard somepeople talking about how they use Agile with defense contracting. Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  10. 10. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsIf youre writing a software for the Shuttle or something like that,or lives are depending on it. I think you can use Agile in all those,but probably, your quality effort is different.Joe: If youre comfortable with doing it. I mean, if you have aterrible golf swing, but you shoot in the 60s all the time... Keepit, right? I think that way a little bit. I mean, it depends. I mean,you may not meet the top of the circuit doing it, but whateveryour expectations are, if youre meeting them, you continue on.We mentioned Kanban, and we brought that into theconversation. This is a good lead in, because a lot of people saythat Kanban is really just a waterfall project on a board.Eric: Right. Yes. Ive heard that. To be honest with you, itprobably could be at first because you are mapping your existingprocess. So if youre existing process is waterfall you probably aremapping a waterfall method to this Kanban. The surprising thingabout Kanban, if you do... And let me kind of clarify this. When Italk about doing software using a Kanban system, first I talkabout mapping the current method you use onto your boards. Forinstance, we maybe have a back log of requirements, in our caseits called stories.Then we have a business analyst who does some of theirrequirements stuff gathering and some other things, thendevelopers and then a QA group. Then we might have a useracceptance testing, thats what we always do.And then we deploy because we are a web based App, we deployto our web server. So if we map all that into different queues,now all of a sudden we can see what everybody is working on.One of the things thats kind of important to do is to put limits oneach queue.So logically what usually makes sense, if I have two QA peopleIm probably not going to allow more than two things to be Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  11. 11. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsworked on at once in that QA queue. Those are what we call ourwork in process limits. We can talk about that in depth a little bitmore but the important thing about those is if you get that rightyou can really start seeing bottlenecks and where your problemsare and that really starts driving improvement to the process.So thats kind of the important thing. If you start with thiswaterfall like Kanban board, six months from now youre probablyarent going to be very waterfall like. Its probably going to bedriving a lot of improvements to your process.At least it should be. Youre probably going to see yourself havingpeople help out the QA group if theyre the bottle neck and tryingto get them to, "Well, were going to test now. Were normallyBA, business analyst, but were going to help you test."Or maybe the business analyst is the bottleneck. And so nowwere going to help them out and do some things there and weregoing to come up with some good ideas like running acceptancetests as developers in QA, or whatever. The idea is you startimproving.You get ideas from the team and they were going to start doingtest room development which we didnt do before so that ourquality is better. I think, like I said, yes, you can start withwaterfall. With Kanban, I think, thats probably true.And to be honest I dont know anybody who really did that. But Ithink it probably could happen. I cant imagine if youre doing itright that you will be doing waterfall. Because you just cant helpbut improve that process. You are going to bring in new ideas andnew processes in there to help make you flow faster.Joe: If anybody is listening to this, youre probably have seen aKanban board somewhere on my blog. But a description of it, youhave four stages, for lack of a number. There is a column foreach stage and its split in a doing and a queue. Getting ready to Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  12. 12. Business901 Podcast TranscriptionImplementing Lean Marketing Systemshand off to the next stage, is a pretty basic description of one.And when you do that I go back and I see that, and then thework in process limits youre just going to... I think, as DavidAnderson explained to me, you just circle a number. All at once itwill limit your work in process, and youve got a Kanban board.Eric: Yes, I would totally agree with that. Like I said, thosequeues, the limits... When a queue fills up... The reallyinteresting thing is, when a queue fills up and the team cantwork anymore on their... Im a developer and I cant move myticket now, because here is this work in process limit. The rule is,I cant move my story to the next queue if the limit has beenmet. So that means I cant move on right? So now what do wedo? One of the things we normally do in our Kanban projects iswe would have daily stand-ups. So you would normally, daily, seewhat is going on. And if that would happen, you know, hopefullyyou dont wait until the daily stand-up to say that. But if ithappens, at say 12, and your daily stand-up is at nine, you dontwait a half a day to tell anybody that. If you do, then we cantackle that as a team and say, "Well what is the problem here?"If it is going to QA..."QA, whats the problem?" I really got towrite a lot of tests here because we havent done that. We didntautomate this. So we need some help. Maybe the developer cancome over and help. Theres some other dynamics that go alongwith developers helping QA but...Joe: Really what that does is it creates more of a team effort. Isthat not right?Eric: Absolutely. Thats the other thing is it introduces the ideathat Im not a developer, I am actually part of a team and ourteam is trying to get this done. Thats definitely something I havehad issues with in some of my teams before. That idea of, "WellIm in QA I dont do development." Or "Im a developer and wereally dont do testing." The idea that we want to get through to Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  13. 13. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsthem is, "No your part of a team." We want to do what it takes toget it done. If that requires you might have to test for a day, sobe it. Lets do that and get it going so that we can get the teammoving. The Kanban board just highlights that. You see exactlywhere the team stopped and you see whos open. Thats theother thing. Some people may not like the fact that is so visible,that their work is so visible and so transparent to the team.But, for the most part, I have found that team members want todo well and thats a good thing to see. To get that transparencyand visibility into your process and they will help out when theycan see that, "Yeah these guys got so much work." Or, "That girlover there really needs help." You know? We can help. That justhelps tremendously.I think that visibility just really helps the team concept goingforward.Joe: I think it is also interesting, because most of the problemsthat I have always seen moving from one state to the next stage,especially when you value stream map-up projects are the handoffs. If someone is coming back to help, they recognize whatsneeded in the hand-offs, more than anybody else.Eric: One of the first implementations we had, it turned out thebottleneck was me. I was doing builds and we... For some ofthese tests we had to build software and then put it into a QAenvironment. If it didnt begin in a QA environment, it didnt havethe latest build and couldnt do it. As we were looking at this, itbecame apparent "Well Eric, the last time you did this was threeor four days ago, they needed it yesterday. So whats theproblem?" Thats one of the things we talked about was, "How dowe know... How do we hand-off this so that Eric knows that hessignaled that, "Oh he has to do this.""So we came up with a signaling system on our Kanban board thatwould tell me, "Oh, its time to build." If we have two stories that Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  14. 14. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsare ready to deploy, then you got to go ahead and deploy. Untilthat gets filled, we dont deploy or some such rule. Bu thatbecame kind of our signal, to show Eric that, "Hey, thats ourhand-off." Its time for you to do your thing.Nothing ever works perfect. We all know that, and Kanbanhighlights it in its visual stream. But what happens when youvereally got to ram something through? Do you still use the samemethodology? How do you handle that?Joe: It probably depends on whos doing the asking. But inreality, usually the really cool thing, especially about Kanban andnow agile, if somebody comes to you and says weve got to getthis done, you have a very good backlog or an understanding ofwhat your team can accomplish and how long itll take them, andyou have a good system of tracking it. If they bring something in,and lets say its a feature, especially in a Kanban board, becausethats a flow kind of system. You can say, "If we know that 95percent of the time, when we get something of this size into ourKanban board, we can deliver it in a week or three days,whatever your time is for that. Youve got those statistics, andyou can tell that to the business owner.If the business owner comes back and says, "Youre telling me aweek. I need it in three days, because weve got a customer whosigned a contract. They need this feature out there," you canexpedite that even more. Thats something that as long as yourteam agrees to it, Im comfortable with doing.Eric: Some people might be not as flexible, but I understandwhen there are customer needs. But you dont want to just dothat every time. You really want the business to be able to say,"Your agreement of how long itll get done, thats comfortable tous, and we know we can count on that. Were comfortable withsaying it takes a week." Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  15. 15. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsThats cool, as long as you make that the next thing theyre goingto work on and you can tell me that theyre going to get thattomorrow or whatever. Thats the level of comfort I think youwant to get your executives or whoever is asking those kinds ofthings to so that they trust your team to deliver in the time theyneed it.When you have those silver bullets, you can re-prioritize or eventake things off the board if you need to and put that silver bulletin. Im throwing out that term "silver bullet." I think DavidAnderson needs that.Thats a case of where we cant just have this next on thepriority. Its got to go now. If you have some kind of system inplace, you can say, "OK, we can do that, but that means thesestories, were going to have to delay those," and the silver bulletgets done.Thats probably something I dont know that Ive ever really donethat. I try to discourage that. Normally, the customers that Ihave worked with are OK with just being next in line, with theirrequest being next in line.Joe: Its a poor business practice if it really happens often, youcan’t really afford to let it happen that often. One of the thingsthat I look at is that, if you have a Kanban board and youvedeveloped a team, you know where your bottlenecks are. Youknow where your supports got to go. That certainly helps to getsomething through quickly. Your business leaders and the otherpeople that come in can see the board. Its so visual that theyknow, and have a certain expectation out of you, whats next,what they have to live with. Dont they? The boards canself-explain itself?Eric: That whole visual board thing is probably the biggestselling point when you go to your executives or managers, orwhat-have-you. They see that value. Immediately they can see... Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  16. 16. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsWhen you explain to them, "Well, this is what were working onand you can see here these are the things that were currentlyworking on for this project. Heres this other Kanban board. Thisis our support board and this tells you what were doing here."Wow, the lights just go on. One place where I worked we just hada tremendous amount of interest generated because where wehad the Kanban boards were so visible to the rest of thecompany. People would just see it and go, "Wow, what is that?"And youve got a good conversation going. Next thing you knowthey realized they could see our work progress.Other groups started doing similar things because they saw thevalue just in that visual part. Not even necessarily in the rest ofit, which is even more beneficial in my opinion and at least yougot them started down that path. You get a lot of good buy-in Ithink just because of how transparent everything is in yourprocess.Joe: Do you document this in software or does the visual boardspeak for itself?Eric: For Kanban we had it in the software as well as on aphysical board. When I first did it we tried just doing itelectronically. We ended up not continuously improving.Joe: But youre software guys. You should be used to that,shouldnt you?Eric: Youre right. That was the argument: wow, we should do itelectronically because were software guys. But I found thathaving a physical board is... Theres something about being ableto see it. Perhaps when we all have 60 inch flat screens on ourteam rooms and we have the software that makes it look like thatphysical board. That will be a good substitute. But right now,theres nothing I know of thats really at that level or economicalenough. Where you compare it to a physical board where peoplecan see it, its actually worth it to me for the double entry, I Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  17. 17. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsthink. Because we were writing on a card or we printed it out andpasted it up. Right now what Im doing is actually all electronic.Im not a big fan of that, let me tell you. I need something bigand visible for the team to see. Otherwise I think you lose a lot ofthat transparency.Software people will tell you, "Oh, were computer people. Weshould be able to use websites, wikis, whatever. That should behow we look at things." But its just not in your face all the time.The boards are in your face. When you get together in the teamroom, you see exactly where youre at. Electronically is a lot nicerfor historical reporting. But its not good at the team level whenyoure trying to stand up with the team and have them see wherethe teams at. Its just a lot better to have a physical board in myopinion.Joe: I think it was Dan Roam, whos the author of "Unfolding theNapkin." One of the things someone asked him one time; “Whatsoftware he used to create this presentation?” He said thatdawned upon him, because it was just stick men on the drawing.He said by making it humanistic it becomes human. I thoughtabout that for a while. I think having a Kanban board, having avisual board makes it humanistic. There are mistakes, there arethings up there that you need to work through. Whereas, whenits on a screen it kind of dehumanizes it and takes the issuesaway a little bit.Eric: Exactly, you cant do things like. I cant move the card tothe next queue. Im just changing a bit somewhere or a flagsomewhere in the software. I dont know. I also think there issomething satisfying when you get done as a developer oranybody on the team, and just moving onto that next queue.Joe: You have a 10 item to-do list, and you check that thingoff. You get down to the bottom, and want to check it off, that ispretty good. Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  18. 18. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsEric: Right. The other thing you will find on the physical board,at least this is what we did, if we ran into issues or something, wewould have a story on a card. Then we would put... Lets saysomething came up there, something was blocking it. We wererelying on somebody else, or whatever. We would take a post-it,a certain color of post-it, maybe it is red or something... Put it onthere, and at some point, you might have two or three of thosepost-its on the card. And it kind of takes on a life of its own, itsown kind of thing that people are familiar.So, if I glance up at that board I realize, I know what story thatis. It is a lot easier to track it, because know it has thischaracteristic that is different from the other ones, that idea ofphysical vs. electronic.Joe: A couple things that during the conversation you talkedabout that I would enjoy you qualifying a little bit for me. One ofthe arguments about Agile and Scrum, I think was it became tooteam orientated and didnt really focus on the customer enough,that it became real internalized. Is Kanban different?Eric: I would argue, yes. My experience is Kanban is veryfocused on what the value is for the customer. So, if you go fromwhat most people are using Kanban, the main marketablefeature, that should be coming from a customer, and it should beabout something that is value for the company, either it ismaking company money because it is a new feature, or it issaving them money or something, but there is some value in itfor the company. So, that is one way that Kanban helps. I thinkthe other way is it is very focused, it doesnt just stop with thedevelopment, start and stop with the development team. You canuse Kanban to really go from the marketing group that comes upwith the idea, so they could have their own board that feeds intothe development board, and at the end you have to interface withyour infrastructure people to make sure your server is setup. Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  19. 19. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsIt is really focused on the whole enterprise I believe, more sothan say, Agile. Agile kind of came out as a reaction to veryheavy-handed techniques, but it was very soft-ward of uppercentric. Whereas, I think Lean, coming from that manufacturingbackground, Kanban comes from that background, it is veryfocused on the enterprise as a whole, the entire organization andnot just IT.As you have said, you use these concepts in your marketing, andI just see there is a lot of benefit in all parts of the organizationfor a Kanban board or these Lean concepts, and they should justflow throughout the company. As I kind of mentioned on thatKanban board, we are looking for one-piece flow.Well, that elusive goal, one-piece flow, it really kind of starts withwhere ever your ideas from your features come from, and theapproval process that goes through to development, todeployment, to then the marketing of its feature.I mean, I think it is the whole kit and caboodle, and thenprobably how you take in your money and your accountingprocesses. I think there is a lot more capability in Kanban and inLean, ideas to bring a whole enterprise together. Whereas, Agilejust started at such a developer focus, it needs to add things on.I think with Lean, those tools are already there.So, that is really a nice part about using Kanban is we are alreadyusing Lean tools and businesses understand that. I think a lot ofthem do.Joe: I also look at Kanban, and you have had a lot moreexperience with it, and with the teams on that, but when you talkabout bottlenecks, and I mean we attribute that back to Theoryof Constraints. One of their arguments has really been is thathaving people idle is not bad. Kanban kind of says that to youtoo, doesnt it? Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  20. 20. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsEric: Yes, that whole idea of wanting work in process, if you runup against a constraint, you dont just go... Im a developer, andI also go back to this example... But if Im a developer, I finishmy story, its ready to go to QA, no matter what, normally. Whata developer will do is, just give it to QA and go on to the next.They dont care if the QA person had time or not, bandwidth ornot, to finish that. But now, with Kanban we say, "Well, wait aminute." If they dont have bandwidth, if their queue is full, youstop and you dont do anything until that queue is open. And thatmeans there might be some slack time. If you cant help them orwhatever, you might have some slack time and normally, somepeople get a little nervous around that, managers in particular.But the idea is use that slack time; you dont just sit around andsurf the net necessarily, you want to use that time to kind ofhone your skills, maybe use it go to a webinar. Do some of thosethings you dont normally do when youre developing to make youbetter and it kind of - you do get some idle time out that. So,youre right, its not discouraged to have idle time in Kanban, Iguess. It might be the way to put that.Joe: Now, theres been a lot of talk about cadence also and acertain rhythm to a Kanban. Have you seen that develop?Eric: Yes, yes. Thats when youre really, if youre not getting tocadence, you want to see why that is, because you should bedelivering on a regular schedule. Normally, what we do is wewould schedule meetings with stakeholders and we would showthem what was going out to release. So, in Scrum, you kind ofcommit to, in this fixed length iteration, were going to deliverthis, whereas in the Kanban, this is what were delivering andweve done it in this priority. And your cadence should be so thatthe amount of effort of what youre delivering is very similarevery time. And, if you see wide variations in that effort, then Iwould argue your cadence is not too good because you should be Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  21. 21. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsdelivering very consistent chunks of effort or whatever when youdeliver.For instance, we would say every two weeks, were going torelease our features to production and that was kind of ourcadence. It ended up that I think they moved that out a little bitof the team I was on. They moved that to three weeks or amonth where they were delivering every month because it turnedout customers were saying that was too fast. Youre deliveringtoo much and we cant handle all the new features because everytime you release something, we learn them and then it comesback.Joe: Thats a good problem to have. Is there anything youd liketo add to this conversation, Eric?Eric: Id just like to say, I really think, and it sounds like yourecoming from a Lean background and you would probablyunderstand this too, but Lean really, I mean, I really believe thatit really involves that whole enterprise and that whole continuousimprovement. There are a lot of tools there. So, I think thats justreally, really an outstanding way to go and I believe as Agilemethods mature, youre going to see a lot more integration withLean and with these Lean ideas becoming more and morecommonplace in software development.Joe: OK. I would like to thank you very much. Ive had adelightful conversation. You can find out more about Eric byreading his blog, Corporate Coder at Thispodcast is available on the Business901 blog site and also at theBusiness901 iTunes store.So, thank you, Eric.Eric: Thank you, Joe. Scrum + Kanban = Agile Discussion with Landes Copyright Business901
  22. 22. Business901 Podcast TranscriptionImplementing Lean Marketing Systems Joseph T. Dager Lean Six Sigma Black Belt Ph: 260-438-0411 Fax: 260-818-2022 Email: Web/Blog: Twitter: @business901 What others say: In the past 20 years, Joe and I have collaborated on many difficult issues. Joes ability to combine his expertise with "out of the box" thinking is unsurpassed. He has always deliveredquickly, cost effectively and with ingenuity. A brilliant mind that is always apleasure to work with." James R.Joe Dager is President of Business901, a progressive company providingdirection in areas such as Lean Marketing, Product Marketing, ProductLaunches and Re-Launches. As a Lean Six Sigma Black Belt,Business901 provides and implements marketing, project and performanceplanning methodologies in small businesses. The simplicity of a singleflexible model will create clarity for your staff and as a result betterexecution. My goal is to allow you spend your time on the need versus theplan.An example of how we may work: Business901 could start with aconsulting style utilizing an individual from your organization or a virtualassistance that is well versed in our principles. We have capabilities toplug virtually any marketing function into your process immediately. Asproficiencies develop, Business901 moves into a coach’s role supporting theprocess as needed. The goal of implementing a system is that the processeswill become a habit and not an event. Business901 Podcast Opportunity Expert Status Scrum + Kanban = Agile Discussion with Landes Copyright Business901