One of the discussions that happened during Don Reinertsen’s product development workshop was the one about absorbing turbulence. Absorbing turbulence is a metaphor for how well a team deals with unplanned variability of the process. These would be situations like arrival of a bigger batch of features to build, or especially complex work items, etc.

Normally, every team is suitable to absorb some turbulence. Beyond that point this capability will not be sufficient and the situation would quickly escalate. A good example may be that the team would gracefully deal with some additional features but above certain threshold we’ll quickly the situation escalating to a high queue state. This would result in long lead times, long feedback loops and generally decreased responsiveness of a team.

These all result in lower efficiency too.

If such a situation persists over longer period of time it can take a heavy toll on people as we are running at risk of burning people out.

I really like the analogy that Don uses in his work: when a human body is losing blood, interestingly enough, blood pressure doesn’t go down. What our body is designed for is to pump enough blood to the brain so it can operate normally.

To compensate for losing blood the heart rate keeps going up. It goes up to the point where this mechanism is no longer sufficient and the organism crashes over a very short period of time.

A similar thing happens when we overload our teams. For some time they deal with the overload just fine introducing their own coping mechanism. They’d likely work overtime, introduce additional multitasking, etc. A problem is that, similarly to the situation when a human body loses blood, there’s a price to be paid for that.

Eventually people end up burned out and leave an organization. From that perspective a good question would be: what kind of early signals we get so that we can address the problem early.

One answer would be careful monitoring of work. How much work in progress we have. How our queues in backlog change. This kind of stuff. While obviously that would provide us some signal, that wouldn’t really be a proxy measure if we want to consider people first, not the process first.

What strikes me is that we at Lunar Logic already use a nice signaling mechanism that would give us an early warning. The mechanism is a happiness chart. Despite the fact that a happiness chart is a super simple, super low-tech tool it works on a few levels.

On one level we have individuals. When I see a deviation from the norm in the chart of one person it likely means that something’s going wrong. It may be related to the work, it may be related to a personal life. Whatever the case is it does affect the work.

If the case is individual it will unlikely be related to the whole project.

Another context is the one of the whole company. If things were going generally wrong I’d expect to see a strong signal across the whole board. “Generally wrong” may mean either mediocre business results, or a cultural problem, or a strong source of frustration, or a bunch of different things.

In such situation the signal would be broader than just a single project or product team.

There’s another scenario, which would be a bunch of people recording worse than typical mood and the correlation would be around a common project. Process-related parameters of that project may look OK: a backlog queue wouldn’t grow, throughput would go up, etc. Is there anything wrong then?

In this case happiness chart would serve as blood pressure – it would be a countermeasure pointing that something is going not exactly OK and if we keep doing that we may end up crashing.

The rule for our happiness chart is that the color translates to the mood. Green means happy, blue means so-so, and red means not happy. Once the chart for a project team gets more bluish or even reddish that’s a very strong indicator that we are not absorbing turbulence in that team gracefully.

The interesting part is that a happiness chart would provide such an information no matter whether a root cause is overloading a team with tasks, interpersonal conflicts that affect collaboration or anything else. The alarm would go off in either case. That’s actually perfect as we want to react to dangerous turbulence early in any situation.

From that perspective the outcome of happiness chart isn’t a leading indicator per se – when the change is triggered it means that there’s already something happening. It isn’t a lagging one either. We can correlate it with other parameters or even check with people to figure out what is happening. We would know that we’re not coping with turbulence well enough much earlier than when we are on the verge of crashing.

The reason why I think this strategy is so valuable is because it allows to merge the data from two different universes. On one hand we have all the process metrics that tell us how we are doing from efficiency perspective. On the other we get a social metric that tell a lot whether the current state is sustainable.

It is exactly like a combination of a blood pressure and a heart rate. The former translate to efficient work of our steering center – the brain. The latter tells a little bit how sustainable current conditions are.

One thing that we are doing at Lunar Logic is we evolve toward no management model of leadership. This means a lot of small changes that all happen with the same attitude at heart: to distribute more and more decision-making power across the whole company. This by the way also means systematically stripping down the management from that power.

The latter is easy in our case as the management is limited to me and I kind of launched the whole process. I would have to be either a hypocrite or a schizophrenic to resist the changes. Luckily enough I believe I’m neither. (Unless that other me has something else to say, that is.)

