Troy Tuttle, KCP, is the owner and a principal consultant at KanFlow. He is a practicing Agile software developer and Lean-Agile-Kanban coach to software teams, project managers and executives. He helps software professionals and teams improve through approaches that support better clarity, understanding, and continuous learning. Troy is the founder of the Kansas City Limited WIP Society and is a regular speaker on topics of Lean, Agile, and Kanban. The foundation for Troy’s knowledge in software development is based on real-world successes and failures with software projects and Lean-Agile.
Download a PDF of the Transcription
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.
Related Podcast: Coaching Agile Software Teams
Transcription of the Podcast
Joe Dager: Welcome everyone. This is Joe Dager, the host of the Business 901 podcast. With me today is Troy Tuttle. He is a Lean-Agile coach, software developer mentor and a consultant with almost a decade of experience working in Lean-Agile environments. He currently operates KanFlow, a consulting firm dedicated to helping software professionals; teams and organizations improve by the study and the application of Lean and Agile principles and practices. Most of his work is directed by approaches that support better clarity, understanding and continuous learning about Lean-Agile and the nature of knowledge work itself. Thanks for joining me, Troy. Did I get everything in the introduction I should have?
Troy Tuttle: It was perfect, Joe. Thanks for having me on.
Joe: You think of all this cutting edge software stuff and we always think about this or either in Silicon Valley, out on the West Coast and East Coast but, you’re in somewhat America’s heartland. How do we find all the software stuff in Kansas City?
Troy: Well, it’s counterintuitive actually. You wouldn’t think from the location much about Kansas City but KC is an emerging tech and startup town and many people call it kind of the new Agile or Austin, Texas of the Midwest as far as technology. Many people are familiar with Google Fiber and Kansas City; Kansas was the very first Google Fiber neighborhood, and that’s jumpstarted a lot of tech investment in the area.
Joe: Wait, we were one of the first Fios cities, which helped us, develop I think some of our technology here, which is much more on limited basis, I would think, Kansas City.
Troy: Right.
Joe: Tell me a little bit about KanFlow. What are you up to and what does KanFlow do?
Troy: KanFlow is my consulting company for Lean and Agile coaching and training, and that’s mostly what I do with it. For the most part, I’m a one-horse show. I’m an independent coach, and most of my work is working with teams and organizations. I like to find ways to improve and most of that improvement is in how they approach Agile software development. One of the things I found is a good fit for me and the organization is an organization that’s been trying to do Agile and maybe they find that they’re a little bit stagnant at some point, or they’ve plateau to some degree. They desire kind of a fresh start or a new way to move forward and jumpstart that again, and that’s what I like to help organizations do.
Joe: I have to jump sideways on you a little here because you just brought something up that I think is interesting is Agile has been around for quite a long time now. And, when you ask anyone in a company, everybody is always Agile, okay. Have you worked with companies outside of software where we’re starting to see is how business practices or how business, the other business people actually talk to the developers and the software people? Are we co-mingling maybe Agile thinking within a company?
Troy: I don’t know that I’ve experienced that at a company that doesn’t work in technology or software to some degree or have an IT Department that works in it. So, most of the time I’ve observed that Agile-Lean expanding outside the traditional technology boundaries that we’ve come to think of where it typically has stopped in the past and, a little more of a cross-pollination across other disciplines within the company.
Joe: How would you maybe ask someone to talk to the Agile group? Is there a different language when you’re talking to that software development group and from regular business practices or the business guys you think of everything in, for lack of a better word, more than a waterfall or type project management and then they move from plan do to kind of envision-speculate when they get into Agile? I’m stealing some of Highsmith’s words there but how is that communication there? How is that structure, do people get it when they talk to software people?
Troy: Well, I kind of a little bit different approach to that where I would say speak the language of the business, right, whatever that language is or whatever business you’re in Speak the language of the business and it’s up to the Agile and Lean folks to adapt to that and that’s where they’re supposed to be good at, right, is bringing that delivery closer to the business need.
I think it’s less of a challenge to the business trying to understand how to speak to the Agile folks than it is having a healthy Agile implementation or approach that it tries to avoid having that gap to begin with. Where everybody’s a business person in that world, right, whether you’re a software developer or a tester, you know, or a graphic designer, we’re all in this business of whatever that business is and that’s more of the approach that I try to take.
Joe: When I looked at your company, KanFlow, okay, I assume you’re a Kanban, guy. Kanban is kind of an Agile discipline of Agile Project Management maybe or Agile, also Scrums evolved in that. So, are you a Kanban guy? Is that who you are?
Troy: Yes and no. The way we’re connected on social media is probably through more of the Lean and Kanban community than anything else, so I guess I’m known as kind of a Kanban guy. But, I don’t necessarily think that Kanban or any Agile approach or discipline has all the answers, right. One of the things I do in my practice is I believe in what I call a Lean-Agile hybrid approach and I’m not the first person that’s stated that, right, so I’m borrowing from a lot of different people. But, I believe that whether it’s Kanban or Scrum or XP, Extreme Programming, none of those in the year 2015 really have all the answers in my opinion and I would prefer teams and organizations to pull the most powerful bits from those different practices and knows that thinking in each of those areas together to form their own kind of hybrid approach.
In many things, I do lead with Lean and Kanban. If we had a whiteboard between us, I would draw up a set of Venn diagram circles, right. We have one circle that might be kind of a Lean and Kanban circle, another circle that might be, I guess, something we call a Scrum and then another circle that we’d have for maybe XP. Where those intersect is where I really think the juice is, right, in improvement. And, to give you a practical example of what I’m talking about, you could have a team or organization stand up in a series of Kanban teams, say Lean-Kanban teams but there’s really nothing in Kanban, especially the traditional literature of Kanban that says, ‘to do retrospectives’, for example for a team or even ‘stand-ups’ for a team, right, it’s not prescriptive.
Those are the things that I would like to pull from Scrum and say, you know, “These are the things, some of the best things that Scrum has to offer so let’s pull that into the mix.” Right and another example from the XP world is user stories. User stories originated from XP. A lot of people associate those with Scrum because they’re often used with Scrum, but they actually came from the XP world. And then, the software engineering practices obviously come from the XP world. So, I’d like to pull those types of things into the mix where appropriate.
Joe: One of the problems I think people have when they start with Kanban, or they start with some of the Agile methods is that they think they have to remove themselves from all these different traditional approaches, and one of them is maybe project scope. How do you start there with someone before you really filter down, do we still need some of that documentation upfront?
Troy: Yeah, that’s a good question. I’m going to give you kind of my Anderson’s Kanban, you know, David Anderson’s version of Kanban answer where really the context of that, of wherever you’re operating, whichever organization you’re operating and really kind of determines that and many organizations do have maybe traditional scoping documents, you know, project chartering and if that’s what you work with, then I say continue with that and then think about ways to improve those practices along the way. Right, so that it’s more of an evolutionary process of improvement.
One thing that I do like to introduce to organizations, outside usually when people say “Well, my team’s doing Kanban,” or “these teams are doing or Scrum or a hybrid of the two” that discussion stops at the boundary of the team. What happens in front of that team is kind of what you’re asking about right, like “We have a new product idea that we’d like to bring in the market. How do we manage that kind of work before the actual implementation team starts to dig into that?” I have two primary vehicles or mechanisms I like to use. One is a portfolio view; some people call them portfolio Kanban boards so that the organization has a view of everything they’re doing from a portfolio perspective. And then, along with that they have some kind of reoccurring meeting, you know, once a week where all those stakeholders that care about that view get together and make decisions around that in a visual way, so visual, using visual management.
Joe: Would that be the same kind of like a product roadmap you’re saying?
Troy: Well, it could be. I’m not real prescriptive about that thing. The key for me is two important things. Well, at least to a third, right, is no matter how you do it is it needs to be visual, and some people take that as “Well, we need to get that up in a physical thing.” And, if that’s what you need to do then that’s okay. If you’re not co-located, you might have to have a digital tool that facilitates that but the number one thing is to make a visual model of that product.
If it’s a roadmap or just a representation of where things are at, at this point at this company, right, is to have a visual model for people that make decisions to help them make decisions. Because, once you make that visual model, people have a much different understanding of where these different things are at and what we need to be focusing on then if it’s not visual. If you want to call that a roadmap or put it in more of a roadmap form, I’m okay with that.
A second thing is; an important thing at the company level is limiting WIP. I have yet to encounter an organization that isn’t doing trying to do too many things at one time, trying to do, you know, do more than they are able to do at a constraint level, right. And, having a conversation about WIP limits at a very high level so that those hard decisions about ‘do we do this or this’ happens sooner than later, instead of saying ‘Yeah, we’re going to do both of these things’ and continuing to struggle with too much work in progress.
Joe: I think that’s a great suggestion. Of all the interviews I’ve done and all the people that have had whether it’s been healthcare or manufacturing or software, all the people that have ended up writing books, about how well they did and what fabulous Lean transformation they had, every one of them have always commented that they wish they would have tried to do less. That is an amazing statement to make, and that’s what you’re saying is to get that up there at the highest level, right, and start limiting WIP right out of the game.
Troy: Do fewer things better and most of the time our customers are going to be better off for that because we’re going to have a higher standard of quality at that point. That’s a hard thing right? We sat there and talked about that for two minutes and that’s something that organizations try to do over years, you know, months and years and have a hard time getting their head around doing fewer things at one time will have many, many other improvements. You’ll actually get more done, you have better quality and a better work environment for the people working.
Joe: I always use the analogy, I think, with Apple because you can name every Apple product, and you can put all the Apple products on a kitchen table. I bet you they’ve said no to a lot of things.
Troy: Yes and they’re the largest company in the world right now, right. So, that would be a great visual wouldn’t it, to put all those products on one table and ask the question, “How many times has Apple said no to something to make this work?”
Joe: You had a third one, okay. I get caught up in what you’re talking about there, so.
Troy: Yes, so the other mechanism, so the first, like I mentioned is summarized, is to visualize at a portfolio view for the stakeholders so that those decisions could be made in a visual way and shared understanding.
The other thing, it’s a little bit closer to the teamwork which goes to your scoping question is the practice of story mapping and I’m a huge proponent of Jeff Patton’s style of story mapping and, you know, if your listeners are curious they can look that up, Google story mapping and it’s going to be a better explanation than I can do verbally because it’s a very visual thing, so it’s hard to explain what story mapping is. But, effectively it allows us to apply a Lean filter to how we approach our work and to approach our work with more of a ‘just in time’ fashion as far as getting into the details, right. We can map out our entire product or product offering at a high level and then order that in importance or return on investment or whatever measurement you want to go by. And, only the very top items or the first items do we dig into the details and the things that are further down on the map, we don’t worry about those details because it may never come to fruition. It often doesn’t by the time we get to our first release or our first MVP, minimal viable product.
Joe: I think that is a good way of saying it, and I’ll go back to I’m a big fan of Highsmith, okay, and his Agile Project Management philosophy that he’s written. I quote him a lot, but he said initially he didn’t like user stories. But, he came to really appreciate them, use them because it changed people’s perception of planning, and it got them from thinking about, that plan-do that I talk about and into more of a speculating than a planning type of fact. We’re not prescribing the future, but we’re really, opens up the horizon. Now, do you agree with that analogy or is that kind of how you look at it in using user stories?
Troy: I do. On a couple of different levels or approaches. One, for the Lean Heads in the audience, what I find from user stories are they’re the best vehicle for reducing Batch size. If you need to reduce Batch size, really the only requirement that is truly sliceable and still deliverable, right, you can reduce the Batch size tremendously by working the smaller user stories and still have something that’s deliverable for the customer. Most other requirement forms like used cases and traditional functional specification documents aren’t reducible like that. That’s a real important aspect from the Lean side.
But, from the perception side like you said, the mindset of ‘we don’t really know in knowledge work where we’re going until we’ve gotten there until we have arrived, right. That’s actually something I use in my training material. I talk about; I really spend some time talking about the nature of knowledge work itself. Knowledge work is more non-deterministic than it is deterministic, and that’s what Highsmith is speaking to, right.
It is a little experiment I do with the class and say, ask the people in the class, “How many, has anybody worked on a project of a non-trivial size, maybe larger than three months? Most of the time I get almost everybody to raise their hand and I have them leave their hand up if by the time you got into that project it was exactly as what you planned at the beginning and I never ever get a hand up, right. That’s an illustration that the work that we do and knowledge work is non-deterministic. We don’t know exactly the steps that we’re going to take to get to the finish line. Those things have to be discovered as we go.
Joe: When I think of a user story too, I think of it like, we’re out there to discover and a narrative gets us in that mode, in that thinking mode versus ‘I got to follow these requirements and this prescription’. I think that has a tendency for disaster because that means we’re not capturing the knowledge that we learned along the way.
Troy: Right, and like I mentioned earlier, because we can reduce their batch sizes right or reduce the size of user stories quite effectively, the output of one user story is very easily rolled into, that knowledge can roll into the generation and clarification of the next series of stories really easily because they’re very light weight, right. As you know, and most of the audience members know, the original user stories were written on index cards for a reason so that you don’t get that involved too early in the process.
Joe: I see a lot of people, when they first get into user stories and try to do a narrative that it’s a half a page long, okay, and you’re really saying that you need to split that at the very beginning and leave it, back off from it and maybe take a higher view of it if it’s half a page long.
Troy: That’s where to go back to my story mapping, Jeff Patton’s style of story mapping, that’s why I like that approach so much. Early in the process from a practical standpoint, I recommend that teams only write down story titles. Maybe the stories themselves just the actual sentence and nothing else and you create a map out of multiple stories and then the map is going to inform you on which stories do we get the details about first and at that point we can start digging into the details and worrying about the acceptance criteria. Only when we realize that “Yes, this is the first three stories that we need to do for this product.” Right and not to worry about stories number 35, 36 and 37, those can just be titles, just something on a card, on a wall at that point in time.
Joe: Yes to know that you need to address this at some point.
Troy: At some point later, right, so we need to achieve some form of ‘just in time processing’ right, a ‘just in time approach’ to elicit details. And, because if we elicit details too early in that process, that’s inventory. Just like inventories bad and manufacturing inventory and knowledge work is even worse because it’s invisible, right, we can’t even see it. Many times we don’t even know how much inventory we have so we really have to guard against generating and building up inventory in a knowledge work process.
Joe: I heard Jim Benson say one time, and I don’t know where he got it from, okay, but you know ‘the last responsible moment’. When do you really schedule something to do?
Troy: that’s an old Agile saying, right, ‘the last responsible moment’, right, and that varies based on the context of the organization, but the principle still holds, right. That most of the time, most organizations that are either haven’t done Agile yet or are really in their Agile process or adoption are still not very good at last responsible moment. That’s a hard thing to get.
Joe: What is limiting about this type of approach? I sit there and think about it, does it take a certain amount of maturity? Can all of us be agile in our thinking or what’s limiting? How do I get there to start doing this?
Troy: Oh, that’s a big one. We’ll start with one, and then you can steer me back on track. It’s low prescription, right, and that requires one to think, right. Compared to like a process of more of following a recipe, right, and so it does take maturity. Although, I don’t know that that should scare people from trying it, right. I think all Agile methods require more maturity than traditional methods because you have to think your way through that process.
But, that’s one thing that Lean and Kanban, I think, brought to the Agile movement and community is a little bit different approach to it, right. More thinking your way through your process, more about finding your process than following a process or following a recipe, right, create your own recipe versus following a recipe which is more of the kind of first generation approach to Agile is do these things in this order and do these ceremonies in this order and you’ll be successful. But, the danger of that is we, you know, that we have a danger getting into cargo cult agile. And, I don’t know if you want to go down that path or not but if we can define what cargo cult agile is.
Joe: Define that real quick.
Troy: Cargo cult agile is just a reference to cargo cults which were born out of post-World War II, the Pacific islands where the island hopping part of World War II between the United States and Japan had a lot of military people in contact with indigenous people of those islands and years later, decades later there were indigenous people that continued to do the practices of the military operations which were landing planes and organizing supplies and that type of thing because they wanted to get those cargo planes to land and bring in supplies like chocolate bars and canned goods that they’ve never been exposed to and they could trade with the military personnel for those types of things.
The cult part of it is they went out and tried to flag in, waved the flags around on the runway and built model airplanes out of organic materials to try to reproduce that. They tried to reproduce those goods by just doing the things, following the recipe of the people they observed doing it. The lesson is like for agile that we don’t really become agile by just following a recipe, by doing the things that we’ve seen other people do, right.
So, this team goes over here and does the standup every day for 15 minutes. I’m going to have my team do that every day, and we’re going to be agile and that it doesn’t work that way, right. We have to think our way through this process. We really have to create our own Agile recipe to be successful.
Joe: I think that goes back to the people that try Lean so many times and to be like Toyota will just copy what Toyota does. “When you stop calling it Lean and call it your own is when you successful with Lean.”
Troy: I think the determining factor, the delineation is ‘do you understand why we do these things’, right, once you understand why we do these things then you have a chance. If you don’t understand why we’re doing these things, why do we, have standups, why do we limit WIP, why do we visualize our work, why do we have retrospectives in Agile teams. Once you understand why we do that, then you have a chance at creating your own recipe from that. But, if you don’t then I think, you’ll probably realize some benefit by following that recipe but it won’t be nearly the game that you could get by truly understanding why and thinking your own way through your process.
Joe: I have to ask you about a topic you’ve been working on. It’s an MVP type thing, okay, but it’s a Minimally Viable Agile. I guess that’d be MVA. What is that about?
Troy: Well, I’m still figuring it out at this point. I’m working on this to do some talks on MVA, Minimally Viable Agile, and so far, you know, what I’ve come up with is a framework or the start of a framework to have a better understanding of why. You know, we were talking about why we do certain things in Agile or Lean software and I believe that based on my experience in observations of teams that you can do less of what’s prescribed traditionally in Agile software and still gain some agility, right, and become agile yourself.
I’ll give you, if you’d like a story I’ll give you a story from my early agile years of something like this happening in my team and I because we weren’t thinking about being minimally viable and agile. We went on doing something that probably wasn’t necessary.
The story is like this. So, for people that are familiar with sprint planning, right, our team was doing sprint planning. We were practicing pretty much standard Scrum approach, and we were sprint planning and we’re going through planning poker, right. We’re turning up cards and planning poker. You would have the Fibonacci number sequence of like a zero, one, two, three, five, eight, thirteen, twenty and so on, relative sizing of stories for our next iteration and we’re progressing through this, you know, for maybe an hour or so and one of the developers on the team, a really quiet person spoke up and said, “You know, why don’t we just save ourselves all of this time in this planning process and call everyone a five and move on and start doing the work because if we just average out all these estimates that we’re doing they all equal a five, right, and we could better spend our time actually building these stories instead of discussing whether they’re a three, a five or an eight or a two or a thirteen when the average is five.”
At that point, we all kind of chuckled nervously and thought well that’s kind of cute but, you know, we’re supposed to do this process because that’s part of the recipe. So, we went on doing that planning process. But, that was an early, it has its roots in what many people in the community recognize now as the no estimates conversation where we could find different ways to go about planning our work beyond traditional estimation process but it’s also something that if we were thinking about being minimally viable and agile, we, as a team, we should have stopped and said, “Is this ceremony or this particular practice useful at this point or could we do our work without it?” Asking that question, I think, for me is kind of the next horizon in agile and lean is what is truly necessary to be agile and do all the prescribed ceremonies and practices of the last 10 to 15 years, are all of them necessary based on what we know in the year 2015 and beyond.
Joe: Things change so quickly now and as you’re saying, even when we go back to that user story development, that when we get to the end of a project, there’s so much more we’ve learned and there’re so many other things that we may have discarded during that whole process that it’s really about doing the minimum over what is on the plate at that time, right?
Troy: Right, this goes into kind of traditional project management. So much of the ceremony around are team-based methods, is about the team and not necessarily about the customer. Right and if we apply that lens to our practices, now, I’m not saying abandon everything that the team finds useful that maybe the customer wouldn’t find, wouldn’t care about but if we apply that lens to the things that we do, we can start eliminating many things or maybe greatly modifying many of our practices to make sure that they’re really something that is benefiting the customer, not just benefiting the team.
Many times, I don’t know that they’re even benefiting the team, they’re just something we’re doing because we prescribed that. It’s an arbitrary, right, it’s an arbitrary construct that doesn’t always have the customer in mind, and we can apply that to estimation. We can apply that to even sprints, right, sprint boundaries. That’s kind of what the Lean and Kanban community brought to the conversation is ‘do we have to do traditional sprint planning and run traditional Scrum sprints or could we do other things and drop those kinds of things or modify them or only do parts of those practices’. That’s what I think is incredibly interesting in one of the communities going at this point.
Joe: What’s upcoming for Troy Tuttle?
Troy: More of the same and I’m actually working on bringing a Lean-Agile conference to the local Kansas City metro area and region. So, that’s consuming a good portion of my time at this point.
Joe: It’s always amazing how much time side projects can take up.
Troy: And, it might be more than I bargained for but, I will give it a go. We’ll see how it goes.
Joe: That sounds pretty exciting. What’s the best way for someone to contact you?
Troy: So, the best way would be either through my website, KanFlow.com or Twitter, which is @TroyTuttle is my Twitter handle.
Joe: Okay, well, I’d like to thank you very much, Troy. I appreciate the conversation and your input on Agile. I think it’s maybe, you know, we can call it a Midwestern influence, but sometimes both coasts need a Midwestern influence.
Troy: That’s right. I’ll see what I can do to help. Thanks, Joe.
Lean Sales and Marketing: Learn about using CAP-Do