Bio James Shore is the author of the Art of Agile Development book and Gordon Pask Award winner. Arlo Belshee well known for the ideas of naked planning and promiscuous pairing, and also a Gordon Pask Award winner.
Lean Software and Systems Conference 2010 — the place to learn about Lean, Pull Systems and Kanban. Understand how established industrial engineering theory can apply to software development process. The conference will assist organizations that depend on software – from start-ups to those that build complex, software intensive products, systems & services – with the application of Lean Thinking throughout the enterprise.
1. I’m here with James Shore, author of the Art of Agile Development book and Gordon Pask Award winner, as well as Arlo Belshee well known for the ideas of naked planning and promiscuous pairing, also a Gordon Pask Award winner. Guys, thanks for joining us. It’s well known that you guys have some interest in approaches recently published about your ideas about Kanban. I was hoping you could talk about that a little bit.
Arlo Belshee: The naked planning approach, which is my approach to Kanban, really focuses on identifying what it is that it’s the value out of a planning practice and eliminate everything else. In particular identify the lies and the things that allow us to lie ourselves - I mean eliminate all of those. The result is something that really does a good job of limiting work in progress.
The general process is that work is either being worked on, in which case we need some way to communicate and describe amongst ourselves and share all the information that’s necessary. Or work is done, in which case there is not really anything more that we have to do about it; maybe demo to somebody, but it’s already been shipped to the customers (otherwise it would still be worked on).
Or work is not started yet. Planning is about organizing the work that’s not started yet and making sure that we can work on it. We only need to do the absolute minimum necessary to provide that. The naked planning approach - we have a short queue. The total estimation is at the bottom of the queue; you say "Your wait time from here is approximately (and you round it off) a month and a half". You just take the top thing off the queue, start working on it.
When you're done with it you take the top next thing off the queue and at any time anyone who has rights (which is everybody) to change the plan can scramble the current order of things in the queue.
James Shore: Naked planning is a Kanban style technique, although when you created it Kanban was just barely getting started, so I'm pretty sure you did it independently. When people think about Kanban, they often think about these work in progress boards that show swim lanes and you have cards you need to the link showing you how the work is moving through. I think unfortunately a lot of that has focused on reflecting a sort of traditional waterfall phase-based approach. Of course, it's not waterfall if you are doing it in very small pieces, it's spiral, it's iterative, but it's still phase-based.
First we analyze, we design, we code, we test we deploy and until we deploy it's not done; we got all these other things that we do. The naked planning approach is really substantially different because it's based on extreme programming. Extreme programming uses simultaneous phases, which means that we can honestly say we either haven't started or we're doing all of those things, all at once truly simultaneously, not just different people doing parts of them, but using one activity to do multiple of these things at the same time.
Arlo Belshee: For example, we'll be sitting there and I'll say "We need to add in this capability that the customer asked for. I think they wanted to be green in this case. How are we going to test that?" And he'll say "We need a little in direction here to inject the test. We just did requirements gathering, design and testing, we haven't written any code yet." - in two sentences.
James Shore: Or if not requirements gathering then requirements fleshing-out. Actually, at that environment if we didn't already know, we could actually ask "Is that green or is that light-green or is it puce?" or whatever.
2. One of the things that's interesting about what you are describing is it sounds like there is a distinction between one queue of work that's to be done and another primary queue of work that's in progress. About that first queue, work that's to be done and not yet in progress, I assume what you are saying is that there is not a large degree of projection involved in that as to what or when that work is going to be completed. Would you say that's accurate?
Arlo Belshee: Identify what the minimum necessary is for the business domain - and then do that. A lot of times when I talk to a VP of Marketing or VP of Sales (a little less with the sales guy, but especially with the marketing guy), we talk about "What do you need?" He says "I have a trade show on October 12. I need to tell people what's going to be there."
At that point many engineers stop and go "OK, we got to figure out what we can do by October 12 and this matters." Ask the next question "How much do you need to tell the people to get them to the booth?" and they'll say "Well, I only have space in my marketing material for 3 bullet points each of which is 4 words long.
James Shore: That’s fairly easy to do.
Arlo Belshee: Yes. I can do that! I can guarantee you 12 words.
James Shore: Especially since we can manage scope. We can say "We're going to hit these 3 bullet points and we're either going to do it with bells on or we're going to do it in another way."
Arlo Belshee: If we have a lot of extra time we might also do a couple of other bullet points that you can, after you've got them there, give them some wild surprises. Or we might not. But in any case we've met his minimum requirement and I didn't do any analysis to do that.
James Shore: I think we should talk a little bit about what's in these queues. I think it's important. These are not just tasks or stories, these are minimum marketable features. We don't entirely agree on what that means.
Arlo Belshee: I look at it from more of an information theory perspective and he looks at it from what actually matters to company.
James Shore: Arlo likes to think about learning and I like to think about cash.
Arlo Belshee: My perspective is I look at the domain in which we are working as software people as having 2 aspects: there is the problem domain and there is the solution domain (we have problems space and solutions space). A lot of the thinking that's going on is going back and forth between problem space and solution space, trying to break things down into small vertical sections in the problem space not just in the solution space, like people often do, going back and forth. My perspective of an MMF is it's the smallest vision I can make in the problem space. That's what the marketing guys care about.
James Shore: That was incredibly academic. Let me rephrase that. I want the MMFs to be the smallest thing that adds value in the market - so, to simplify the smallest thing that you can sell, which is actually Arlo's phrasing.
Arlo Belshee: It was my phrasing from way back when I had to change it.
James Shore: You were good then. I don't know what happened.
Arlo Belshee: I made it smaller.
James Shore: I think that's where I disagree. I think you make it too small to be useful. The idea of the MMF - we're working on one of these things at a time. It's hard to show. We've got this "to-do" queue and then to the right of that we have the stuff we're working on, which is a detective's blackboard, which we'll talk about separately. We also have the vision and maybe some mind maps and so forth. What we're working on, when we get it done, we could switch to something completely different and we want that investment of time and energy and money to have been worthwhile.
Which means that when it's done it has to have had some value, not just value to the customer, but market value, a value that's going to make a difference. Value to the customer is market value in a lot of ways. It's positive word of mouth, it's marketing, it's customer satisfaction. If that's what it is, that's an MMF. But, if for some reason, it's valuable to customers but they're never going to use it, they're never going to pay for it or it's never going to cause them to continue to pay their monthly service fee, then it wasn't worth doing on its own.
We have to do something else. I think that this MMF needs to be something that's worth doing on its own. That's really the key for me about the MMF. It's something that's worth doing on its own that the investment was worthwhile. The simple way of saying that is "the smallest thing we can sell". But it does need to be phrased in problem space. That is it needs to be about the result, the business problem, not about how we're going to achieve that result. You used an example from your current company about that; do you remember that example?
Arlo Belshee: Yes. We've got an MMF that's on the board right now that is we need to present 3 iterations of what a feature will look like, as we're going through the process. So that with our first meeting with the customer we can show them what vertical slicing looks like and get the conversation go in the right way. Our value of it is that it's going to help us shape the way we get feedback from those customers, the frequency of feedback and change the way that discussion works.
James Shore: Is this an external customer?
Arlo Belshee: Yes, that's an external customer, it’s actually a doctor, a physician we teach them how we do this.
James Shore: That sounds like MMF to me because that does something to add value in the market, gets its involvement.
James Shore: It might not be dollars. There is an example of the team I'm working with in Seattle right now. We went through and we brainstormed all these features and I just started working with them a couple of days ago. They brainstormed everything. We looked at that and over night we decided that none of that were minimum marketable features. The real minimum marketable feature for this company is that on April 30th they are going to demonstrate their progress to a major client.
If they don't have any new progress to show, that client could decide to retract their acceptance of the proposal that's worth millions. So, our minimum marketable feature is not about this feature or that feature, it's just simply show progress. Show progress in a way that they care about, which is implied on the card. The card says "Show progress to X customer". That's wonderfully focusing. We know exactly what we want to do we know what we don't need to do. We don't need to make maintainable code. We don't need to do a lot of things. We just need to show progress so we can seal the steel.
Arlo Belshee: Another example - we're choosing some of the abnormal MMFs, because there are of course all the normal ones as well. Another one that we had a few months back doing a new product launch, and the executives in the company didn't have a really good idea of risk analysis or even how to do a market analysis or any of that sort of stuff.
We had several MMFs on the board for the software group that were getting together, with risk analysis information doing some risk analysis, doing some marketing analysis and stuff. For none of those MMFs did we write a single line of code. For none of those did we do anything that's "software job"; we were doing other people's jobs because we happened to have the expertise to do it, and needed it to get it done.
James Shore: Although in fairness (this might muddy the waters a little bit), they were really upset that you weren't writing software. They thought you were overstepping your boundary until they saw the results.
Arlo Belshee: Then suddenly the discussions in the whole company changed.
Arlo Belshee: Certainly.
James Shore: Pieces of it.
Arlo Belshee: OK, but I would say that that was a case where we identified that the thing that the system needed was a risk analysis and there was no one in the organization that was perfectly equipped to deal with that. We had the most capacity for identifying that need and willingness to take it on, so we took it on. In that sense, it is a place where our small group did what was right for the system as a whole, sort of. As he alluded to before, other people in the system like the CEO felt that we were overstepping our bounds and not getting done our jobs.
James Shore: I happen to know about this company and it's kind of a special case because the company as a whole has not really embraced Lean thinking. Lean is a whole system approach. It is an approach where we are trying to see the best value for the organization, the lowest cost for the organization, not just the best software development, because software development that isn't in the service of the organization's goals is irrelevant. Actually I do a lot of software transition, Agile transition for people - that's my business.
I help them transition and I do it by going into the company for 3-6 months at a time. I really go in and get to know them. It's really common when we start out, those folks that hire me, once they sign my checks, they don't really think their life is going to change at all. Sometimes they realize that it is going to change and get excited about the possibilities because they see the value of the systems thinking, as with the folks I'm working with now and sometimes they don't as more of this was the case there.
Arlo Belshee: This did actually had some transformative effect on the conversations that those people are now having with each other in our absence. They are now doing a little more of the systems level thinking.
6. You made reference to doing work that’s in line with the company's goals. From a practical sense, especially in relation with your Kanban system, how do you establish and maintain and align those goals?
James Shore: I think it all ties together. We've got this idea of Kanban board - visual planning, visual management. You get to see what's going on. One column is the MMFs. We've got what we're working on, as that finishes we take the next MMF. When we’ve got a space there, we need to make a new MMF and where does that come from? That comes from a big picture idea that originally I used to just do a vision. That's a one page statement, 3 paragraphs or so.
From a strategic perspective, what are we doing? What is it that most valuable thing that we can be spending our time on, because software development is not cheap and certainly is certainly not low risk? How will we know we got there? (what Joshua Kerievsky calls management tests) And also not just how did we know we made it, but how do we know we're on the right track is another thing I tend to look at. That's the vision - a piece of it.
Arlo has recently invented, 5 days ago, an intermediate piece which has a lot of promise that I'd like to explore further. Why don't you explain that?
Arlo Belshee: I will play with it and see how it turns out over the next year. I also want to say one more thing about the vision, which is at this company that we're talking about, the executive team, the leadership team isn't really able focus in vision on one idea.
James Shore: They have really good high level vision, but it's not specific enough. There are things like improve processing time for business.
Arlo Belshee: But even then, they want to allocate 30% of their budget to that and 40% to a new line of business, 25% to another thing. We actually have an investment portfolio; this is currently working on, at the vision level.
James Shore: It doesn’t' give a lot of guidance. You got to come up with the next MMF to work on. The next thing that's actually going to be valuable on the market, what's it going to be?
Arlo Belshee: That's where the product planning comes in place. Between vision and Jim (the MMF column) currently we're doing mind maps. The center of each mind map is one product or service that the company delivers, in this case processing or whatever else. Then coming out from that is whatever is appropriate. These were made by discussions among everyone who's got a stake or an interest or any information or knowledge.
In fact, when we have those physicians on site who work for one of the customers of ours, then they're going to be doodling on those mind maps as well. Those mind maps will talk about parts of the system (parts of the system are important) future parts of the system, open problems, all sorts of things, all the information that's in our product line.
Then we just do a dotted circle around parts of it where we want to set a goal and the goal is just everything that's in that circle. We put date on it.
Arlo Belshee: The vision is the primary objectives and direction the company is going in. Most of what's on those mind maps will end up being related to the vision in some way. Because we could draw all sorts of things about the product, but we're going to draw the ones that are relevant.
James Shore: In this particular company the vision is sort of a broad statement of what the software team is about. It's an internal team that is just constantly developing software that's used in house. So, it's not a product centric company. That's probably why they don't have a very specific vision.
Arlo Belshee: The company's got 4 different services that they deliver and the 5th one that they're adding. We're sort of supporting the infrastructure tool that's used for all of those.
James Shore: The vision says "Do those 5 things." In a product oriented company like the one I'm working with in Seattle, it's much more specific. It's about "capture this part", it's about "meet this regulatory demand, so we can see this number of customers come in". It's very much more about product and it's got a lot more specificity to it. I don't know if we'll need the mind maps, although I'm going to try it anyway.
Arlo Belshee: In either case, the mind maps will need to elaborate on them, you fill out the information. Those goals you then define and it's much like you are trying to create an MMF off of these goals. You pick the goals that are most in line with the next vision objective.
James Shore: One thing I think we should make sure we're clear on here is that the team includes not just programmers and testers and all the technical expertise, it has to include business expertise. For the team Arlo is working with we grew our own product manager because nobody who had that capability was willing to participate. For the group I'm working with in Seattle, I actually have 4 product managers that are part of this team, because this is the lifeblood of the organization, it's a very valuable product.
Without this product the company would not exist. With so many product managers on the team, what they are using is the MMF cards. They move them around and talk about them and use that as their boundary object, it's their physical representations of what's in their heads.
Arlo Belshee: We were keeping the product bubbles specifically not MMFs, bigger than MMFs, so that when we have an opening in the queue, you go look at one of the bubbles that's inside one of the dotted goals and you shave off a little bit and that becomes an MMF.
James Shore: My approach to MMFs I think it's inherently a little larger than your approach. I want to try this mind map idea, but I wonder how much of a difference that creates between our 2 approaches as far as the need for something like that is concerned.
Arlo Belshee: We're also finding that the mind map includes mostly things in the problem space, but there are some ideas that customers have. Often a customer will say "I need this" and you have to talk to them for a while to figure out what the problem is and why they want it. The "I need this" needs to go upon the board as well.
Those are up in the mind map, even though we then don't honor them when we get to MMF creation, when we actually start an MMF. We will consider that as one of the many ideas. When we write the MMF, it's not on the card of the MMF anywhere because we're not constraining the solution space, we're just trying to define the problem.
9. A lot of what you've been discussing falls into what I'll summarize as the work that we have yet to do, that side of the queue. Could you talk a little bit about your approach to what it looks like when we take the work into the end progress?
James Shore: There are 2 pieces to this. Which one would you like to talk about first? There is the detective blackboard idea, which is how we visualize the work, but then there is also the notion of how do we make it possible to do this all at once in one phase.
Arlo Belshee: This is all about communicating and collaborating as we're working. Detective's blackboard is much like you see in a crime drama where they have the big thing on the wall with the string connecting various pieces of paper and so on. You get forensics’ evidence and it goes up there right next to the baggy that contains the bullet and all that stuff. We did the same sort of thing.
The blackboard holds all the information about whatever it is the team is working on right now, anything that's relevant and stuff is arranged and spaced in ways that make sense to the team right now.
Some of the things on the blackboard might be tasks, some of them work queue, some of them might be little spikes, some of them might just be open questions to someone who knows the answers of these. Some of them might be a rough sketch or an illustrated file of the UI.
We had Bluetech at one point, the statistics of calls coming in to the customer support center, because we were trying to work on stuff that would reduce our call volume. They can be just about anything - whatever is relevant. Then they get organized in various ways. You'll come in in the morning and things are clustered by the design of the code. We've got all the cards laid out in the class diagram; you can pretty much see that on the board.
We worked forth a little that way and we decided actually we've got something here that there is some value, so we want to do a deploy. Since we're going to go to a deploy, let's re-scramble this board so that it identifies the parts that we're going to push to deploy and the parts we're not. Now we have this thing that can easily help us work towards what's necessary to get the deployment out by 2 this afternoon.
Now that we got the deployment out, we're good, but because we broke it out this certain way, we saw a couple of new concepts, so we're going to put in new concept clusters and then talk with the customer to see what the missing one is there. Tomorrow morning we find a threading bug and take all of the cards and we organize them in the synchronization diagram to start identifying what are the things that are running in parallel with what - where’s our deadlocking happening. Stuff moves.
James Shore: Yes, it's very dynamic. As you were describing that, what it made me think of is this is the team's external brain. I don't remember who introduced me this idea, it may have been Brian Merrick, but there is this concept called the boundary object that I've referred to briefly earlier.
Whenever you are having communication between multiple people it's helpful to have a boundary object, which is basically how you get 2 people to understand what each is talking about - this is shared representation. Even if your language and my language are not exactly the same, we can use this boundary object to communicate. This to me, the detective's blackboard sounds like a boundary object.
Arlo Belshee: It's a very dynamic boundary object.
James Shore: Things come off of it and go on to it and so forth. When the MMF is done, what next?
Arlo Belshee: As stuff goes along, you find that the amount of information on the board grows. It starts completely empty because we don't break down or look into any MMF until we actually start working on it, we don't need to estimate. Then information starts coming in and we find the amount of stuff on the board grows.
Over time, eventually, the amount reaches a stable state and then starts to collapse, there is less and less information as every hour goes by. That's when we know we're about half or 2/3 done with the MMF. At that point that's when we do our first serious demos to test if there is everything complete.
The first couple create new flurries of information and then after that we start getting less and less. The thing is done when everything related to it has been done - the customer service has been trained, the thing is part of the automated deploy, it's either already out or it will be out automatically the next time the button gets pushed, it's fully polished, everything is solid. At that point, there is really not a lot of value to what's left, because we've gotten rid of any information that was relevant. There is nothing relevant any more down to the MMF card, which is done.
James Shore: So you take it off the board.
Arlo Belshee: You take it off the board, tear it in half. I tear them in half.
James Shore: I like to archive all the cards and toss them in a drawer.
James Shore: Why do you need a "done" column?
Arlo Belshee: You do need a celebration. Celebrating is important and celebrating is not within the team. You need to have a celebration outside the team, too. A done column will never be a celebration. What you need is some demos. You need people to actually come and play with the software.
At Bluetech we did trade shows and actually we're going to start doing those at the current company too. You get together once a month and the dev team sets up little booths where we show off as a trade show internally. Actually at the current company we're going to even bring in some physicians and have an actual "monthly trade show" with our customers where they can see the cool new stuff.
James Shore: We used to do weekly demos and that just wasn't enough interesting new stuff every week to get people excited about it, so it sounds like a better way. You need that human element; you need to have something to get excited about, a little ceremony.
Arlo Belshee: It's what builds trust.
James Shore: It builds trust and people want to be proud of their work.
Arlo Belshee: That is a weakness of the continuous flow planning stuff. With iterations you make a promise, you deliver on the promise, you should do it again. But continuous flow is a little fuzzier, so you need to celebrate or something to help you do that.
12. It seems to me with the nature of the work being so dynamic and the lack of concrete upfront planning you have with iterations that there has to be some kind of structure in place to make sure that the information is passed and that the structure of your teams facilitates that.
James Shore: This is my favorite topic. Arlo is all about the learning, I'm all about having teams work together well. One of the things that happens is that people think that the cards and everything else is how you communicate, but it's not. It's not how you communicate. It may be a boundary object, it may be a facilitation for communication, but the communication itself has to happen through conversation. That's the way human communicate best.
For this approach to be successful, in my opinion, you really need to have everybody together in the same room. This is actually what our presentation today here at the Lean Software Systems Conference was about. It was about the fact that we got this idea in Lean called the workcell. This is sort of a fundamental Lean concept that we haven't approached, we haven't tried in software yet.
Arlo Belshee: It's completely missing from Lean's software stuff.
James Shore: I think this is a real innovation that we have something that's very much like a workcell and that is the cross functional collocated team. A team that works on one thing. That cross functional collocated team, that team with everybody in the same room, open workspace, everybody could see what everybody else is doing and they hear each other and everything else, that is how they stay up-to-date.
And that's what allows us to eliminate all this work in process, all these queues and just have "Not started", "Going" and nothing else.
Arlo Belshee: Often, when people describe a planning process, it seems like it's prescriptive. What we'll do is put this planning of process in place and that will limit our work in progress and will get this value out of it and the like. What happens if you just do that is it works for a little while, it is better than no planning process at all, which is what most people have, what they actually have.
However, over the course of a couple of years, they build up all the engineering problems and code debt or distrust or other things that end up killing the efforts. The collocated team and that sort of perspective what we're really talking about is you need to get right production.
Once you can produce and produce as in innovate, not just come up with more features but pick exactly the right features; innovate like hell, one you can do that, then you have a lot of freedom to plan in a much more lightweight fashion and now you can use some of the other techniques. If you just try and use them without the innovative cell you're going to hell.
James Shore: Arlo has yet to start a blog so let us mark this opportunity. I have a blog; it's http://jamesshore.com. I write about whatever interests me, which tends to be whatever is pushing my button. I'm putting my book up online.
The Art of Agile Development is going up online. All these chapters are going out for free once every Friday. If your viewers are interested, they can take a look at that. I've tweeted more than twice about many inconsequential things which would be at James Shore on Twitter.
James Shore: Thank you.