I don’t say it’s easy. One challenge in each step toward participatory leadership is that we, humans, don’t like to give up on power. I’m no different. I like that warm feeling that I can make a call and it shall be as I say. It’s not only that. Sometimes I simply know which option is good and the temptation to intervene and tell people what’s the best choice is strong. It would mean, however, taking a step back on a path toward democratizing leadership. So I keep my mouth shut.

On other occasions I just feel like we are going too far from my comfort zone and I slow down the process.

Giving up on power is a prerequisite to go further. While I don’t say it will go as easy in every case it isn’t enough to get that part working. In fact, despite being vocal how much I don’t want to make all sorts of decisions and how much I appreciate autonomy I still get loads of the questions that start with “Can I…”

If I’m lucky enough to suppress my System 1 reaction that would be either of: yes, yes but, no, no but answers I’d reply with “Can you?” The ball is back in your court and as long as you take responsibility for the call you make I’m OK with that.

The interesting thing is why these questions are popping up over and over again though. Despite the fact that on a conscious level we promote autonomy our natural behaviors means retreating back to the old pattern of asking for permission.

We simply don’t claim autonomy even if it slaps us in the face.

Besides years of programming our brains by education and work system that make it hard to act differently there’s another reason for that. Most of us want to be good citizens and we don’t want to use our autonomy to do stuff other wouldn’t like or even would be against. So we back up to the ultimate decision-making authority who is supposed to know what everyone in an organization likes or approves or more likely who doesn’t give a damn what anyone thinks – a manager.

The interesting thing is that the fear sometimes is well-grounded. We have different sensitivity toward different things. Behaviors that we consider positive or neutral may have negative connotation for others. If I’m a manager and I use my ultimate decision-making power and I don’t give a damn then, well, I don’t give a damn. But what if I’m just a team member who cares?

The idea we came up with is a set of two very simple rules.

1. The Nike Way
If you want to do something just do it.

2. Speak Up
If you don’t like what someone else is doing speak up.

Yes, that’s it. There’s one underlying principle, which is mutual respect. We don’t need to love each other. We need to respect our autonomy and our right to have different views on stuff.

The nice thing about this setup is that it is a self-balancing mechanism. It takes only one person try something new. It doesn’t require permission or even extensive up-front discussion. Pretty much the opposite, as a default we assume that every initiative would be awesome and everyone would love it or at least have nothing against.

The Nike Way is verbalizing the attitude described by famous Grace Hopper’s words: It’s easier to ask forgiveness than it is to get permission.

What we do know is that despite best intentions it won’t be true all the time. Occasionally, OK more often than occasionally, someone would do something that somebody else is not OK with. Then we have Speak Up rule that triggers a conscious and meaningful discussion (sometimes dubbed a shit storm) that provides additional insight for both sides and most likely some sort of consensus.

Speak Up rule was designed with a positive scenario in mind, i.e. someone unintentionally stepped on someone else’s toe. It works however in malicious cases as well. When someone intentionally crosses the line or pulls an organization in an unwanted direction someone else will speak up too.

The best part is that the same way it takes only one person to just do it, you need only one person to speak up.

One might point that there’s a risk that it would end up in indecisiveness. So far I don’t see that happening. First, speaking up doesn’t mean the ultimate veto power. It simply triggers a discussion. Second, the respect bit that is a hard prerequisite keeps the discussion civilized.

There’s a little more sophistication to balance that. Naturally extroverts would have an upper hand in unstructured discussion. That’s where empathy plays its role as helps to facilitate these weaker signals. On a basic level there are just these two simple rules: The Nike Way and Speak Up rule.

There’s an ongoing discussion that I occasionally refresh with Markus Andrezak on usefulness of applying Kanban to manage portfolio and generally to the process of figuring out which products should be built.

What is Portfolio

One obvious thing that we can start with is focusing on a specific context. After all portfolio is a pretty loaded word and it is used in all sorts of situations. While my goal isn’t to boil down portfolio discussion to only few available options I see at least three distinctively different cases.

There are organizations that ore focused on project work. A typical gig they run would be a distinct initiative that is different form all the other initiatives they run. What’s even more important the revenue from that work would be connected to delivering work. This would be a project portfolio case. A classic example would be an offshore web software shop.

