WASTE

Post Origins

This is the first time I am adding this section to my posts but I think the context of where thoughts come from is helpful.

Recently I had the great opportunity to work with Woody Zuill on some Story Narrowing/Splitting/Slicing with a group interested in the topic. Subsequently a conversation took place with a cohorts group about this experience and it helped to clarify some of the different bits and pieces.

Before we get into this post, I want to thank Woody Zuill for the opportunity to partner up. I also want to thank Kevin Meadows, David Batten, Fred Zuill, and Alfredo Rivas for their insight and conversation.

Another thank you to Kevin Meadows for your time in reviewing and contributing directly to this post.

The Post Begins…

The discussion around reducing and eliminating waste in software development touches everything we do. The systems and processes we use. The code we write. The documentation we create. The stories we write. The techniques for setting objective targets. And all the tools and metrics we use to track everything we do. The ultimate waste is in the frameworks we implement. I may or may not drone on about the inherent waste of installing frameworks in this post, let’s just see where this goes.

For those new to my posts, I try to write them as a thought journey. I do very little editing beyond grammar and spelling. I am exploring a thought while writing about it and then sharing it out to see what comes of it.

Story Mapping

For years I have enjoyed story mapping. I am lucky enough to have had conversations with Jeff Patton about story mapping I’ve been a part of with various teams. It has dawned on me previously, and now I am thinking about it, are story maps waste? Potentially. In the truest lean thinking, I would have to consider them waste. We have created this story map that we can’t build all at once. The time we spent creating the map did provide us with a shared understanding of the big picture, but I have yet to be a part of a team that built the entire map end to end. In most cases, we only ended up building a very small portion of the map until our customer was happy with what they had. I don’t want to discredit the shared understanding that the story maps and the collaboration of story mapping provides. It has always been very helpful when I have been a part of creating or using them.

Chances are that if you created a story map, you are undertaking an effort to solve a large problem that has various steps, alternative pathways and scenarios, and multiple users spread across multiple domains. And I enjoy the use of a story map as a tool to narrow the scope of what we might deliver to solve some problem. What if we took the request that made us think about creating a story map and instead pulled out of it a single thing we could deliver and just went from there? To me this is where the power of story narrowing or slicing or splitting or whatever else we decide to call it has its real power but is often missed.

I recently had the opportunity to work with a group of people interested in story narrowing/slicing/splitting. One of the things we noticed is people tend to go right into solution mode and think about all the tasks we need to undertake to solve for the entire story. When we slowed down and narrowed out one piece of the story that we could understand, agreed it would deliver value, and we could deliver, that brought what needed to be done a little closer to the complicated domain, and a little less in the complex domain. (More on Cynefin domains ahead…)

But then we began to create inventory, and inventory is waste. The group started to narrow out another piece of the story. Why? We have this one piece we can do. Let’s do that. Then see if the next piece of the story should be done or if something else is of greater importance and value now.

“In product development, our greatest waste is not unproductive engineers, but work products sitting idle in process queues.”
― Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development

The reason I think this need to break down all of a story into its various bits before we start work is our need to have certainty about the future. We can’t. Combined with the thought that absolutely every part of the “requirements” is, well, required. And this type of thought process is supported by “Agile Frameworks” like Scrum and SAFe. Where we need to plan out everything we are going to do to complete a Sprint Goal or deliver at the end of our Product/Program Increment. And we should stop doing that. If you think we can have certainty about the future, then as a bright man once said.

“You’re wrong, and you should feel bad.” – David Batten

Now before the Scrum advocates come to attack me… No, there is nowhere in the Scrum Guide that states your Sprint must be the common 2 weeks we see everywhere. Or that you should be filling up your Sprint Backlog to support some arbitrary Sprint time-box. And no, there is nowhere in the Scrum Guide that states your Sprint Goal has to be some large undertaking. You could, and I have, worked on and with teams that used Scrum for 1-day Sprints, or 1-Story Sprints. But those teams ended up moving away from Scrum altogether. But there is that concept of a “Product Goal” in Scrum that does lend itself to building towards a larger deliverable than might be necessary. Which in turn supports the thought of loading a Sprint Backlog to achieve some larger goal of fulfilling all the required “requirements”.

