Pawel Brodzinski on Leadership in Technology

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

Tag: principles

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

  • Practices, Principles, Values

    I was never a fan of recipes. Even less so when I heard that I have to apply them by the book. What I found over years was that books rarely, if ever, describe a context that is close enough to mine. This means that specific solutions wouldn’t be applicable in the same way as described in the original source.

    This is why I typically look for more abstracted knowledge and treat more context-dependent advice as rather inspiration that a real advice.

    From what I see that’s not a common attitude. I am surprised how frequently at conferences I would hear an argument that the sessions weren’t practical enough only because there was no recipe included. This is only a symptom though.

    A root cause for that is more general way of thinking and approaching problems. Something that we see over and over again when we’re looking at all sorts of transformations and change programs.

    People copy the most visible, obvious, and frequently least important practices.

    Jeffrey Pfeffer & Robert Sutton

    Our bias toward practices is there not without a reason. After all, we’ve heard success stories. What Toyota were doing to take over the lead in automotive industry. The early successes of companies adopting Agile methods. There were plenty of recipes in the stories. After all that’s what we first see when we are looking at the organizations.

    Iceberg

    The tricky part is that practices, techniques, tools and methods are just a tip of the iceberg. On one hand this is exactly what we see when we look at the sea. On the other there’s this ten times bigger part that is below the waterline. The underwater part is there and it is exactly what keep the tip above the water.

    In other words if we took just the visible tip of the iceberg and put it back to water the result wouldn’t be nearly as impressive.

    Practices, Principles, Values

    This metaphor is very relevant to how organizational changes happen. The thing we keep hearing about in experience reports and success stories is just a small part of the whole context. Unless we understand what’s hidden below the waterline copying the visible part doesn’t make any sense.

    Principles

    A thing beyond any practice is a principle. If we are talking about visualization we are implicitly talking about providing transparency and improving understanding of work too. Providing transparency is not a practice. It is a principle that can be embodied by a whole lot of practices.

    The interesting part is that there are principles behind practices but there are also principles that are embraced by an organization. If these two sets aren’t aligned applying a specific practice won’t work.

    Let me illustrate that with a story. There was a team of software architects in a company where Kanban was being rolled out across multiple teams. In that specific team there was a huge resistance even at the earliest stages, which is simply visualizing work.

    What was happening under the hood was that transparency provided by visualization was a threat for people working on the team. They were simply accomplishing very little. Most of the time they would spend time on meetings, discussions, etc. Transparency was a threat for their sense of safety, thus the resistance.

    Without understanding a deeper context though one would wonder what the heck was happening and why a method wouldn’t yield similar results as in another environment.

    Values

    The part that goes even deeper are values. When talking about values there’s one thing that typically comes to mind, which is all sorts of visions and mission statements, etc. This is where we will find values a company cares about. To be more precise: what an organization claims to care about.

    The problem with these is that very commonly there is a huge authenticity gap between the pretense and everyday behaviors of leaders and people in an organization.

    One value that would be mentioned pretty much universally is quality. Every single organization cares about high quality, right? Well, so they say, at least.

    A good question is what values are expressed by everyday behaviors. If a developer hears that there’s no time to write unit tests and they’re supposed to build ore features or no one really cares whether a build is green or red, what does that tell you about real values of a company?

    In fact, the pretense almost doesn’t matter at all. It plays its role only to build up frustration of people who see inauthenticity of the message. The values that matter would be those illustrated by behaviors. In many cases we would realize that it would mean utilization optimization, disrespecting people, lack of transparency, etc.

    Again, this is important because we can find values behind practices. If we take Kanban as an example we can use Mike Burrows’ take on Kanban values. Now, an interesting question would be how these values are aligned with values embraced by an organization.

    If they are not the impact of introducing the method would either be very limited, or non-existent or even negative. This is true for any method or practice out there.

    Mindfulness

    The bottom line of that is we need to be mindful in applying practices, tools and methods. It goes really far as not only does it mean initial deep understanding of the tools we use but also understanding of our own organization.

    This is against “fake it till you make it” attitude that I frequently see. In fact, in a specific context “making it” may not even be possible and without understanding the lower part of the iceberg we won’t be able to figure out what’s going wrong and why our efforts are futile.

    Paying attention to principles and values also enables learning. Without that we will simply copy the same tools we already know, no matter how applicable they are in a specific context. This is by the way what many agile coaches do.

    Mindful use of practice leads to learning; mindless use of practice leads to cargo cult.

  • Kanban: The Culture Challenge

    My focus for past months drifted a bit away from the core of Kanban. I either focused on more enterprisey applications of Kanban in the context of portfolio management or on what’s blood of every company, which is organizational culture. Every year though I use Kanban Leadership Retreat as a perfect occasion to reset my focus a bit. It wasn’t different this year.

    Those of you familiar with the method please forgive some of the basics in the post.

    The classic definition of Kanban Method is as follows.

    Principles

    • Start with what you do now
    • Agree to pursue incremental, evolutionary change
    • Initially, respect current roles, responsibilities and job titles
    • Encourage acts of leadership at all levels

    Practices

    • Visualize
    • Limit Work in Progress
    • Manage flow
    • Make policies explicit
    • Implement feedback loops
    • Improve collaboratively, evolve experimentally

    A side note: a super-common observation is that teams would understand and know the practices but would be almost completely ignorant of the principles. This is a pattern that leads to very shallow implementations that don’t yield sustainable improvements and typically stop at just better work management.

    Another perspective we may use to define Kanban is through its values. The approach was proposed by Mike Burrows. What Mike achieved was translating the original principles and practices to more generic values.

    The end result is a following list.

    Kanban Values

    • Understanding
    • Agreement
    • Respect
    • Leadership
    • Flow
    • Customer Focus
    • Transparency
    • Balance
    • Collaboration

    Since the values originated in the principles and practices there’s also an interesting exercise you can do to map one to the other.

    The important part of this perspective of looking at Kanban is that it describes what values should be embraced by an organization so that Kanban implementation will have deep and lasting impact. In other words if an organization doesn’t embrace for example transparency or respect I would expect resistance during the implementation, rather ephemeral improvements and very limited sustainability.

    Now, let me share yet another perspective of describing Kanban, which is Kanban agendas. Just to tease you there are three agendas: sustainability, service orientation and survivability. One nice thing is that the agendas nicely fit the values. Each of the agendas covers a few values.

    Sustainability

    • Transparency
    • Balance
    • Collaboration

    Service orientation

    • Customer focus
    • Flow
    • Leadership

    Survivability

    • Understanding
    • Agreement
    • Respect

    Now we have a frame for further discussion (and some of Kanban 101 in a pill too).

    Why I would bring this up, you may ask. One session that I attended at Kanban Leadership Retreat was about reintroducing an idea of maturity of Kanban implementations in the context of values. The workshop and the exercise we run there is a topic for another story. The important bit in this context is that Mike, who unsurprisingly run the session, decided to put Understanding, Agreement and Respect aside for the purpose of the exercise.

    We may look at it from at least a couple angles. We may say that Understanding, Agreement and Respect, since they all were derived from principles and not practices are much more difficult to assess than the rest.

    We may point that they are some sort of prerequisites for starting with the whole rest and thus we base on an assumption that these values are already in place.

    Both of these points of view are, in fact, valid. I see a big problem here though.

    First, this is a bit like saying that Understanding, Agreement and Respect are second-class citizens in this picture. The whole focus goes to the other six values. Now, let me remind one thing. The second-class values are derived from principles not practices. In other words it means petrifying the situation we have, where we discuss practices all the time and principles are relatively ignored.

    Second, Understanding, Agreement and Respect all belong to survivability agenda, which puts that very agenda at risk. What does it mean?

    If we get service orientation right this translates to doing things right and doing the right thing (at least as far as Kanban covers that part). If we get sustainability right it means that the evolutionary change is feasible. The problem is that without survivability it simply won’t last. We’ll see a pattern that is pretty common across Agile and Lean adoptions. Promising results and early success that is followed by systematic reversal of the change.

    Third, there’s one of my recent pet peeves, which is organizational culture. Obviously the culture relates to all the values by definition. However, Understanding, Agreement and Respect summarize the most common missing bits of culture. Also, these bits are least related to specific solutions we have in our toolboxes which means it is much more difficult to influence the change in these areas than it is in the rest.

    Finally, the assumption that we have Understanding, Agreement and Respect in place before we start with Kanban is simply not true in my experience. We wish it was, but that’s not what I see. Sorry. It is a common case with pretty much any method that reaches a specific level of maturity by the way.

    It all boils down to the challenge I teased in the title of the post. The challenge is to think about methods that aim to change or improve how we work from a perspective of organizational culture. A starting point would be answering a few questions.

    • Do we understand the existing culture of an organization?
    • Is the existing organizational culture well-suited to support the change we want to introduce?
    • Which elements (behaviors, values, beliefs) of the culture are missing?
    • How can we influence the culture so that it evolves toward the expected state?

    Before we can answer these questions in a meaningful way introducing a major change is simply gambling. And the odds are against us. Bad news is that in majority of cases the answer for the very first question would be negative and the further we get the sadder the answers would be.

    A good thing is that, at least as long as it comes to Kanban, we advance our thinking toward better understanding of what it takes to make the change survive. It should help to shift the perception of Kanban from a simple, light-weight tool that can help you with organizing work in one’s team toward deep and sophisticated model that requires understanding of quite a lot of related concepts.

    A word of warning: don’t expect the end results of the latter if you treat Kanban as a former.