Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: methods

  • The Fallacy of Shu-Ha-Ri

    Shu-Ha-Ri is frequently used as a good model that shows how we adopt new skills. The general idea is pretty simple. First, we just follow the rules. We don’t ask how the thing works, we just do the basic training. That’s Shu level.

    Then we move to understanding what we are doing. Instead of simply following the rules we try to grasp why the stuff we’re doing works and why the bigger whole was structured the way it was. We still follow the rules though. That’s Ha level.

    Finally, we get fluent with what we do and we also have deep understanding of it. We are ready to break the rules. Well, not for the sake of breaking them of course. We are, however, ready to interpret a lot of things and use our own judgement. It will sometimes tell us to go beyond the existing set constraints. And that’s Ri level.

    I’ve heard that model being used often to advise people initially going with “by the book” approach. Here’s Scrum, Kanban or whatever. And here’s a book that ultimately tells you what to do. Just do it the way it tells you, OK?

    Remember, you start at Shu and only later you’d be fluent enough to make your own tweaks.

    OK, I do understand the rationale behind such attitude. I’ve seen enough teams that do cherry picking without really trying to understand the thing. Why all the parts were in the mechanism in the first place. What was the goal of introducing the method in the first place. On such occasions someone may want to go like “just do the whole damn thing the way the book tells you.”

    It doesn’t solve a problem though.

    In fact, the problem here is lack of understanding of a method or a practice a team is trying to adopt.

    We don’t solve that problem by pushing solutions through people’s throats. The best we can do is to help them understand the method or the practice in a broader context.

    It won’t happen on Shu level. It is actually the main goal of Ha level.

    I would go as far to argue that, in our context, starting on a Shu level may simply be a waste of time. Shu-Ha-Ri model assumes that we are learning the right thing. This sounds dangerously close to stating that we can assume that a chosen method would definitely solve our problems. Note: we make such an assumption without really understanding the method. Isn’t it inconsistent?

    Normally, the opposite is true. We need to understand a method to be able to even assess whether it is relevant in any given context. I think here of rather deep understanding. It doesn’t mean going through practices only. It means figuring out what principles are behind and, most importantly, which values need to be embraced to make the practices work.

    Stephen Parry often says that processing the waste more effectively is cheaper, neater, faster waste. It is true for work items we build. It is true also for changes we introduce to the organization. A simple fact that we become more and more proficient with a specific practice or a method doesn’t automatically mean that the bottom line improves in any way.

    That’s why Shu-Ha-Ri is misguiding. We need to start with understanding. Otherwise we are likely to end up with yet another cargo cult. We’d be simply copying practices because others do that. We’d be doing that even if they aren’t aligned with principles and values that our organization operates by.

    We need to start at least on Ha level. Interestingly enough, it means that the whole Shu level is pretty much irrelevant. Given that there is understanding, people will fill the gaps in basic skills this way or the other.

    What many people point is how prevalent Shu-Ha-Ri is in all sorts of areas: martial arts, cooking, etc. I’m not trying to say it is not applicable in all these contexts. We are in a different situation though. My point is that we haven’t decided that Karate is the way to go or we want to become a perfect sushi master. If the method was defined than I would unlikely object. But it isn’t.

    Are there teams that can say that Scrum (or whatever else) is their thing before they really understand the deeper context? If there are then they can perfectly go through Shu-Ha-Ri and it will work great. I just don’t seem to meet such teams and organizations.

  • Recipes Are (Almost) Useless

    One of the least useful pieces of advice you may ever get on management would go along the lines: “we’ve done such and such and it worked freaking miracles for us, thus you should do the same.” In fact, all the ‘shoulds’ and ‘musts’ are sort of a warning signal for me, whenever I learn about someone doing something right.

    This is by the way something that is surprisingly prevalent in many management books. A story of someone wildly successful who shares how they believe they achieved it. While I do appreciate a story and all the insider’s insight that help to understand a little bit more it is only a story.

    Was it backed up by credible research? Was it successfully adapted in a number of other organizations? What might be critical assumptions that we base on and how would the story be different in another context?

    It’s not that I would call each of these stories bullshit. Pretty much the opposite. I often find that many of the ideas shared are aligned with my experience. The issue is that on occasions I can track down some of the underlying prerequisites that aren’t even mentioned in the source. Does it mean lack of good will? I don’t think so. I’d rather go with fairly shallow knowledge.

    Unfortunately this has a lot to do with what we, as consumers of books, articles or conference presentations, expect. It is oh so common when the basic expectation is to get a recipe. Tell me how to build my startup. Tell me how to fix my effectiveness problem. Tell me how to grow an awesome team. Tell me how to change my organizational culture. Tell me how to scale up a method we are using.

    Yes, recipes sell well. They are sometimes dubbed “actionable content” as an opposition to theories that are non-actionable. That is unless someone undertakes effort to understand them and adjust to their own context.

    Over years I’ve been enthusiastic about some methods and practices I discovered. I’ve been skeptical about many more. I’ve changed my mind about quite a bunch of them too. An interesting realization is that the further from a plain recipe a method is the more I tend to consider it useful in the long run. I guess one of the reasons for me to stick with Kanban for all these years is that I quickly realized how adaptive the method is and how much liberty I could take using it.

    This is also a reason why I never become a fanboy of Scrum. While obviously there’s much value in specific practices it offers in specific contexts I got discouraged by early “do it by the book or you aren’t doing Scrum” attitude promoted by the community.

    I digress though. The point I want to make is pretty simple.

    Recipes are useless.

    OK, OK. Almost useless.

    It doesn’t really matter whether we discuss a project management techniques, software development practices or general management methods.

    It’s not without a reason that pretty much any approach, once it becomes popular, ends up being not nearly as useful as it was reported in early success stories. There are just too many possible contexts to have any universally sound solution.

    What’s more, during its early days, a method is typically handled by people who invest much time to understanding how and why it works. After all, there are no success stories yet, or very few of them, so a sane person handles such a thing cautiously. Then, eventually it goes downhill. Some would treat a method as universal cure for all the pains of any organization, others would sense a good certification business opportunity and suddenly any understanding of ‘whys’ and ‘hows’ is gone.

    One thing is what I believe in and how I approach the tools I adopt to my toolbox. Another one is that I frequently get asked about an advice. I guess this is inevitable when you do at least a bit of coaching and training. Anyway, in every such situation the challenge is to dodge a bullet and avoid giving a recipe as an answer. This by the way means that if I am answering your question with ‘shoulds’ and ‘musts’ you should kick me in the butt and ignore the answer altogether.

    A much better answer would be sharing a handful of alternatives along with all the assumptions I know that made them work in the first place. Additional points are for supporting that with relevant research or models.

    In either case the goal should be the ultimate understanding why this or that thing would work in a specific context.

    Without that a success story is just that – a story.

    Don’t get me wrong. I like stories. We are storytellers after all. It’s just that a story itself bears only that much value.

    The next time you hear a story, treat it for what it is. The next time someone offers you a recipe, treat it for what it is.

  • 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.