The fourth behavior, “Create simple things in small steps” describes both what to create (simple things) and how to create (small steps).
Simple Things
When I say simple, I don’t necessarily mean easy. And I certainly do not mean crude in form or incomplete. Simple indicates something that does not have superfluous parts or multiple responsibilities, is easy to understand, is as independent from the rest of the solution as possible, and meets a need as is.
Simple may not address all use cases, but it does address some use cases.
Take for example, a method for checkout that does not handle tax calculations. This has one responsibility - enable checkout. It addresses some use cases. It can be delivered right now and improve the experience, despite not meeting all of the “tax” use cases.
Small Steps
When I say small steps, I mean bits of work that typically improve the user experience or provide an opportunity to learn. This might be simplifying the checkout screen or running the tax calculation in the background and logging the results to see how it performs with real production data.
People often mistake small chunks with small steps. Small chunks may get us closer to the desired end, but do not offer value or learning along the way. These might include updating the database schema so that we can eventually manage sales, use, and specialty taxes in various combinations or leaving the tax calculation in a branch or behind a flag until we believe the entire thing is ready to go live all at once.
When we create simple things in small steps, we expand our options. Maybe 100% of our products are currently non-taxable. Or maybe we can live with the fact that people can purchase non-taxable items on-line but still have to call-in for taxable items. We’ve still cut down on the call volume. In either case, we have the option to address the “tax” needs in another small step or move on (for now) to something else.
In future articles, we’ll talk more about tools and techniques that enable us to create simple things in small steps.
If you want to keep up on the progress of the Behaviors Book, pay attention to the Behaviors Book page. And if you would like to learn more about how we use The Behaviors to guide teams, reach out.
In this article, I want to go more in depth on Opportunity Solution Trees; what they are, how they are used, how to create one, and how I think about them slightly differently (but only slightly) than folks like Teresa Torres who really introduced them broadly to the Product community in her book “Continuous Discovery Habits”. This book, by the way, is a must have for anyone who works in software product development - not just folks in product-specific roles.