Pawel Brodzinski on Leadership in Technology

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

Tag: methods

  • Flailing Around with Intent

    Flailing Around with Intent

    Knowing is not enough; we must apply. Willing is not enough; we must do.

    Johann Wolfgang von Goethe

    Does it sometimes happen to you that you try to explain something in a detailed way to someone, and that person responds with a one-liner that nails the idea? I suck at brevity, so it happens to me a lot.

    That’s one reason why I appreciate so much the opportunities to exchange ideas with smart people from lean and agile communities.

    The most recent one happened thanks to Chris Matts and his LinkedIn post on agile practices. Now, I’d probably pass on yet another nitpicky argument about what’s agile and what’s not, but if it comes from Chris, you can count on good insight and an unusual vantage point.

    Community of Needs

    One reason that I’m always interested in Chris’ perspective is that he operates in what he describes as the Community of Needs.

    Members of the Communities of Needs operate in the area of “Need” to create a meme and then work with the meme to identify fitness landscapes where it fails, and evolve them accordingly. These communities have problems that need to be solved. They take solutions developed for one context and attempt to implement them in their own context (exaption), and modify (evolve) them as appropriate.

    If you dissect that, people in the Community of Needs will:

    • Focus on a practical challenge at hand
    • Be method/framework-agnostic
    • Understand the specifics of their own context and its differences from the original context of a solution
    • Seek broad inspirations
    • Be crafty with makeshift solutions

    The word ‘practitioner’ comes to mind, although it might be overly limiting, as the Community of Needs describes more of an attitude than an exact role one has in a setup.

    One might propose ‘thinker’ as the opposite archetype. It would be someone who distills many observations to propose a new method, framework, solution, etc.

    Thought Leaders

    Let’s change the perspective for a moment. When we look at the most prominent figures in lean & agile (or any other, really) community, who do we see? As a vivid example, consider who authored the most popular methods.

    All of them ‘thinkers’ (in Chris’ frame, members of the Community of Solutions), not ‘practitioners.’

    Before someone argues that the most popular methods stem from practical experiences, let me ask this:

    When was the last time the founding fathers (they’re always fathers, by the way) of agile methods actually managed a team, project, or product? It’s been decades, hasn’t it?

    Yet, these are people whom we rely on to invent things. To tell us how our teams and organizations should work. We take recipes they concoct and argue about their purity when anyone questions their value.

    I mean, seriously, people are ready to argue that the Scrum guide doesn’t call daily meetings ‘standups,’ as if the name mattered to how dysfunctional so many of these meetings are.

    It seems the price to pay for such thought leadership is following rigidity, preceptiveness, and zealotry. Thank you, I’ll pass. It feels better to stay on the sidelines. I will still take all the inspiration I want when I consider it appropriate, but that’s it. It’s not going to become a hammer that makes me perceive every case as a nail.

    Where Theory Meets Practice

    I admit that I have a very utilitarian approach to all sorts of methods and frameworks. If there’s a general guideline I follow, it’s something like that:

    Try things. Keep the ones that work. Drop those that don’t.

    Put differently, I just flail around with an intent to do more good than harm.

    Over the years, I’ve learned that a by-the-book approach is never an optimal solution. Sure, occasionally, we may consider it an acceptable trade-off. In my book, though, “an acceptable trade-off” doesn’t equal “an optimal choice.”

    Almost universally, a better option would be something adjusted to the context. A theory, a set of principles, a method, a framework—each may serve as a great starting point. Yet my local idiosyncrasies matter. They matter a hell lot.

    A smart change agent will take these local specifics into account when choosing the starting point, not only when adjusting the methods.

    For one of the organizations I worked at, Scrum was not a good starting point. Why? Were their processes so unusual that they wouldn’t broadly fit into the most popular agile method? Or maybe a decision maker was someone from another method camp? Might they be subject to heavy compliance regulations that forced them into a more rigid way of working?

    Neither. It’s simply that they had tried Scrum in the past, and they got burned (primarily because they chose poor consultants). The burn was so bad that anything related to Scrum as a label was a no-go. Working on the same principles but under a different banner simply triggered way less resistance.

    Local idiosyncrasies all the way. Without understanding a local context, it’s impossible to tell which method might be most useful and how best to approach it.

    Portfolio Story

    When we operate within the Community of Needs, even when we don’t have a strong signal like the one above, we rarely have a single ready answer.

    Consider this example. As a manager responsible for project delivery across the entire project portfolio, I was asked to overcommit. And not just by a bit. While already operating close to our capacity, top leadership expected me to commit to the biggest project in the organization’s history under an already unrealistic deadline.

    By the way, show me a method that provides an explicit recipe for dealing with such a challenge.

    At its core, it wasn’t even a method problem. It was a people problem. It was about getting through the “but you have to make it work and I don’t care how; it’s your job we pay you for” and starting the conversation about the actual options we had. You might consider it almost a psychological challenge.

    My goal was not to educate the organization on portfolio management, but to fix a very tangible issue in (hopefully) a timely manner.

    If I had been a Certified Expert of an Agile Method™, I might have known the answer in an instant. Let’s do a beautiful Release Train here, as my handbook tells me so. I bet I’d have a neat Agile Trainwreck™ story to tell.

    In the Community of Needs, we acknowledge that we don’t have THE answer and assess options. In this case, I could try Chris Matts’ Capacity Planning, which emerged in an analogous context. I might consider one of Portfolio Kanban visualizations, hoping to refocus the conversation to utilization. Exploiting Johanna Rothman’s rolling wave commitments might help to unravel the actual priorities. Inspiration from Annie Duke’s bets metaphor could be tremendously helpful, too.

    Or do a bit of everything and more. Frankly, I couldn’t care less whether I would do that by the book, even if there were a book.

    Ultimately, I wasn’t trying to implement a method. I was trying to address a need.

    Flailing Around with Intent

    It all does sound iffy, doesn’t it?

    “You can’t know the answer.”
    “You should know all these different things and combine them on the fly.” “Try things until something works.”

    Weren’t the methods invented for the sole purpose of telling us how to address such situations?

    They might have been. Kinda. The thing is, they respond only to a specific set of contexts. Or rather, they were designed only with particular contexts in mind, and they fit these circumstances well. Everything else? We’re better off treating them as an inspiration, not an instruction.

    We’re better off trying stuff, sticking with what works, getting rid of what doesn’t.

    As Chris put it:

    “Flailing around with intent is the best we can do most of the time when we are trail blazing beyond the edge of the map.”

    Chris Matts

    So, if you want a neat two-liner to sum up this essay, I won’t come up with anything remotely as good as this one.

    The Edges of the Map

    We could, of course, discuss the edges of the map. The popularity of a method may suggest its broad applicability. Take Scrum as an example. Since many teams are using Scrum, it must be useful for them, right?

    On a very shallow level, sure! Probably. Maybe. However, if something claims to be good at everything, it’s probably good at nothing.

    The Scrum Curse

    The more ground any given method wants to cover, the less suited it is for any particular set of circumstances.

    And if one wants to build a huge certification machine behind a method, it necessarily needs to aim to cover as much ground as possible.

    So, what is a charted map for Scrum? Should we consider any context where the method could potentially be applied? If so, the map is huge.

    However, if we choose the Community of Needs vantage point, and we seek the most suitable solution for a specific need we face, then the map shrinks rapidly. It will be a rare occurrence indeed when we choose Scrum as the optimal way given the circumstances.

    Then, we’re trailblazing beyond the edges of the map more often than we’d think. And flailing around with intent turns into a surprisingly effective tool.

    Thank you, Chris Matts and Yves Hanoulle, for the discussion that has influenced this article. I always appreciate your perspectives.

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