Then we have organizations that, similarly to the previous example, focus on building multiple concurrent and independent initiatives yet they would operate them as products by themselves. In other words they earn money by directly selling their software, or services provided by that software, to the end users. There’s no simple definition when the work is done. This would be a product portfolio case. A classic example would be a game development studio.

Then there is an alternative version of product portfolio where the whole company is focused on building a single product. In such a case the overarching initiative that everyone contributes to is obvious as there is only a single one. The discussion would happen between either specific goals to achieve or specific big scale functionalities to build. This would frequently be labeled a product portfolio too although for the sake of this discussion I’d go with a feature portfolio label, even if it isn’t precise especially for big organizations. A classic example would be a startup building what they believe is the next world-changing product.

Of course we can think of a mix of any of these scenarios and rarely only one of them will be pursued by an organization exclusively. What’s more we could go further with a differentiation within these scenarios. We’d see a completely different dynamics of project portfolio in a company that works under time and material terms than from one that build fixed price projects. A very different feature portfolio will be in a startup at an early phase which is still figuring out product-market fit that in an established company focusing on leveraging their user base or staying ahead of competition.

Where is the Problem

The discussion about applicability of Portfolio Kanban boils down to defining what is the most painful problem on a portfolio level in a given context. From that perspective there is a clear distinction between project portfolios and the other two scenarios. The difference is in the way revenues are generated.

In project work the more projects we finish the more revenues we can expect. With product or feature portfolio building software is only an intermediate step in order to generate revenues. In other words we know much more up front about return on investment in project portfolio scenario than we do in other two.

That doesn’t completely change the bottom line. In each case the choice on endeavors an organization works on is crucial for its long-term health. In each case overcommitment and too much work in progress on portfolio level can decimate the value of any ongoing work, no matter how carefully chosen. There are commonly mentioned reasons for that: long lead times mean long feedback loops and a lot of work in progress results in inefficient work.

There’s one more dimension that from my experience is at least equally, if not more, important. The constraints provided by work in progress limits change the dynamics of the discussion about starting new stuff, be it projects, products or major features.

Typically the discussion about economic feasibility of starting a new product or a project happens in isolation. If the ultimate problem that we are trying to solve is choosing the right initiatives to work on it should never happen in isolation. After all most of ideas we come up with make sense… in some context. An interesting question would be whether we are in such a context.

We may have a bunch of projects that we expect to be profitable. But which of them provide us most monetary and non-monetary value? How starting another one affects the ones that are already ongoing? Given a business hypothesis which we want to validate, which out of all possible experiments would generate most valuable information? Would starting another concurrent experiment obfuscate the outcomes of ongoing ones?

Of course we can say that each project will provide some value and each experiment will provide some learning opportunities. We don’t have infinite capabilities thus we need to choose.

Role of Portfolio Kanban

The way I look at Portfolio Kanban is that is addresses a very common issue of overburden at portfolio level and as a result it drives the discussion about what are the right endeavors to pursue. The latter starts happening when, thanks to WIP limits, we start saying no to new initiatives. What WIP limits create is they underscore available capabilities as a scarce resource. The next step typically is more careful consideration how these capabilities are put in the best use, which ultimately means a discussion about what is the right thing to build.

Obviously this dynamics is not true in all environments. Startups, especially at the early stages, will likely focus on figuring out what is the right thing to build without any external incentive. Organizations built around a single product, at least to a certain size, will naturally maintain discipline in strategy planning that will provide an answer what are the crucial product goals for them.

Beyond that it all gets fuzzy. If an organization gets big enough it has capacity to build multiple initiatives concurrently. Each product that grew far enough has a number of potential development paths it can follow and each of them can be promising on its own. If we talk about multiple product organization a temptation to follow a bunch of new goals at the same time is even stronger. And with projects it’s like an everyday issue.

Of course I don’t say that it’s not possible to start the other way around: nailing down the ultimate purpose, which may mean answering the Spice Girls question, and following up with defining what are the right features, products or projects that serve the purpose. This would likely mean that the number of concurrent initiatives will be limited as majority of activities would be optimized toward pursuing the purpose.

