I have to ask you about a topic you’ve been working on. It’s an MVP type thing, but it’s called a Minimally Viable Agile. I guess that would be MVA. What is that about?
This is an excerpt from Next Weeks Podcast
Troy Tuttle: I’m working on this to do some talks on MVA, Minimally Viable Agile, and so far, what I’ve come up with is a framework or the start of a framework to have a better understanding of why. 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 a story from my early agile years of something like this happening o my team. 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. For people that are familiar with sprint planning, our team was doing sprint planning. We were practicing pretty much standard Scrum approach, and we were sprint planning and going through planning poker. We’re turning up cards. 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, for maybe an hour or so. One of the developers on the team, a really quiet person spoke up and said, “Why don’t we just save ourselves all of this time on this planning process and call everyone a five and move on and start doing the work. 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, we’re supposed to do this process because that’s part of the recipe. We went on doing that planning process. It has its roots in what many people in the community recognize now as the no estimates conversation, right, 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. Aas 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?” Right, and 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, because, 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, 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, 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.
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.