When we look into the various ideas and concepts emanating out of the Toyota Way, the Toyota Production System (TPS) and all of the various Lean incarnations, we find that there are quite a set of principles and ideas to choose from, as various people and industries translate these concepts in order to adapt to their own reality.

Even though I find the core underlying ideas to be the most inspiring, I’ve found little need to re-invent the wheel. So to get cracking at improving the way work works, the basic principles I’ve tried to weave into the fabric here at my shop are the Poppendiecks principles for Lean Software Development, as expressed in their book, aptly titled “Lean Software Development: An Agile Toolkit”

The great people at Crisp made an addition in their version of the principles and included “Take the long view”. This seems wholly congruent to me, so I have chosen to do the same.

So what follows here is a quick rundown of the basic guiding Lean principles and an attempt towards a brief explanation of how we have designed our work with these ideas in mind.

Here we go:

Eight Lean Principles

1. Take the long view

What does it mean and why is it a good thing?

To me, taking the long view means accepting short term “losses” in order to protect long term gains. Things that are worth doing are worth doing right. This means being brave, demonstrating grace under pressure and saying no to some stuff.

How do we try to live up to it?

The long term gains that we are trying to protect touch on a multitude of different areas, including what kind of organisation we want to build, how we want to treat each other, what kind of product development team we want to be, the quality of the things we put out and so forth. There’s little room for compromise here. We have for instance allocated capacity to substantial platform improvements, we spend all the time and the money we deem necessary to build our team and our team players in order to facilitate the journey towards world class. We also find ourselves in a constant change process, which is allowed to take the time it takes in order to be successful.

2. Eliminate Mura, Muri, Muda

What does it mean and why is it a good thing?

So, now we’re talking Japanese. Mura means “uneven flow”, Muri is “overburden and stress”, and Muda is “waste”. Eliminating these things should result in better flow, and better flow means increased throughput. Increased throughput means shorter queue times and hence faster delivery of any value that we decide to pursue.

How do we try to live up to it?

We have an organization wide kanban-flow with a work-in-progress limit. Visualizing this (using first physical boards and later digitally using AgileZen) means that our colleagues now understand that no more work can be taken on if we have reached our WIP-limit. We have also been rather successful at scaling down the size of our releases and we avoid big batches of work, and we’re trying to organize around our value streams.

Further, we have been successful in categorizing different kinds of work, and we use simplified “classes of service” as this work is allocated to specific queues. One of these queues is managed by a (again) simplified “cost of delay” method. Or “impact of delay”, as I saw proposed by David J Anderson recently.

There are still some work coming in sideways, but we’re working on that, and despite our efforts, we are currently operation dangerously close to capacity (we have “local” adherence to WIP-limit, yet we find ourselves with one too many lanes at the moment) which is basically a result of historical decisions. We should be seeing the end of that inherited problem soon.

And when it comes to eliminating waste, I’ll have to make that a separate post for another day.

3. Build Quality in

What does it mean and why is it a good thing?

Quality should not be something that you start to consider during the end of a process. There’s ample opportunity to make high quality a part of the everyday work. High quality is good business, as sloppiness is punished immediately by our customers.

How do we try to live up to it?

Building Quality in means that we have high ambitions regarding quality and that we need very, very compelling arguments if we are ever to engage in any deadline driven development, which is a quality-killer if ever I saw one. When we talk about quality, we talk about quality of code, user experience, visual design, communication and so on. We are trying to build these aspects of quality into the very fabric of our product development process. For instance, there’s specific space allocated in our product development process for follow up work post-relase, this include – but is not limited to – responding to feedback and refactoring. You can read more about our product development process here.

4. Create Knowledge

What does it mean and why is it a good thing?

To me, creating knowledge first and foremost means that we actually regard both information and knowledge as something that can be created, it’s not necessarily something that “just happens”, even if that happens too. If you understand my meaning.

How do we try to live up to it?

We have several swim lanes of work, and these lanes are populated by members from our skilled team. The people who work together have bi-weekly retrospectives, where they focus on their own particular process, looking for (and implementing) improvements. We also have a monthly “whole departement retrospective” where we do the very same, but at a higher level. During these workshops we find areas where we want to improve, and the improvements (framed as experiments) are visualized in a Kanban-board, where we can see current experiments in progress. If the experiments turn out well, we make them part of our new MO and so they become “standard work”.

Previously, we arranged reoccurring Lab days. This was such a successful concept that we have extended the one day into two weeks. During these two weeks, (almost) all other work comes to a halt, and the players in the Product Development Team are left to their own devices to deliver whatever value they feel makes sense to them. There’s a minimal amount of structure and rules involved. All in all, we spend 25 percent of our time doing this.

We have also arranged a Hackathon in Berlin together with ImmobilienScout24, a German company with a product similar to ours, and we’ll have another go here in Stockholm come spring. Furthermore, we have book clubs where we read up on different topics, we attend conferences and we have an exchange thing going on with a friendly company here in Stockholm, with whom we meet up and compare notes on the “how” of product development.

5. Defer commitment

Deferring commitment means making decisions at the last responsible moment. The value of this is that until the moment arrives when the decision has to be made we have the opportunity to continue to gather information and by waiting we make sure we decide when we have more information, rather than when we have less. This improves the quality of the decision, and the gives us the flexibility and the possibility to turn the ship in a new direction if it’s called for.

How do we try to live up to it?

The product development process that we follow is designed to defer commitment until the last responsible moment, as the decision regarding what to work on next, be it larger themes or smaller work packages is made just-in-time. When it comes to our “theme work”, we also have a time boxed discovery period, that defers “final commitment” as it were, to a point in time when more information is available. The separation of the decisions to explore/discover and the commitment to deliver is an effective risk reduction strategy.

6. Respect people and their knowledge

What does it mean and why is it a good thing?

Respecting people is the very foundation on which all other things rest. I truly hope I don’t have to convince anyone why this is core.

How do we try to live up to it?

The way we assemble teams is based on the respect for people and their knowledge. In our Theme Work, we assemble the right people at the right time, and we try to “recruit” internally based on what our team members themselves want to work on. Our removal of the role “Product Owner” is also a move aligned with this important principle. We have no reason to give ownership of our product(s) to anyone else than the skilled people who build them. What we do have is someone in each cross functional team that handles administration, business rules, communication, coordination and other stuff. If none of the developers or designers want to take on that responsibility (as a learning opportunity) we have skilled generalist who can carry that if necessary.

7. Deliver fast

What does it mean and why is it a good thing?

To me, delivering fast is about sending out value to our customers with high frequency. More importantly, it’s about how fast delivery shortens our feedback cycles and speeds up our learning. And of course, as the saying goes: “Done is the engine of more”

How do we try to live up to it?

I repeat myself, but this is achieved by limiting WIP, small batch sizes and aggressive release planning. It’s also a question about being fearless, which is a mindset that we work to cultivate.

8. Optimize the whole

What does it mean and why is it a good thing?

Optimizing the whole is the opposite of local optimization, and local optimization is often counter-productive for the system as a whole. Optimize the whole is about seeing the whole system, the whole value stream, and work to improve it.

How do we try to live up to it?

In our product development process, we choose what value to deliver with the aid of a single impact tool. The tool has a set of parameters that reflect various areas of impact. We aim to focus on the value that brings the most value across the whole organization. We have also chosen to organize ourself with cross functional teams, across silos, along our value streams, with respect for the whole as we enter into our discover and delivery phases.

So there it is. I do feel that the foundation is in place, yet there’s plenty of room for further improvement.