The problem is few organizations are ready to make this step just like that. And even when they are, there are still a lot of risks along the way. First, depending on how the ultimate goal is defined it doesn’t have to limit the options for what constitutes an attractive endeavor and we’re back to the square one. Second, even if the purpose provides enough focus there’s typically still plenty of options how to pursue the goal and thus overburdening portfolio is still a viable option. Third, and most importantly, in bigger organizations defining a single purpose may be impossible because office politics kicks in or there isn’t enough strategic leadership present.

In either of these cases as well as in the most common situation where there isn’t enough awareness to even start the discussion about the purpose Portfolio Kanban may serve as a facilitation tool. On the top of efficiency gains, similar to those seen in other applications of Kanban, it would catalyze the discussion about what is the right thing.

This is, in fact, the most important outcome of introducing Portfolio Kanban that I’ve seen.

What Portfolio Kanban Is Not

An argument I’ve heard a couple of times is that Portfolio Kanban doesn’t help to define what is the right thing to build or what is the ultimate purpose. I completely agree with this one. That answer simply isn’t there. Portfolio Kanban, pretty much alike any Kanban application, is a meta method. One shouldn’t expect to get context-specific answers.

If an organization is ready to look for these answers that’s great. Depending on specific context Lean Startup, Lean UX or other modern product management approaches may be relevant. That’s where awesome guys like Will Evans or Markus Andrezak kicks in with their expertise. That’s where Stephen Bungay’s work will prove invaluable, which Jimdo guys will happily confirm. That’s where Don Reinertsen would provide outstanding guidance for decision making.

In such cases, usefulness of Portfolio Kanban will indeed be limited. It will be mostly process improvement and efficiency stuff.

A common case wouldn’t be even remotely as rosy though. That’s why value provided by Portfolio Kanban typically go beyond the process stuff. It would still stop at introducing pressure to start important and difficult discussions. It wouldn’t provide guidance for that conversation. A good thing is that there would be more pressure the more screwed up the situation is. We can expect this catalyzing mechanism to exist continuously till we either solve the problem or give up on limiting work in progress on portfolio level.

If someone claims that Portfolio Kanban is supposed to provide more than that in terms of defining what is the right thing, well, we may be talking about different things.

There’s a question I get asked pretty frequently: which conference I would recommend to attend. Of course the answer is always contextual but surprisingly often after some further inquiry I recommend Lean Kanban Central Europe.

On one hand it’s the content. Even today I remember all the keynotes from the first LKCE three years ago. That’s how much that stuck. Since then the program was only getting better. Then, there is exposure to new ideas. Lean Kanban series of conferences are surprisingly consistent when it comes to bringing to the mix new concepts, models and methods. One can bet that that thing which sounds so fresh on one of big Agile events was covered in extent a few years ago at Lean Kanban tour.

Then of course there is networking. With three hundred people networking is of very different quality than at the events that attract a thousand people or more. Everyone is more accessible and it’s not an ultimate challenge to track down someone who you really want to chat with.

The post wasn’t meant as a just an infomercial of LKCE. The conference, as every good event, evolves. One change that we introduced this year are consistent tracks and track chairs. This means that there’s always someone who made final decisions for the part of the program. This also means that there’s even more space for radical ideas as we as the program board aren’t driven by the consensus that much.

The track I’m honored to lead is the leadership track. One thing I didn’t want to do with it was just to throw a bunch of great speakers and just let them do their magic. What we’ll have instead is a theme and different ideas on leadership evolving around the same theme. Of course we still have a bunch of awesome speakers in the first place.

This approach means that everyone who will choose to stay throughout the whole track will get a consistent experience, while being exposed to different ideas. In fact, when working on the track I was thinking of it as of a mini-conference on its own.

The underlying theme for the track is broadening understanding of what leadership is and what approaches and tools we may use to let it emerge in our organizations. Esther Derby will kick off the track explaining that leadership at all levels isn’t just a nice theoretical concept or wishful thinking. At the same time the challenge is that there are no recipes that allow us to easily build such an environment. If there was such a thing as a track keynote it would be this one and I can hardly think of a better candidate than Esther to deliver it.

With no recipes we aren’t left alone in the wild though. We do have models and methods that, if understood correctly and used mindfully, can help us to shape the organization to steer emergence of leadership. When I think about people who easily mix different models and methods applying them contextually to provide most value Liz Keogh is on the top of my list. That’s why I asked her to cover that part. At least a bit of exposure to systems thinking and complex adaptive systems seems inevitable.