Back to my original thought… Are story maps waste? Well, creating a map gives us a shared understanding of a larger vision. Story maps also allow us to horizontally slice out a potentially valuable end to end solution. Story maps also need to be created, and that takes time and effort. They also need to be managed and planned around. Which takes away from creating the software that delivers value into our customers hands. And since we created this map, we have created inventory. And all inventory is waste. Especially when you consider that we never build everything we put on the map. So yes, story maps technically fall under the “waste” category for me right now. That doesn’t mean I won’t continue to create story maps or support those that do. I love a good story map.

Domains

Understanding domains is not waste. But I did mention the complicated and complex domains towards the beginning of this post. If you are working on or with software development, it would be beneficial to familiarize yourself with Cynefin. Checking out Dave Snowden’s site on Cynefin would be a good idea. As well as various talks by Woody Zuill. Particularly his Let’s Make It Easy talk. I will try to provide some clarity here, but I am no expert. The short-short version is there are 5 domains. Clear, Complicated, Complex, Chaotic, and Confusion.

Clear. When things are obvious to us. We know exactly what to do to get a desired outcome.

Complicated. When things are a bit difficult, and we need some knowledge, skills, and experience to achieve the desired outcome.

Complex. When things are completely unknown. The unknown unknowns rule this domain. We may start down a path towards something and discover a whole new thing.

Chaotic. When things are on fire. We just react to them to put the fire out. We don’t have time to think.

Confusion. When we don’t know which domain, we belong in.

I, and many others, agree that software development lives in the complex domain. There are a ton of unknown unknowns to contend with and we don’t know the solution to the problems upfront. There are no instructions we can follow that get us to the desired outcomes.

Contrast this with engineering where there is a standard body of knowledge and long-established best practices. There are even math formulas that you can look up that tell you exactly how to model a process. We have nothing like that in software engineering. In fact, what we do should not be called “engineering” at all because it bears no resemblance to the rigorous approach of any other engineering disciplines. We’re making it up as we go along.

Kevin Meadows

When considering cynefin, I think most of the world doesn’t realize what domain they are in. We don’t stop to consider the proper domain. We can’t take tools and approaches from the clear or complicated domain and expect them to work in the complex domain.

When we narrow stories to find something distinct, that we understand, that delivers value, and we can deliver. We are attempting to nudge our work in software development from the complex domain a little closer to the complicated domain. We will probably never reach the clear domain with software development. But we can try. Who knows what innovative things we might discover. That is if we can get out of our own way.

Backlogs

I’m not sure where the disagreement can possibly come from on this one. A backlog is a list of things you intend to do but may not actually do. Calling it a list of potential options or experiments makes no difference. If you have a backlog, you have inventory, if you have inventory, you have queuing, if you have queuing, you have waste. This is essentially the same thought as a story map. If you have a story map. Which is an over production of possible options. Which creates a backlog of inventory. Therefor waste.

Take that same thought of a story narrowing from earlier. If we find one distinct, understandable, valuable, deliverable thing. And leave the rest of the story behind while we work on that one thing. Do we have waste? I don’t think we do. We are not committing to going back to that story at all. We are taking a small bit, delivering, and allowing the customer to steer us towards the next thing. If it is back to the original story, then so be it. But our collective understanding of what to do next is clearer. No, it is not now somehow magically in the clear domain, the complex nature of software development still exists. We are just a little clearer in our understanding of the solution and value we are attempting to provide.

Closing

There are plenty of wastes in everything we do. Processes, frameworks, software development, posting articles that possibly could have been a string of toots or tweets, and of course management bureaucracy we all know has a metric ton of waste. All these years later, and we are still trying to understand ourselves and help others to understand where we are, what a logical step in a direction is, and how to learn from that step where to go next.