Tag: kaizen

  • Why We Fail to Change

    Why We Fail to Change

    I’d love to get a beer each time I hear a story about management imposing a change on teams and facing strong resistance. Literally every time I’d fancy one, I’d be like, “Hey, tell me your agile transformation story.”

    One common excuse is that people don’t like the change. That is surprising given how adaptable humankind has proven to be. I’d rather subscribe to the idea that people don’t mind the change; they don’t like being changed.

    Unfortunately, being changed part is the story of oh so many improvement initiatives. And Agile implementations, obviously, are among the most prominent examples of these change programs, of course.

    So, how is it really with responding to changes?

    First, it really helps to understand typical patterns of introducing change. The model I find very relevant in this context is Virginia Satir’s Change Model. Let me walk you through it.

    We start with the existing status quo, which translates to a performance level. We then introduce a new concept, which we call a foreign element.

    Virginia Satir's Change Model 1

    Then we observe an expected improvement, and they lived happily ever after and all. Well, not really. In fact, whenever I draw that part of the model and ask what happens next, people intuitively give pretty good answers.

    After introducing a change, performance drops.

    Virginia Satir's Change Model

    It is kind of obvious. We need time to learn how to handle a new tool, practice, or method. Eventually, we become increasingly proficient at whatever that is, and we start to see the results of the promised improvements. Finally, we internalize the change, and the cycle is finished.

    Because of its shape, the curve is called a J-curve.

    It is an idealized picture, though. In reality, it is never such a nice curve.

    Virginia Satir's Change Model

    What we really see is something much bumpier. It isn’t a straight line to start with, when we maintain the old status quo. Then, it gets way more all over the place when we start messing with stuff. It’s not only that the rough average deteriorates, but also that the worst-case scenario gets worse, and by much more.

    It’s pretty much chaos. In fact, that’s exactly how this phase is called in Virginia Satir’s original model.

    Virginia Satir's Change Model

    An interesting observation we can make is that the phase called resistance is a short one that occurs just after introducing a foreign element. Does it mean that we should expect resistance against the change to be short-lived?

    Yes and no. Yes, if we consider only the “I’m not even going to try that new crap” type of resistance. This kind of reaction is typically driven by a lack of understanding of why the whole change was proposed in the first place. There is, however, a whole range of behaviors that happen later in the process that we would commonly call resistance as well.

    Some people aren’t ready to see even a temporary drop in performance. Once they face it, they suggest a retreat to the old status quo. When facing a stressful situation, many people instinctively go back to what they know best. Unsurprisingly, the old way of doing things is precisely what they know best.

    There are also those who are impatient and not willing to give people enough time to learn the ropes. Curiously enough, the last group often includes managers who initially funded the change.

    In either case, the result is the same in the end. More resistance.

    Virginia Satir's Change Model

    Inevitably, we reach a pivotal moment. We’ve been through the bumpy ride for quite some time already, and yet we haven’t gotten better. In fact, we’ve gotten worse. Not only that. We’ve gotten worse and less predictable. The whole change doesn’t seem like such a good idea after all.

    So what do we do?

    Virginia Satir's Change Model

    Of course, we reverse the change and go back to the old status quo. Oh, and we fire or at least demote that bastard who tricked us into starting the whole thing.

    One interesting caveat of the whole process is that a change is not always simply reversible. When we change specific behaviors and yet don’t get the expected outcomes, reverting to the old status quo may be difficult, if not impossible.

    For the sake of the discussion, let’s assume we are lucky and the change can be reversed. We are back to old ways of doing things, and we simply wasted some time trying something new. Oh, and we built a stronger case for resisting the next change. We petrified the existing situation just a little bit more.

    One reason changes are often reverted is the perceived risk associated with them.

    Virginia Satir's Change Model

    A pretty good proxy for perceived risk is predictability. Typically, the more unpredictable a team or process is, the riskier it is considered. In this case, the important thing that comes along with a foreign factor is how much predictability changes. Not only does performance drop, but it also becomes much less predictable.

    While the former alone might have been bearable, the combination of both factors contributes to the perception that the change was wrong in the first place.

    There is another dimension that is particularly interesting here. It is the scale of change. How much we change the existing environment: team, process, practices, etc.

    Virginia Satir's Change Model

    We can imagine a series of small improvements, each modifying the context only slightly. The entire series of them leads to a similar outcome as one big change rolled out at once.

    We can describe one approach as evolutionary and the other as revolutionary. If we draw inspiration from Lean, we’d call them Kaizen and Kaikaku, respectively.

    Virginia Satir's Change Model

    Fundamentally, the J-curve in both approaches would be shaped the same. The big difference is the scale. The revolutionary change means one big leap and rolling out all the new stuff simultaneously. This means a single big J-curve.

    The evolutionary approach introduces a lot of tiny J-curves one after the other. In fact, it is possible to have a few changes run concurrently, but let’s not complicate the picture any more.

    What are the implications?

    Virginia Satir's Change Model

    Let’s go back to the scale of the risk we undertake. With Kaikaku, the unpredictability we introduce is much higher than what we’ve seen in the late status quo.

    Kaizen, on the other hand, typically suggests changes that are small enough to avoid destabilizing the system nearly as much. It is pretty likely that unpredictability introduced by each of the small changes will be almost invisible, given that we don’t deal with a fully predictable process anyway.

    The risks we take with an evolutionary approach are much more acceptable than those we face when rolling out a single, large change.

    That’s not all, though.

    Virginia Satir's Change Model

    Another consideration is the duration of the destabilization. In other words, the cycle time of change.

    A big change, naturally, has a much longer cycle time, as it requires people to internalize many more new behaviors, practices, techniques, etc. It means that exposure to the risks is longer. Given that the risks are also more significant, it raises the odds that the change will be reverted before we see its positive results.

    With small changes, cycle time is shorter and so is exposure to risks. Again, not only are the risks much smaller, but they are also mitigated much faster.

    One last thing worth mentioning here is that, so far, we optimistically assumed that all the proposed improvements have a positive outcome. That’s not true.

    With the evolutionary approach, even if some of the changes don’t yield expected results, we still gain from introducing others. With a revolutionary approach, each part that doesn’t work simply increases the likelihood of reverting the whole thing altogether.

    It is not to say that Kaizen is always superior to Kaikaku. Both evolutionary and revolutionary approaches have their place. We need Stuart Kauffman’s Fitness Landscape to explain that.

    Stuart Kauffman Fitness Landscape

    Imagine a landscape that roughly indicates how fit for purpose your organization is. It should simply translate to factors such as productivity, responsiveness to the changing business environment, etc. The higher you are, the better.

    The simplest and safest way to climb up is to take small steps uphill.

    Stuart Kauffman Fitness Landscape

    While the approach works very well, eventually we reach a local peak. If we continue our small steps in any direction, it would result in lower fitness for purpose. Simply said, we wouldn’t perform as well as we did at the peak.

    If we look only at the closest terrain, we might as well say that we’re already perfect and there’s no need to go further.

    Stuart Kauffman Fitness Landscape

    Obviously, that would be naive. Or stupid. Or both.

    The solution becomes apparent when we take a broader view. If we moved to the slope of another hill, we could eventually reach even a better position.

    Stuart Kauffman Fitness Landscape

    That’s exactly when we need a big jump. It doesn’t have to automatically land us in a better situation than the one we were initially in. The opposite would often be the case. What is important, though, is that we land on the hill that is higher. That translates to bigger potential for improvement.

    Stuart Kauffman Fitness Landscape

    Once there, we can retreat back to the good old strategy of small steps that allow us to climb up. Eventually, we reach the peak that is higher than the previous one. Then we can repeat the cycle by looking for even a bigger hill.

    Similarly, to the case of J-curves, the picture here is idealistic, suggesting that each change, whether small or large, is considered successful. In reality, it is more the result of experimentation. Some of the changes would work, while others would not.

    Stuart Kauffman Fitness Landscape

    As you might have guessed, small steps here represent the evolutionary approach or Kaizen. A big jump is equivalent to revolutionary change or Kaikaku. Depending on the context, one or the other will be more useful.

    In fact, there are situations when one of the strategies will be basically useless. That’s why introducing change without understanding the current context is simply begging for failure.

    One more implication of the picture is that, given the lack of any other guidance, the evolutionary approach is both less risky and more likely to succeed. That’s why I prefer to start with Kaizen when I’m unsure about the context within which I’m operating.

    One last remark on Fitness Landscape. What you’ve seen here is a heavily oversimplified view. In reality fitness landscape wouldn’t be two-dimensional. Stuart Kauffman discussed it as a three-dimensional model, although I tend to think of it as a multi-dimensional one.

    It means that each change can improve our situation in some dimensions and have an opposite result in others (think: we’ve improved quality, but we are slower). We will have different combinations of effects in different dimensions—some more desirable and some less.

    If that wasn’t enough, the entire landscape is dynamic and continually changes over time. In other words, even after reaching a local optimum, we will need further continuous improvements simply to maintain our fitness for purpose. The peak will be moving over time.

    I know the post got long by now (thanks for bearing with me that far, by the way). This, however, is only a starting point for discussing why introducing the change often triggers resistance.

    I believe it provides a pretty good explanation of why so many improvement initiatives fail. This is also one of my answers to the question of why many Agile adoptions are doomed to fail from day one.

    Attempting to significantly change an organization without understanding its underlying mechanisms is simply begging for frustration and failure.

    Finally, understanding the change models will influence the choice of the methods and tools we’d use to drive our change programs.

    And if you chose a journey of a change agent, good luck! It can be as challenging as it can be rewarding.

  • A Fool With a Tool Is Still a Fool

    When I first discovered how Kanban in general, and Work In Progress limits specifically, worked as a catalyst for deep systemic improvements it was like an epiphany. Kanban, which at the beginning seemed like a neat and light-weight process management tool, proved to be far more than that. Not only was it helping to clean up the mess short term but also steered sustainable changes in the long run.

    When Tools Fail

    These were my early days with Kanban. Since then I’ve seen a lot of teams applying Kanban in all sort of ways. A thing that surprised me was that, even among the teams that achieved a certain level of maturity of the adoption, the results were mixed at best.

    Some of these teams are doing great and the early results I’ve seen no longer stand as exceptional. Most of them though weren’t even close. Clearly the magic of WIP limits that induce slack time, which in turn results in a steady stream of sustainable improvements, is neither obvious nor granted. There has to be something else.

    No curious person, and I tend to consider myself one, would pass on this observation without a second thought. No reasonable person, and I tend to consider myself one, would keep sharing the success stories ignoring all the counterexamples.

    Of course, one obvious reaction would be that the teams that failed to achieve exceptional results got it wrong. In fact, if you want to look for such attitudes among our thought-leaders it is pretty common. The method works, only those unskilled folks mishandled it, they’d say. No wonder these teams still crawl in the misery, they’d add. Actually, they sort of deserved it by not doing the thing the way we preached, the thought-leaders would sum up.

    Fortunately I’m not a consultant or an owner of a business that depends on popularity of a specific approach. I consciously chose to stay in practitioners’ camp. This leaves me with no neat and simple (and wrong) answer to the puzzle.

    A nice thing is that, given enough experience, we will stumble upon such puzzles on and on. Gemba walk which seems to be mentioned in every other important management book from The Goal to Lean Startup was another such realization for me. Failed stories of applying Kaizen boards and holding Kaizen evens was one more. Organizations struggling with Improvement Katas is probably the most recent one but the list goes on.

    Cargo Cult

    A cargo cult is, in short, defined as mechanically following practices or rituals without understanding why they worked in the first place and expecting the same results as achieved originally. In case you wondered it doesn’t really do miracles. In fact, the only known successes are creating prophets of cargo cults.

    A common observation, and a sad one, is that our efforts with applying different methods are surprisingly close to that definition. Even worse, such attitude is often encouraged. By the book applications of any tool means spreading the disease. It is like saying that we need to trust an enlightened prophet who guarantees two-, three- or fourfold productivity increase as long as we do exactly as they say.

    Don’t get me wrong the other end of spectrum, which is NIH syndrome, is equally bad. If NIH syndrome was a good guidance it would mean that entire management knowledge is useless because no one in the world was exactly in the context such as ours.

    In either case the missing bit is understanding the underlying principles behind the tools. One exercise I typically start my Kanban training with is asking a group about practices and principles. While they always know a few practices, sometimes most or even all of them, almost no one remembers any of the principles.

    By the way, the same thing is true when it comes to Agile Manifesto. Everyone knows “this over that” part but most of the time that’s pretty much it. It seems like we haven’t understood what we read. Alternatively, we never read that thing at all but heard about it somewhere where they used only the marketing part of the manifesto on a slide.

    It is kind of like knowing how but having no clue whatsoever why we’re doing something. And then we wonder why we fail so frequently.

    Understanding

    I know that belief in universal solutions has certain appeal. It doesn’t require us do to the hard work of trying to understand what is happening around. I don’t think there’s a shortcut here though. I mean one can get lucky, as I did during my early adventures with Kanban, but this experience can’t be easily translated to different contexts.

    Now, certain techniques give us a promise of help in facilitating the understanding how we work. Visualization and Gemba walks come as obvious examples. However, before we rush to apply them we may want to ask ourselves a question do we understand how and why these techniques work. Seriously. Even something seemingly so straightforward as visualization may be a waste unless a team understands that one of its biggest powers is reflecting current condition and current process and not projecting an expected state, or that too much burden on keeping it up to date will render it irrelevant, or that that too many objects on a board makes it incomprehensible and, as such, pretty much useless.

    I think the most common practice across all agile teams I know, no matter which method, if any, they follow, is a daily standup meeting. I believe I can safely assume that vast majority of agile teams have their daily standups. Now, how many of them asked themselves why they are doing that? Why are standups a part of a canon of Agile and Lean? Why were they introduced in the first place? And why, the hell, are they so prevalent?

    It doesn’t seem to bug many people. That’s interesting because they may be just following a cargo cult and maybe they could have been doing something much more useful in their context.

    Take pretty much any popular practice, technique or method. The same story again. We don’t understand why the tools we use work and simply blindly apply them. Doesn’t that fulfill a definition of a cargo cult?

    By the way, I think that one of significant contributors to the situation we have here is pretty common perception that Shu-Ha-Ri model universally applies in our context. A basic assumption that when being on Shu (apprentice) level we should do as a master say because we are incapable of understanding what we are learning doesn’t seem to be an extremely optimistic view of our teams.

    Call me lucky but most the time I worked with teams that are perfectly capable of better understanding how the work gets done and how specific tools contribute in that. The missing bit was either knowledge itself or curiosity to get that knowledge.

    A side note: the higher up we go through hierarchy the less of that curiosity I see, but that’s a bit different story. Most of time talking about tools we are in the context of teams, not VPs and execs.

    A Fool With a Tool is Still a Fool

    Any time a discussion goes toward tools, any tools really, it’s a good idea to challenge the understanding of a tool itself and principles behind its successes. Without that shared success stories bear little value in other contexts, thus end result of applying the same tools will frequently result in yet another case of a cargo cult. While it may be good for training and consulting businesses (aka prophets) it won’t help to improve our organizations.

    A fool with a tool will remain a fool, only more dangerous since now they’re armed.

    Not to mention that I don’t think orthodoxy is anyhow helpful in this discussion.

    By the way: as much as I didn’t want to engage the recent TDD versus anti-TDD discussion you may treat it as my take on it.

  • Why Your Change Program Will Fail

    Most change initiatives fail. How many of them? Well, let’s see.

    In 1995, John Kotter published research that revealed only 30 percent of change programs are successful. Fast forward to 2008. A recent McKinsey & Company survey of business executives indicates that the percent of change programs that are a success today is… still 30%

    This is from a McKinsey report. How about different sources?

    According to international management consultants Bain & Co, 70 to 90 per cent of organizational change initiatives fail.

    Now, obviously these statistics receive some criticism. After all, what is a change initiative? What is a success? My point is that what we see is that in different context we suck big time at improving how we work.

    What’s more we are not improving really. Over the course of past 15 years we’ve seen a huge rise of the methods and approaches that are specifically aimed toward driving the change management.

    Agile proposed a neat value container quickly filled with specific methods that should change and improve the way we work. Lean offered a thinking pattern focused on continuous improvements. Both are more and more frequently considered table stakes than game changers. Why nothing is changing then?

    First, let me make a bold observation: neither Agile nor Lean seem to be making a difference. In fact, that’s not only my observation. Daniel Mezick points that:

    If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, “freestanding” agility.

    We have to be doing something wrong. Dave Nicolette offers some ideas what that might be. Anyway with such a wild popularity of Agile and Lean we should expect to do better than that. The problem is that most of the time we don’t even try to understand what made them work in the first place.

    That’s a sad observation, but most of the time when I hear an Agile or Lean experience report it simply covers methods, practices and tools. The problem is that neither of these is pivotal in any change initiative. Basically, adopting practices and tools is simply a cargo cult. That’s not going to work unless there’s something more, the same way as it didn’t work for the Pacific tribes after the World War II.

    In agile context we often mention values as the missing bit. I sort of agree with that. Sort of because the way Agile Manifesto is formulated it creates false dichotomies, yet it points us the right direction.

    There’s a problem with values though. You don’t introduce values simply stating that you have them. You don’t incept them through mission statements and stuff. By the way, do any of you know value statement of your org by heart? Values are derivative of everyone’s behaviors and attitudes, thus they are a result of organizational culture.

    There’s one more layer to that. Values can’t be inconsistent with the culture. Otherwise authenticity is gone and your claims about values have little to do with reality.

    In other words a company can’t adopt Agile Manifesto simply by stating so. Not a surprise that change initiatives around Agile so frequently boil down to methods and tools. Not a surprise they fail at a high rate.

    We see the same story with Lean as well. The bits that get traction are tools and techniques. It is so often when I see teams acting like limiting work in process, doing Gemba walks and having Kaizen boards was everything there was to improve continuously.

    It’s not going to fly, sorry. We are back to organizational culture and everyone’s everyday behaviors. What do people do when they see an issue? Do they feel empowered to do whatever the hell they believe is the right thing to do to fix that issue? Do they even know what is the ultimate value they produce so they get good guidance on what is an issue in the first place?

    These behaviors tell a lot about the culture. Unfortunately most of the time answers for the questions above suggest that there’s no freaking chance to make the tools work the way we intend them to. Typically we see over-constrained, siloed organizations where one neither knows what is the right thing to do nor has courage to go beyond the constraints.

    I keep getting flak for bringing this up over and over again but I will do it once more.

    It’s easier to ask forgiveness than it is to get permission.

    Grace Hopper

    Grace Hopper’s famous words are, in my opinion, the essence of the bit we are missing when introducing Lean or Agile to our organizations. That very bit is responsible for the appalling rate of success of change initiatives.

    You can have all the hot tools and practices in place but when your people are driven by fear of consequences of their actions nothing will change. “Fear” may sound harsh but that’s what it is. It doesn’t mean that changing status quo by a tiny bit scares the crap out of me. It’s enough that I start thinking about potential consequences, what my bosses would think about that and whether they would even be happy. This is fear too.

    When I think about the situation from a perspective of my experience as a manager I’m not surprised. I mean, really, promoting this whole “don’t ask permission” attitude is going to backfire on you on occasions. What’s more it means giving up control. Even worse, it assumes trust. It assumes trust to everyone, not only to few trusted people. Now, this is a huge leap of faith management has to take.

    If you are thinking about continuous improvement or making your change initiatives work start with this leap of faith. If you can’t make it work don’t bother with all the tools, methods, practices and stuff. It’ll be just a waste of time. And the best part is that to make this work leaders have to start with themselves.

    Only then you can dream of influencing culture so that it supports the everyday acts of leadership on all levels. If you got it right you may actually start thinking about all the helpful stuff you can introduce to keep the changes running. In fact, it’s pretty likely that you won’t need so much guidance as lots of them will emerge.

    Oh, and if you wonder whether that change among leaders and managers is easy, well, it involves lots of pain and suffering. It is against of what we’ve been (wrongfully) taught for years. Sorry.

  • Why Kaizen Boards (Typically) Don’t Work

    A Kaizen board is a neat concept. It’s a visual tool that keeps track of all the ideas for improvements gathered across a team and then helps to analyze the status of ongoing improvement experiments. What we get from using a Kaizen board is we encourage everyone to participate in improvement process, visualize ongoing and planned improvements and give ourselves some sort of a tracking mechanism.

    That’s the theory.

    In practice I haven’t seen such a board that would work well.

    I don’t say it isn’t possible to make it work. I just say it’s unlikely.

    To answer why I think so, I have to bring the old story repeated multiple times in the context of Lean. When Japanese started kicking Americans’ butts in automotive industry in the second part of twentieth century Americans sent their managers to see what’s so different in factories in Japan. Surprisingly enough Japanese were super-open and transparent with all the tools and practices they had in place. Americans meticulously noted all the novel stuff they learned and implemented the same tools and methods back home. Guess what. It didn’t work.

    It didn’t work because all these practices weren’t really game changers. The real game changer was underlying mindset that actually made these tools and methods work. By the way, this was also a reason why sharing all the secrets about practices wasn’t a problem. They weren’t nearly enough to make a difference.

    We pretty much recreate the same story when we try tools like Kaizen boards or when we create Kaizen teams. We introduce a tool and believe it will change the game. It won’t.

    The magic behind thousands and thousands of improvements implemented in Toyota every year is not any of the tools. It is a culture that supports trying stuff out. It is mindset that enables that. All that continuous improvement is happening not because people submit improvement ideas to Kaizen boards but because people are actively experimenting. They do stuff.

    If you tried using a Kaizen board this picture may be familiar. There was lots of stuff submitted to the board but very few, if any, real changes were observable in your working environment. Now ask yourself: what would it take for any team member to try something out. Would people need to get permission and a blessing before they changed the way they worked? And then, when the thing failed, would they need to explain or ask forgiveness? Would they feel that they were co-creating the system they were a part of?

    In most organizations I know these answers would tell you why your Kaizen board or Kaizen team or Kaizen whatever doesn’t have a slightest chance to work. In fact, in such a situation a Kaizen board would just be a nice excuse. I’d had that awesome idea but it wasn’t accepted. I’d come up with that great improvement but there wasn’t time to implement it.

    Except then you shouldn’t call it a Kaizen board but an excuse board.

    And the best part is: if you have right mindset and the right culture in place a Kaizen board isn’t needed at all. People just run their improvement experiments. Of course some of them last and some of them don’t. Then you obviously can use a Kaizen board as a tracking and visualization tool. Unless you get there though – don’t bother.

  • MVP Thinking

    One of the most valuable goals achieved by Eric Ries’ Lean Startup is popularizing the term Minimal Viable Product (MVP). Of course the concept isn’t novel. We were using the Minimal Marketable Feature (MMF) idea back in the early days of Kanban and it was coined based on the same way of thinking. There are more of such concepts too.

    The basic premise is that we should build the smallest possible thing or run the smallest possible experiment that is still reasonable and adds value. Depending on the context the value may be something that helps users, but may as well be just knowledge discovery or verification a hypothesis.

    One thing I’ve realized recently is how widely I apply this thinking. Initially, it was simply the way of breaking the scope down. I wanted my teams to build possibly small, but still valuable, chunks of software so a client can verify them and feed us back with useful information. Then, after Lean Startup, it was about running a product. What we want to build something new that kicks butts. What is the smallest feature that can prove or disprove the hypothesis that it would work at all?

    Somehow I now use the same way of thinking, MVP thinking if you will, to discuss marketing ideas, define actionable items during retrospectives, etc. Often it is difficult to define a product per se, but there always is some kind of an expected outcome and definable minimal effort allowing the get that outcome.

    So how would I define MVP thinking?

    1. Define the next smallest valuable goal you want to achieve.
    2. Define minimal effort that allows you to achieve that goal.
    3. Execute.
    4. Analyze the outcomes and learn.
    5. Repeat.

    A potentially tricky part here is defining the goal because it is totally contextual. It is also something that really appeals to me as I don’t like recipes. In fact, if there is anything new here it is basically extremely broad application of the pattern as the idea itself is anything but new. I mean, we usually close our context to working with the scope of a project, driving a product, running a business, etc. Then, we absolutely coin a new term and if it works we make our careers as overpriced consultants.

    That’s totally not my goal. I’m just trying to broaden an applicable context of ideas we already know as I’ve personally found it helpful.

    So if my problem is a roof leaking near a roof window my next minimal goal may be verifying whether the leakage has anything to do with an external window blind. Such a goal is nice because minimal effort may mean simply waiting for the next rain with the blind either opened or closed. I definitely don’t rush to repair the roof.

    Talking about marketing? Let’s set a general goal that, say, TechCrunch will cover us. What would be the smallest valuable experiment that can bring us closer to achieving this kind of a goal? I guess reaching out and networking may be a very reasonable first step. It doesn’t even require having an idea, let alone a product, that we want to have covered.

    How about a product? Well, this one was covered virtually everywhere. Building minimal functionality, possibly even fake, that allows verifying that the idea for the product makes sense.

    Retrospectives? What is a single, smallest possible, change that will have a positive impact on the team? Try it. Verify it. Repeat.

    Heck, I even buy my sailing gear this way. What is the smallest possible set that allows reasonable survival? Then I use the outcome and iterate, e.g. next time I need new gloves, long johns and waterproof case for a phone.

    When you think about that it is basically Kaizen – systematically running small improvement experiments everywhere. So yes, it’s nothing new. It’s just the specific idea of Minimal Viable Product that spoke to me personally and gave me a nice constraint that can be used in different areas of my life.

    By the way, despite it very open definition I also find Kaizen usually applied in a very limited context. So no matter which idea works for you, just remember you can use it in broader context.