By that point the balance of the track will have swung toward more systemic approach to leadership. In that context however we can’t forget that at the end of the day it all boils down to people dynamics. That’s where Marc Burgauer will kick in with his message about how trust, connections, blame and fear of shame play pivotal role in building leadership across organization. Marc does an awesome job bringing people perspective into discussion.

The only missing bit in that mix is a practical story that shows how one may use all these building blocks to create a culture where leadership emerges and thrives. I tasked myself with that. On one hand at that point my job will be super easy as Esther, Liz and Marc will have covered the important parts and I’ll just build the connection between my story and earlier sessions. On the other, matching such a lineup of speakers is a challenge by itself. I guess my inner speaker now hates my inner track chair.

Of course leadership track will be competing for attendees attention with other awesome tracks. It was never our goal for LKCE to make choice between sessions even remotely close to easy. I do hope though that there will be some people who will choose to stay with us through all the leadership sessions. Especially that it is the shortest track of the event. As you can see though there was a lot thought invested to provide additional value for those who would be at all sessions.

The track is more than a sum of its sessions, it’s a product of interactions between its parts.

Have I just brought systems thinking again to the discussion? Oh well…

I hope this is one more argument to join LKCE this year. I’d love to see you there and I’d love to get feedback about the final outcome.

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.

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.

I like the way Jerry Weinberg defines leadership.

Leadership is a process of creating an environment where people become empowered.

Empowerment

I don’t really like the word empowerment as it is frequently used in the context of making people empowered. The way I understand empowerment such thing can’t even be done. You can’t empower me to do something.

What you can do is give me enough positional power and possibly encourage me to do something. I can still cease to do it because of a number of reasons. I may not see value or sense in doing that. It may move me too far outside of my comfort zone. I may be afraid of peer reaction. Finally, potential consequences of failure may drive my decision.

The way I think of empowerment is that it is intrinsic. I can feel empowered to do something. What others can do is they can create conditions that would enable that. It means anything from creating experiments that are safe to fail to shaping the environment so it supports and not discourages me to act.

Only such way of interpreting empowerment makes Jerry Weinberg’s definition of leadership reasonable.

Process

What Jerry Weinberg talks about is a process. That’s unusual as typically when we think about leadership we think about individual context. How to become a leader or how to become a better leader.

What “a process of creating an environment” communicates is that a discussion about leadership should happen in a different context. Instead of wondering how to help an individual to become a better leader we should discuss how to build an environment, or a system if you will, that supports emergence of new leaders and further development of existing ones.

This inevitably brings to a context of system thinking.

If we consider an organization a system there are many of its properties that influence whether, how and when people can lead.

One of the most obvious ones would be a formal hierarchy. How rigid it is and how many levels it is built of. A hierarchy is important as it often linearly translates to power distribution. Most often it would be managers who make most decisions and influence environment around in extent.

Then we have all the rules that people are supposed to follow. What is allowed and what is not. What stuff I have to comply to before I can do things I want. And most importantly whether everything is allowed unless rules state otherwise or the opposite: nothing is allowed unless rules state otherwise.

Thinking of an organization as of a system from a perspective of enabling leadership is important because the system defines constraints. Normally, one can’t go beyond these constraints without risking dire consequences.

In other words structures and rules define how much potentially is possible in terms of catalyzing leadership. It doesn’t automatically mean that fairly flat hierarchy and few rules is enough to see emergence of leadership throughout a company.

Environment

The bit that enables fulfilling potential created by rules and structures is organizational culture. We define organizational culture as a sum of behaviors of people being part of an organization. It’s not only abut behaviors though. It’s also about what drives them: values, principles, norms, beliefs, etc.

Organizational culture constitutes what is an environment we work in. This is what steers how far we would go within existing structures and rules. In fact, it may even let us break the rules. It may be perfectly acceptable to for an organization to go against the existing constraints as long as it means doing the right things and is aligned with organization’s values and principles.

What’s more, for companies that aim for good leadership distribution across the board will likely encourage such behaviors as it is a crucial condition for evolving the system and the culture.

The hard part about organization culture is that we can’t mandate its change the same way as we can mandate for example rules change. We can’t do it as the culture is a derivative of behaviors of many people.

