At Spire Digital, we stick to a set of guiding principles, mantras, and rules of engagement by which we run the company and build great software. SpireLean came to be through a mashup of many influences.
Our Chief Operating Officer, Nick Coppolo recently gave a talk on SpireLean. Among other sources, he was heavily influenced by Jeffrey Liker’s Book, The Toyota Way and became inspired by the parallels between efficiently building quality cars and efficiently building quality software. From there, imagining a TPS-style service delivery model was only a small cognitive skip away.
Our goal became to achieve Toyota Motor Corporation’s flow state in both the business and production. Toyota’s playbook for building a great company by eliminating waste while creating evangelist customers changed everything we thought about what we do and how we do it. Ultimately, it changed Spire.
Genesis of lean
Postwar Japan is where lean came to be at Toyota. The Toyota production system became the example of religious waste elimination and value stream mapping, thereby making a lot out of a little.
It ultimately became the Toyota we know today largely through the work of Taiichi Ohno as influenced by the work of Edwards Demming. He created the principles around eliminating waste, value stream mapping, the ergonomics of an assembly line, the upstream preparing work for downstream, and Kanban, a visual representation of tasks using cards or tickets to balance demand with capacity.
Lean, specifically lean manufacturing is one degree removed from software development from a conceptual distance standpoint. It’s important to separate lean manufacturing from lean product development. We focus on the delivery of software and ways of thinking, correlation, and similarities to lean manufacturing.
Lean product development, popularized by Eric Reis’s 2010 The Lean Startup, is a complement to lean manufacturing, also born of scarcity in the form of capital. In the mid and late nineties, it was the “field of dreams” in terms of venture capital pouring cash into the unknown tech industry that had nebulous value and long term return. It was also highly speculative, like panning for gold.
Then, the tech bubble burst in 2001 and 2002 and capital reduced. Angels, Seeders and VC needed a new metric by which to wait or speculate on tech companies. Over the period between 2002 and 2008, capital became more readily available. Rather than investing in ideas, the general theme was to invest in people with the understanding that great leaders with great minds could find their way to building a great company. Instead of finding a great product to invest in, investors wanted to find great leaders with the right skills, charisma, and experience who could build a great company.
After the collapse in 2008 the barrier of entry was so low that we saw new capital. Whether it was a seed investor, angel investor or VC, they were investing in proof because companies could get to market faster. We could prove product market fit through users, retention, awareness, and ideally, revenue in a way that was unimaginably cheaper and faster than in the late 90s.
Principles of Lean Software Development: Eliminating Waste
If our goal and requirement in professional services is to constantly and rapidly deliver value to our customers, ultimately waste is the enemy of value. The seven wastes of lean are as follows:
For us, inventory is tracked through backlogs, stories, designs, requirements, research, and all components that lead to software development. You could see it in an inventory of concepts and ideas, which we may or may not build at some point. That is all a form of waste. In professional services, all of that iteration for things that may or may not come to be, we have to charge for. If our goal is delivering value, generally the most valued object or measurable increment of value is delivered functional software. We want to eliminate inventory or reduce it as much as possible.
If you’re waiting for designs or tickets, it’s a waste of time. Waiting typically prevents work. If a task is finished but there’s a delay in the approval process, it poses a bottleneck for the team. Waiting for input from another activity can slow down efficiencies, proving the importance of quick cycle times.
If you’re continually producing defects, it’s a major form of waste. It’s also the most visible. If you’re in production and something comes back from the client to go back to that chart of client stoke, it can very rapidly go the opposite way.
This is tricky for engineers because you’re always worried about painting yourself into a corner. Overproduction is building too much or beyond what has been demanded. As a result, at a minimum it slows down what we’re trying to deliver right now. There’s a fine balance to strike.
Motion is referred to when tickets go left, or backwards, in Kanban. When tickets go left, it creates more work, and that motion is a form of waste. We want tickets to go right, meaning they’re moving forward in their journey. Ideally, they will go all the way to the end.
One of the biggest forms of waste is inefficient communication. Transporting requirements include the definition of done, the plan, the when, and the how. Anytime we’re transporting that knowledge, there’s a risk that it’s lost or poorly translated. Transport, although necessary, is not an activity that is either designing or building software.
Over-processing could be considered another form of over-engineering, but more granular. It entails building things that take too long, have components that are unnecessary (also known as gold plating), or have workflow processes that delay value. Building for future proof is a dangerous principle. It’s important to build for now and understand that you’re going to iterate and build upon that. Otherwise, you risk over-processing.
Build, measure, and learn is the lean cycle. We formulate a hypothesis, create and run an experiment, reach a conclusion on the results of that experiment, and do the whole thing again. We want to do this in very short cycles. Ultimately, lean as a whole is about continuously and rapidly delivering value to your customer and in return, receiving value back to the business. At Spire, we would say any cost-bearing activity must directly deliver value to the customer, because in return, the business and its employees receive value as well.
Speed always wins in the marketplace. It would be better to get to market faster with a narrower, shallower product to establish some semblance of market share than to lose out to competition getting their first. Speed always wins, and not only is it your speed to market, but also your speed to react and change.
Predictability is the Holy grail in business. If you can say, “this is what we’re investing and this is what their return will be” and you deliver on it, it’s an impressive feat. At a more tactical level, if you can say, “this is what we’re going to build, this is when it’s going to be done, and this is what it will cost,” agile and lean doesn’t specifically allow for that, but it can enable it. Predicting the future requires measuring cycle time and throughput, and then measuring against the backlog. When you’re able to predict the outcome based on burn-rate, you can predict what things are going to cost.
This is huge, especially in an unknown environment. Even if you’re rebuilding enterprise software, operational software, or B2B software, retaining flexibility is key. If you go all the way back to the work in progress and inventory, there are sunk costs or investments made in every conversation we have and every document we produce.
The benefit of running Kanban is that you can change the entire course of the software project, ultimately the business, or in reality, anything within your power in an instant. You can change your mind, and fundamentally that’s very cheap, but building software is expensive. Thus, we want to retain as much flexibility as possible. Let alone for the obvious benefits in an ever-changing unknown business climate where you’re constantly receiving feedback from your customers and competitors, you need the ability to move and move fast, and not have the burden of sunk cost or investment for things that haven’t come to fruition to inform those decisions.
This goes back to this concept of thinking and planning. Conceptualizing everything before we put pen to paper is fundamentally inexpensive and we want to allow for that. We want to learn, discover, model something, and make sure there’s going to be a return on investment through research or subject matter experts.
The minute we go into execution, things become exponentially more expensive. The alternative is that we all are resolute in our vision, we don’t provide the details, we haven’t done the research, and we don’t provide the definition of done. And we say, “go build this thing” and you have chaos, and in this case, very expensive chaos.
Phases of flow
Tribal knowledge is a form of waste. Although it feels really good to have esoteric, tribal knowledge around what branch things are in and how we built them, it’s death to scalability and manageable, turnkey solutions, which we want to provide our clients. When going to help someone onboard, empathy is your greatest tool here. If you’re a developer and you walked onto this project and you think, “I would have no idea what I’m doing,” you probably need to update your documentation.
One of the cornerstones of documentation is the roadmap. This is where we get in the nitty-gritty. Roadmaps are key, simple documents that are shared with our clients and updated regularly. It lists what we’re building, when, and what it will cost. There’s no magic to this.
The ticket: the single source of truth
The ticket is everything in the efficiency and productivity of a software delivery team. The term ticket is derived from Kanban, but ultimately it’s a granular shippable requirement. The ticket is a progenitor of value. The ticket represents what is going to go out into the world in the form of working software, for which we will invoice our clients.
The acceptance criteria for a ticket should be binary, defensible, and irrefutable. The definition of done should require no domain knowledge or tribal knowledge. It should be relatively small, but shippable. If the ticket is sized appropriately, everybody on the entire delivery team, regardless of area of expertise or function, should be able to operate off the same ticket.
With throughput and cycle time of tickets, we can begin predicting the future. By analyzing past ticket size and complexity, we can predict which tickets will fall on the higher or the lower end of our standard deviation in terms of cycle time, including, where applicable, any inherent refactoring. This enables predictability.
Most software development firms want to increase their efficiency. This can sound difficult and intimidating, however, simply drawing from Toyota’s founding principles has the power to transform the way your company delivers. Since Spire Digital has integrated Lean methodology into its practice, efficiency has become integral to our success. Quickly delivering quality custom software has been a rewarding challenge for us. SpireLean has aligned our teams under a shared vision and end goal. Understanding the sources of waste has helped us stay focused on what matters and conscious of what doesn’t. We continuously and rapidly deliver value to our clients, and thanks to lean, we receive incredible value back to Spire Digital.