What’s more we can’t mandate the change of behaviors in a sustainable manner either. We can introduce a policeman who would make sure people behave the way we want them to, but the moment the policeman is gone people would retreat back to the old status quo.

So what can we do with the culture? We can work on constraints. This is in fact aligned with a system thinking view of an organization.

A Process of Creating an Environment

The bottom line of this is that most of the time when I hear complaints about not enough good leaders it is because environment is designed in a way that doesn’t let them emerge, let alone thrive.

A litmus test that I use to quickly asses what climate there is for potential leaders would be bringing up famous Grace Hopper’s words:

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

The question to ask is how much of that attitude is present in an organization. An interesting observation is that the more people exercise that attitude the less they actually need to ask forgiveness.

The core of it though is empowerment. On one hand it translates to taking the rules into account and then doing the right thing even it means going beyond the rules occasionally. On the other it means that an organization accepts and supports such behaviors. It requires involvement of both parties.

It requires continuous effort to adjust rules and structures and evolve an organizational culture to reach such stage. It requires a lot of discipline across management on all levels not to break such attitude once it is present as it is fragile.

That’s why it’s a process and not a thing. Good news is that the better you do that the more leaders would get involved and the more self-sustaining the process will become.

At the end of the day, there’s no shortage of leaders, only a shortage of companies that let leadership emerge.

There is one thing that seems to be present in pretty much every company strategy these days. Given the opportunity, they want to grow. Obviously not every organization is successful at that but scaling up is treated as a default option and a universally desired goal.

In fact, it is sometimes assumed so obvious that it doesn’t even gets discussed. One example was a recent discussion on preserving culture (see comments too). The post that initiated the whole thing seems to assume that the growth is a fixed part of the equation.

An interesting thing happens when I mention scaling up strategy that we have at Lunar Logic, which is: don’t. All those blank stares and questions like “why would you pass an opportunity to grow?” Interestingly enough ceasing to grow means that we have to pass on some potential projects. This makes the whole discussion even more interesting.

An issue we forget is that scaling up doesn’t come for free and the biggest cost of growth is how it affects organizational culture. Given that the current culture is something one values, preserving the important parts of it during growth is extremely difficult. If we are talking about rapid growth it’s basically impossible.

If you happen to be in a place where the culture is a cornerstone of your success, which is exactly our case at Lunar, you may want to rethink whether scaling up is an obvious, or even desired, choice.

Nevertheless a story I keep hearing over and over again about different organizations is “we’ve been doing so great so far that we decided that we want to grow by 100% in a year.” The trick is that when they succeed they will likely be a very different organization. Different values will be shared across the group. Different behaviors will be treated as a norm. Different way of work will be considered a standard. It will be a different culture altogether.

It is likely that the very things that made them successful in the first place will be gone by then lost in rush to get bigger.

Obviously there’s only that many things one can do with couple dozen people but then decision about growth is typically made without considering all side effects.

And by the way, while I keep focusing on culture, as it is most vulnerable, there’s much more than that. One of the catchy themes these days is scaling Agile. Obviously part of the story is rolling out Agile in the context of big organizations. Another part though is maintaining all the value that we get thanks to using agile approach once we grow. While this is doable it adds to complexity of all the processes and the whole system.

It’s not without a reason that smallest organizations tend to be the most efficient and as they grow they tend to spend more and more effort trying to comply with their internal and artificial processes.

So why not dodge the bullet and keep an organization small? While I don’t say it has to be a default option it’s definitely an option to consider.

It changes the whole equation as suddenly you are incentivized to say no. No, we won’t take this project as we are fully booked. No, we won’t jump on that candidate even though she seems to be pretty good. Suddenly, we have higher standards for work we do and people we hire.

The focus is not on “more and more” but on “better and better.” Wouldn’t that be a nice option to consider?

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.

Whenever I end up discussing project portfolios with people representing or knowing specific organizations out of curiosity I ask a couple of questions. How many projects? How many people running those projects?

Note, most of the time I don’t ask these questions in the context of completely random organizations. The most common case would be asking people who are a part of Agile and Lean community. People who understand the concept of limiting work in progress and its implications.

Disturbing news is that, even among the most mindful people, the answers I would get are pretty much shocking.

Kanban Leadership Retreat is an occasion to meet people advancing thinking for a community that painted limiting work in progress prominently on their banners. One would expect that these people, if not anyone else, would be ahead of the rest of the crowd in addressing the issue of too many concurrent projects.

Well, maybe we are. At the same time the ratio of a number of projects run by an organization to a number of people who work on those projects reported at the last Kanban Leadership Retreat in Cascais is terrifying.

1.0, 2.1, 4.5 and 6.0. Let me rephrase what this number is. This is how many projects per person an organization runs on average. In fact, it does mean that some people are in a situation that is much worse than that.

I didn’t gather that data in any consistent manner. I just asked my question any time the context would pop up in a discussion. It isn’t by any means proper research. It shows, however, a very interesting trend. The best result is a project per person, and we are talking here about an organization with a hundred engineers in this case. Few of those projects, if any, require attention of a single person only.

From that point though we go downhill. I can’t imagine any situation where a single person runs concurrently a few projects and they are at least a tiny bit effective. This means heavy multitasking for those initiatives that get any progress and lots of others where progress is nil. Effectively, they are parked even if management believes that they are active.

Let me repeat. It wasn’t reported by a random community. It is the community that calls their user group meetings Limited WIP Society. Not Visualization Society or Flow Society. Limited WIP Society. We do care. We do pay attention. Yet still, we do suck at that. Big time.

Larry Maccherone in his talk at Lean Kanban North America reported that teams that work on a single project are significantly better in terms of defect density. We can use that as a proxy for quality of work. It’s not anecdotal evidence. Larry bases his research on raw data from almost ten thousand agile teams.

By the way, Larry also reported that team size of 5-9 people is by far the most popular one. In other words, ideally, we should be looking as projects to people ratio of 0.2 and below. Of course it is contextual and shouldn’t be treated as the true north. In organizations that typically run tiny projects that require attention of 2-3 people such ratio may be unachievable. At the same time we do have companies that typically run huge initiatives that involve dozens of people.

In either case anything above 1 is obviously crazy. In fact 1 is crazy already.

We can’t make this possibly work.

The easiest way out is obviously reviewing the portfolio and putting on hold or abandoning a big chunk of ongoing initiatives. This would mean that the active remainder would get more, hopefully enough, attention so that these projects can be completed in reasonable time.

Sad truth is that I know such an expectation is unrealistic.

If we understand that potential projects are options that we can execute and once we decide to start them it means commitment we should also understand the consequences. Commitment means that there’s a price to be paid for abandoning an initiative. What’s more that cost isn’t easy to assess. How much would reputation of a company suffer for letting a client down? How much bad word of mouth would be triggered?

Another way is to go with the theme of Lean Kanban Central Europe conferences: stop starting, start finishing.

In other words make it hard to start new stuff. Discuss the cost and risks attached to adding one more thing to your plate. I don’t expect an explicit WIP limit. On portfolio level it is rarely a feasible option anyway. The strategy that you can use is WIP limits by conversation.

There’s not much guidance needed to shift these conversations to a broader context that is frequently ignored. It’s not only how much a new project would cost and how much we are going to get in revenues. It is also about available capabilities: can we staff a project appropriately for its whole lifecycle? What is the cost of delaying the project? What risks are we going to introduce by starting a new initiative both to that initiative and to all ongoing ones? And what is ultimately value of completing the project?

The value question goes way beyond simple financial outcome. In fact, it is a very deep discussion as one needs to understand the goals of an organization. Otherwise discussion about value is pretty much irrelevant. Also discussion about value doesn’t happen in isolation. Remember how hard it was to let down current clients breaking our commitments to them? Well, that’s clearly negative value for the company. If that’s the cost you pay you better have a damn good reason to do so.

I do admit that WIP limits by conversation is a concept that seems vague and fuzzy. However, given that people understand what is effect of too much of work in progress I find it a surprisingly powerful tool. It simply shift the focus of a discussion and thus influences how decision making process looks like. It is like a facilitation tool that helps us to use knowledge that we already have.

Then we stop starting and start finishing.

If we do that in a continuous manner we evolve toward more effective way of working. Not only does it mean fewer emergencies or better reliability but also choosing the right initiatives to run. It would be a nice situation to be in, wouldn’t it?