One thing that I learned quickly when I started experimenting with Portfolio Kanban is that a classic, flow-driven board design isn’t particularly good in vast majority of cases.

Board Designs

Long story short, I ended up redesigning the board structure completely and it worked much better. In fact, it worked so well that I started proposing such a design as a starting point whenever working with portfolio Kanban.

Interestingly enough, as Kanban adoption of portfolio level progressed I started seeing completely different approaches to visualization. Not that they were worse. They just focused on different aspects of work.

One that popped up early was two-tier board that addresses different granularity of tasks at the same board. We can track the roots of this design to David Anderson’s time at Corbis. Since then it was picked up to manage portfolios.

Another example came from Zsolt Fabok, who was inspired by Chris Matts. What he proposed was a board that stresses expected delivery dates and how an organization is doing against these dates. Again the board design is completely different from the ones we’ve seen so far.

Another interesting example that I like is a portfolio board that visualized non-homogenous flow of work. This still is one of the most unusual board designs I’ve seen and yet it makes a perfect sense given the context.

By that time it was perfectly clear that there is no such thing as a standard design of Portfolio Kanban board. Each of these designs was fairly optimal if we considered the context. At the same time each of the boards was designed to stress a different aspect of work.

The design I ended up with in my Portfolio Kanban story revolved around available capabilities and commitments. The two-tiered board design focused on flow of coarse-grained items and breaking work down to fine grained items. The deadline driven board based on an assumption that the most critical aspect of work are delivery dates and monitoring delays. Finally, non-homogenous flow board design addressed the issue of different flows of work in each of the projects.

Which design is most useful then? It depends. To address that question we first need to answer which aspect of our work is the most important to track on a regular basis. To get that answer we need to discuss risks.

Risk Management

Obviously, risk management is a multi-dimensional issue. Some dimensions would be more interesting than others. The word “interesting” typically translates to the fact that we are more vulnerable to a specific class of risks or that we are doing especially badly against managing that class of risks.

A typical example in the context of portfolio management would be overburdening. We commit to more projects or products than we can chew. We end up having our teams juggling all the concurrent endeavors. As a result we see a lot multitasking, context switching, and huge inefficiencies.

In such a case the most interesting dimension of risks would be one related to managing available capabilities and ongoing commitments. And that would exactly be information that we’d like to focus on most when designing Portfolio Kanban board.

That’s by the way almost exactly the process I went through when I proposed capability-focused board design. Of course, back then the thought process wasn’t that structured and it was more trial and error.

There are some additional aspects of the story, like the huge variability of size of the projects that we typically see. This would affect the details of the board design as well. In this case relative size is visualized as well.

The most important bit is that we start with the most important risk dimension. This should define the whole structure of Portfolio Kanban board.

Coming back to different visualizations I mentioned we can easily figure out what was the key class of risks in each design.

In two-tiered board the biggest concern was smooth flow of coarse-grained items (feature sets). We can also figure out that variability in size of feature sets wasn’t that much of a problem. Given that we’re talking about product development organization and that they are in full control of how they define feature sets, it does make a lot of sense.

Delivery date driven board stressed how important risks related deadlines and timeliness of delivery were. We may also notice that there isn’t much stress on flow of work and not that much focus on addressing potential overburdening either.

The design with non-homogenous flow, as its name suggests, pinpoints that most important risk dimension was managing flow. On the other hand risks related to capability management and overburdening don’t seem so important.

Optimal Design

The structure of Portfolio Kanban board can show only that much. We can’t visualize all the risk dimensions using the board structure alone. David Anderson in his Enterprise Service Planning talk points that it is common that organizations track 4-8 different dimensions of risks. The board design can address one or two.

Make it the two that matter most.

Where would others go? Fortunately we still have items on our board, whatever we decide them to be. We can track information relevant for other risk dimensions using information on index cards. The design of the items on the board is no less important than the design of the board itself.

Designing Portfolio Kanban board is not an obvious task. We don’t even have a standard approach – something similar to a flow-based design we commonly use on a team level. Understanding how we manage risks is the best guidance that can lead to fairly optimal board design quickly.

Of course one alternative is to go through a trial and error process. Eventually you’d land with similar outcomes. A quicker way though is to start with understanding risks.

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.

I argued against multitasking a number of times. In fact, not that long ago I argued against it in the context of portfolio management too. Let me have another take on this from a different perspective.

Let’s talk about how much we pay for introducing too many concurrent initiatives in our portfolios. I won’t differentiate here between product and project portfolios because for the sake of this discussion it doesn’t matter that much.

Let’s imagine that the same team is involved in four concurrent initiatives. Our gut feel would suggest that this is rather pessimistic assumption, but when we check what organizations do it is typically much worse than that. For the sake of that discussion and to have nice pictures let’s assume that all initiatives are similarly sized and start at the same time. The team’s effort would be distributed roughly like that.

The white space between the bars representing project work would be cost of multitasking. Jerry Weinberg suggests that for each concurrent task we work on we pay the tax of 20% of the time wasted on context switching. Obviously, in the context of concurrent projects and not concurrent tasks the dynamics will be somewhat different so let me be optimistic with what the cost in such scenario would be.

If we reorganize the work so that we limit the number of concurrent initiatives to two we’d see slightly different picture.

Suddenly we finished faster. Where’s the difference? Well, we wasted much less time on context switching. I assumed some time required for transition from one project to another yet still, it shouldn’t be close to what we waste on context switching.

In fact, we can move it even further than that and limit the work to a single project or product at the same time.

We improved efficiency even more. That’s the first win, and not the most important one.

Another thing that happened is we started each project with the exception of the first one in presence of new information. We could have, and should have, learned more about our business so that we are better equipped to run another initiative.

Not only that. It is likely that technology itself or our understanding of technology advanced over the course of running the first project and thus we will be more effective building another one. These effects stack up with each consecutive project we run.

The total effect will be further improvement of the total time of building our projects or products. This is the second win.

Don Reinertsen argues that the longer the project is the longer the budget and schedule overrun. In other words, if we decided to go with all the concurrent initiatives we’d likely to go longer that we assumed.

In short it means that we do end up doing more work that we would do otherwise. Projects are, in fact, bigger than we initially assumed.

The rationale for that is that the longer the project lasts the bigger the incentive to cram more stuff into it as the business environment keeps evolving and we realize that we have new market expectations to address.

Of course there’s also an argument that with bigger initiatives we have more uncertainty so we tend to make bigger mistakes estimating the effort. While I don’t directly refer to estimates here, there’s an amplification effect for scope creep which is driven by overrunning a schedule. When we are late the market doesn’t stand still. To make up for that we add new requirements, which by the way make the project even later so we add even more features, which again hit the schedule…

A bottom line is that with bigger projects scope creep can get really nasty. With fewer concurrent initiatives and shorter lead times we get the third win.

Let’s assume that we’ve had deadlines for our projects.

What happens when we’re late? Well, we pull more people from other teams. Well, maybe there was one guy who said that adding people to the late project makes it later but, come on, who reads such old books?

Since in this case all our projects are late we’d pull people from another part of an organization. That would make their life more miserable and their project more likely to be late and eventually they will reciprocate taking our people from our future projects in a futile attempt to save theirs. That would introduce more problems in our future projects. No worries, there will be payback time when we steal their people again, right?

It’s a kind of reinforcement loop that we can avoid with fewer concurrent initiatives. That’s a fourth win.

Finally, we can focus on economies of delivering our products or projects. A common sense argument would be to bring time to market as an argument in a discussion. Would we prefer shorter or longer time to market? The answer is pretty much obvious.

To have a meaningful discussion on that we may want to discuss Cost of Delay. How much it costs us to delay each of these projects. It may translate to the situation when we don’t generate revenues or the one when we lose the existing ones. It may translate to the situation when we won’t optimize cost or fail to avoid new costs.

In either case there’s an economic value of delivering the initiative later. In fact knowing the Cost of Delay will likely change the order of delivering projects. If we assume that the last project had the biggest Cost of Delay, the first the smallest (4 times smaller) and the middle ones the same in the middle of the spectrum (a half) we’ll end up building our stuff in another order.

The efficiency of using the teams is the same. The economic effect though is vastly different. This is the biggest win of all. Including all other effects we roughly cut down the total delay cost by two thirds.

The important bit of course is understanding the idea of Cost of Delay. However, this couldn’t have been enabled if we’d kept running everything in parallel. In such a situation everything would be finished at the same time – at the latest possible moment. In fact, if we avoid concurrent work even the ultimately wrong choice of the order of the projects would yield significantly better economic results than building everything at the same time.

What we look at is a dramatic improvement in the bottom line of the business we run. The effects of limiting a number of concurrent initiatives stack up and reinforce one another.

Of course, it is not always possible to delay start of specific batch of work or limit the number of concurrent projects to very low number. The point is though that this isn’t a binary choice: all or nothing. It is a scale and typically the closer we can move toward the healthy end of it the bigger the benefits are.

I’d love to get a beer each time I hear a story about management imposing a change on teams and facing strong resistance. It would be like an almost unlimited source of that decent beverage. Literally every time I’d fancy a beer I’d be like “Hey, does anybody have an agile implementation story to share?”

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

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

So how is it really with responding to changes?

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

We start with existing status quo that translates to a performance level. Then we introduce something new, which we call a foreign element.

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

After introducing a change performance drops.

It is kind of obvious. We need time to learn how to handle a new tool, practice, method or what have we. Eventually, we get better and better at that and we start seeing the results of promised improvements. Finally, we internalize the change and the cycle is finished.

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

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

What we really see is something much bumpier. It is bumpy already when we maintain status quo. It gets much bumpier when we start messing with stuff. It’s not only that rough average goes down but also worst case scenario goes down and by much more.

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

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

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

Some people aren’t ready to see, even temporary, drop in performance and once they face it they propose to get back to the old status quo. When facing a stressful situation many people retreat back to what they know best and the old ways of doing things is exactly what they know best. There are also those who are impatient and not willing to give people enough time to learn the ropes. The last group often includes managers who funded the change in the first place.

In either case the result, eventually, is the same. More resistance.

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

So what do we do?

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

One interesting caveat of the whole process is that a change is not always simply reversible. When we changed specific behavior and yet didn’t get expected outcomes reverting the behaviors may be difficult if not impossible.

For the sake of the discussion let’s assume we are lucky and the change is reversible. We are back to the late status quo and we simply wasted some time trying something new. Oh, and we built a stronger case for resisting the next change. We petrified the existing situation just a little bit more.

One reason why changes are reverted so often is the perceived risk of the change.

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

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

There is another dimension that is very interesting for the whole discussion. It is the scale of change. How much we want to change the existing environment: team, process, practices, etc.

We can imagine a series of small changes, each modifying the context only slightly. The whole series lead to a similar outcome as one big change rolled out at once.

We can call one approach evolutionary and the other revolutionary. We can use inspiration from Lean and call evolutionary approach Kaizen and revolutionary one Kaikaku.

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

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

What are the implications?

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

Kaizen on the other hand typically go with the changes small enough that we don’t destabilize the system nearly as much. In fact it is pretty likely that unpredictability introduced by each of the small changes will be almost invisible given that we don’t deal with fully predictable process anyway.

The risks we take with evolutionary approach are much more bearable than ones that we deal with rolling out one big change.

That’s not all though.

Another thing is how much destabilization lasts. In other words what is cycle time of change.

Big change, naturally, has much longer cycle time as it requires people to internalize much more new stuff. It means that exposure to the risks is longer. Given that the risks are also bigger it raises the odds that the change will be reverted before we see its results.

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

One last thing worth mentioning here is that so far we optimistically assumed that all the proposed changes have positive outcome. That is not always true.

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

It is not to say that Kaizen is always superior to Kaikaku. In fact both evolutionary and revolutionary approaches have their place. Stuart Kauffman’s Fitness Landscape helps to explain that.

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

The simplest and safest way to climb up would be to make small steps uphill.

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

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

Obviously, someone saying that wouldn’t be treated seriously. Well, not unless we are discussing a patient of a mental facility.

The solution is seen when we look at the big picture. If we moved to the slope of another hill we can get better than we are.

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

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

Of course, similarly to the case of J-curves the picture here is idealistic in a way that each change, be it small or big, is a successful one. In reality it is more of experimentation. Some of the changes would work, some not.

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

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

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

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

It means that each change can improve our situation in some dimensions and have an opposite result in others. We will have different combination of effects in different dimensions – some more desirable and some less.

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

I know the post got long by now (thank for bearing with me that far by the way). This is however the starting point for the discussion why introducing the change very often triggers resistance. It provides pretty good explanation why some many improvement initiatives fail. This is also one of my answers to the question why many agile or lean adoptions are doomed to failure from the day one.

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

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

You get what you measure. The old truth we keep forgetting about so often.

Story Points and Velocity

One relevant context to remember this is when we measure progress of project teams. The set that was wildly popularized along with Scrum is story point estimation, most typically with Planning Poker as a method to come up with the estimates, and measuring velocity. In such a set velocity, which simply is a number of story points completed in an iteration, is a primary measurement of pace.

I don’t say the whole set is evil. What is evil though is how it is frequently used. Story point is pretty much meaningless – the same story can be estimated 2 or 8 and both are perfectly valid sizes. This means that the moment someone starts expecting specific velocity they will get it. In fact, continuous improvement in velocity is as easy as pie. It’s known as story point inflation.

The same thing will happen when someone starts comparing teams basing on velocity.

And then there’s expectation for velocity to be predictable, which translates to low variability. If that’s the goal story point estimates will be gamed so velocity looks predictable.

How much does it have to do with any real sense of sizing?

OK, I hear the argument that these all are dysfunctions related to velocity. Fair enough. Let’s assume for the rest of this article that we are doing it right.

Measuring Progress

The problem is, that the whole activity of estimating story points doesn’t provide much value, if any. What Larry Maccherone’s research shows is that the best measure of throughput is simply counting the stories or features done.

Let me stress that: it doesn’t matter what size we initially though a story or a feature would be. What matters is that it’s either completed or not. That’s it.

Larry knows what he’s talking about. The data sample he had was from ten thousand agile teams, vast majority of them being Scrum teams. If there had been a quality signal in story point estimations and measuring velocity he would have seen it. He didn’t.

So even if we do the whole thing right it’s just a complete waste of time. Or is it?

Estimation

One part of Planning Poker, or any other discussion about story point estimates, is validating all sorts assumptions about a feature or a story. Another is addressing gaps in knowledge about the task.

These discussions can provide two valuable bits of data. Sometimes we realize that the chunk of work hidden behind a story is simply too big and should be split it. Typically it’s after someone provides input about complexity of a scenario.

The outcome of such a scenario would be simply splitting a story.

A different case is when we realize we simply don’t know enough to come up with any meaningful sizing. It may be either because we need more input or simply we are discovering a new land and thus our level of uncertainty is higher. The reason doesn’t matter.

What matters is that in such a case we deal with more uncertainty than normally thus we introduce more risk.

In both cases we get additional valuable information. Beyond that a discussion whether something is worth 5 or 8 story points is irrelevant.

No Bullshit Estimation Cards

That’s basically rationale for no bullshit estimation cards. I like to think of it as of “Story Points and Velocity: The Good Bits.”

Instead of focusing on futile discussion and potentially driving dysfunctional behaviors we get a neat tool that keeps few valuable parts of the approach. And you get a little bit of sense of humor for free.

By the way, there’s a more serious a.k.a. politically correct version too.

It saves time. It provides value. And most of all, it makes you focus on the right challenges.

And in case you wondered, you can get your own deck (or as many as you want really).

I’m a strong proponent of participatory leadership model where everyone takes part in leading a team or even an organization. A part of leading is making decisions. After all if all decisions still have to be made, or at least approved, by a manager it isn’t much of participatory leadership.

(Benevolent) Dictatorship

The most typical starting point is that someone with power makes all decisions. As a result commonly seen hierarchies are just complicated structures of dictatorships. As a manager within my small kingdom I can do what I want as long as I don’t cross the line drawn by my overlord.

Of course there are managers who invite the whole team to share their input or even distribute particular decisions to team members. There are leaders who use their power for the good of their people. It may be benevolent dictatorship. It is still dictatorship though.

This model works fairly well as long as we have good leaders. Indecisiveness isn’t a super-common issue and if it is there’s at least one person who clearly is responsible. Often leaders have fair experience in their roles thus they are well-suited to make the calls they make.

The model isn’t ideal form a perspective of promoting participatory leadership. If we want more people to be more involved in leading a team or an organization we want them to make decisions. And I mean truly make decisions. Not as in “I propose to do this but I ask you, dear manager, to approve this so that responsibility is, in fact, on you.” I mean situations when team members make their calls and feel accountable for them.

I’d go even further and propose that in truly participatory leadership model team members acting as leaders would make calls that their managers wouldn’t.

This isn’t going to happen with a classic decision making process.

Consensus

A natural alternative is a consensus-driven decision making process. A situation where we look for a solution that everyone agrees on.

This one definitely allows escaping dictatorship model caveats. It doesn’t come for free though.

Looking for consensus doesn’t mean looking for the best option, but rather looking for the least controversial option. These two are very rarely synonymous. Another issue is the tiredness effect. After a long discussion people switch to “I don’t care anymore, let someone make that decision finally and move on.”

Not to mention that the whole decision making process suddenly gets really time-consuming for many people.

While in theory consensus solves accountability problem – everyone agreed to a decision – in practice the picture isn’t that rosy. If I didn’t take active part in the discussion or my objections were ignored I don’t feel like it’s my decision. Also if the decision was made by a group I will likely feel that responsibility is distributed and thus diluted.

One interesting flavor of consensus-driven decision making is when people really care about the decision even though it is controversial. It’s not that they want to avoid participation or even responsibility. It’s just consensus is unlikely, if even possible.

Such a discussion may turn into an unproductive shit storm, which doesn’t help in reaching any common solution and yet it is emotionally taxing.

Advisory Process

There is a very interesting middle ground.

My pursuit of participatory leadership decision making became a major obstacle. I declined to use my dictatorship power on many occasions encouraging people to make their own calls. The answer for a question starting with “Can I…” would simply be “Well, can you?” That worked up to some point.

It builds the right attitude, it helps to participate in leading and it makes people feel accountable. The problem starts when such a decision would affect many people. In such a case we tend to retreat back to one of the previous models: we either seek consensus or look for a dictator to make that call for us.

Not a particularly good choice.

I found the solution while looking at how no management companies deal with that challenge. Basically, everyone acts as they had dictatorship power (within constraints). However, before anyone makes their call they are obliged to consult with people who have expert knowledge on the subject as well as with those who will be affected by the

This is called advisory process. We look for an advice from those who can provide us valuable insight either because they know more about the subject or because their stakes are in play. Ultimately, a decision is made by a single person though. Interestingly enough, a decision-maker doesn’t have to take all the insight from advisory process into account. Sometimes it is not even possible.

Accountability is clearly there. Healthy level of discussion about the decisions is there as well.

Constraints

The key part of going with such decision making scheme is a clear definition of constraints. Basically, a dictator, whoever that is in a given context, gives up power for specific types of decisions.

The moment a team member makes a call that is vetoed the whole mechanism is pretty much rendered irrelevant. It suggests that people can make the decisions only as long as a manager likes them. This isn’t just a form of dictatorship but a malicious one.

These constraints may be defined in any sort of way, e.g. just a set of specific decisions or decisions that don’t incur cost beyond some limit, etc. Clarity is important as misunderstanding on that account can have exactly the same outcomes as ignoring the rules. After all if I believe I could have made a decision and it turns are not to be true I will be disappointed and disengaged. It doesn’t matter what exactly was the root cause.

Setting constraints is also a mechanism that allows smooth transition from benevolent dictatorship to a participatory model. One super difficult challenge is to learn that I, as a manager, lost control and some decisions will be made differently than I’d make them. It’s better to test how it works with safe to fail experiments before applying the new model to serious stuff.

It also addresses a potential threat of someone willing to exploit the system for their own gain.

Learning the ropes is surprisingly simple. It doesn’t force people to go too far out of their comfort zones and yet it builds a sense of leadership across the board. Finally it provides a nice option for transition from the old decision making scheme.

And the best thing of all – it is applicable on any level of organization. It can be at the very top of the company, which is what no management organizations do, but it can be done just within a team by its manager.

I ranted on 100% utilization a few years ago already. Let me add another thread to that discussion. We have a ton of everyday stories that show how brain-dead the idea of maximizing utilization is. Sometimes we can figure out how it translates to work organization as well. Interestingly, what Don Reinertsen teaches us is that queuing theory says exactly the same.

As we go up with utilization lead time or wait time goes up as well. Except the latter grows exponentially. It looks roughly like that.

But wait, does it mean that we should strive to have as low utilization as possible? I mean, after all that’s where lead times are the shortest. This doesn’t sound sensible, right?

And it doesn’t make sense indeed. Cost of waiting is only one part of this equation. The other part is cost of idle capacity. We have people doing nothing thus they don’t produce value yet they cost something. From that perspective we have two cost components: delay cost related to long lead time and cost of idle capacity related to low utilization.

Of course the steepness of the curves would differ depending on the context. The thing is that the most interesting part of the chart is the sum of the costs which, naturally, is optimal at neither end of scale.

There is some sort of economic optimum for how much a system should be utilized to work most cost efficiently. There’s very good news for us though. The cost curve is the U-curve with flat bottom. That means that we don’t need to find the ideal utilization as a few percent here or there doesn’t make a huge difference.

We’d naturally think that the optimum is rather toward the more utilized part of the scale. That’s where the interesting part of the discussion starts.

We have pretty damn good idea how much idle time or slack time costs us. This part is easy. Now, the tricky question: how much is shorter lead time worth?

Imagine yourself as a Product Owner in a funded startup providing an online service. Your competitor adds a new feature that generates quite a lot of buzz on social media. How long are you willing to wait to provide the same feature in your app? Would keeping an idle team all the time just in case you need to build something super-quickly be justified?

Now imagine that your house is on fire. How long are you willing to wait for a fire brigade? Would keeping an idle fire brigade just in case be justified?

Clearly, there are scenarios where slight differences in lead time are of huge consequences. We don’t want our emergency calls to be queued for a couple of weeks because a fire brigade or an ambulance service is heavily utilized. In other words steepness of one of the curves varies a lot.

Let’s look how different scenarios change the picture.

This sets the economically optimal utilization at very different levels. There are contexts where a lot of slack is perfectly justified. The ultimate example I can come up with are most of armies. We don’t expect them to be fully engaged in wars all the time. In fact the more slack armies have the better. Somehow we don’t come up with an idea that if an army has no war to run we better find them one.

Of course it does matter how they use their slack time, but that’s another story.

We don’t have that drastic examples of value of slack in software industry. However, we also deal with very different steepness of delay cost curve. Even if we don’t expect instant delivery we need to move quicker and quicker as everyone else does the same.

The bottom line is that our intuition about what is the cost of wait time (delay cost) is often flawed. This means that even if we are able to go beyond the myth of 100% utilization we still tend to overload our teams too much.

Oh, and if you wondered, at Lunar Logic our goal is to keep team’s utilization between 80% and 90%.

I’ve heard that question quite a few times after I shared my feedback with somebody: “What am I supposed to do with such feedback?”

The question may imply that feedback e.g. wasn’t “actionable” or something. Anyway, I have an answer for that. It goes:

“Whatever the hell you want.”

Yup. Exactly that. In fact this is precisely what I’d love you to do.

As the opposite to: getting defensive, explaining yourself, finding excuses, bringing other interpretations, and so on and so forth.

Feedback is not an attack. You don’t need to defend yourself. It isn’t an interrogation either. You don’t need to explain yourself. And most of all it isn’t a goddamn appraisal. You don’t need to maximize the score.

It is feedback. I’m sharing some observations and opinions that somehow relate to your work, actions, behaviors, attitude, etc.

I don’t intend to change you. I want to provide you with more information so that your decisions about your further course of action are informed better. You can disagree with the part or the whole of the message you get. You can interpret it in a vastly different way. You can confront that with other feedback that is contrary to mine. That is all just perfect. You can ignore it altogether and I’m still fine with that.

Remember? Whatever the hell you want.

The reason is I know it is subjective. No matter how much I try to make it factual it is always about interpreting facts. And I don’t try to make it purely factual. In fact, the system in knowledge work is built of people and interactions between these people. How objective can “facts” about interpersonal relationships be? Is there even an objective truth there? Or is it rather a combination of interpretations that can be more or less aligned one with the other?

So no, I’m not trying to convince you that my point is even valid. It’s how I perceive specific situation and how I feel. Oh, it isn’t factual, someone would say. Well, the fact is that I perceive and I feel so and so. Do you want to discuss with such a fact? Didn’t think so.

I am well aware that my perceptions and my feelings aren’t universal truths. That’s why it is you who decide what to do with the feedback or whether to do anything at all.

There is the other part of the story. I sometimes receive feedback and I’m like “Thank you. I’m not going to change that.” What I see as a reaction is that someone is either discouraged or even pissed off with my reaction.

I mean, they did expect me to comply with what they shared with me. I don’t differentiate here feedback on work I do from feedback on my behaviors. It’s just, for whatever reasons, I decide that I don’t want to change that specific thing.

That doesn’t make me any less grateful for feedback I got by the way.

It’s just that now we turned the tables. Now it’s: Whatever the hell I want.

If you want to make me compliant with whatever just make it explicit. At least we’ll have common understanding.

Feedback’s role, the way I perceive it, is not compliance. It is providing information about one’s behaviors, actions and attitudes and their impact. It is, as its name suggests, about feeding one back with information, not about changing one or making them doing what somebody else want them to do.

If you give me feedback with a clear intention to change me or even worse to make me do what you want you are likely to end up being disappointed.

It will happen despite the fact that I treat that feedback as factual and fair. It is factual since fact is that you think and feel whatever you think and feel. It is fair for the very same reason.

At the same time it is subjective. Objective feedback, as long as it touches interactions between people, is a mirage. Or an oxymoron. Stop pursuing objectivity. To make it clear: it doesn’t make such feedback any less valuable.

Once we understand that it enables the whole new level of discussing feedback both ways.

Ultimately it’s: “I share that with you. Do whatever the hell you want with this.”

And: “Thank you for sharing. I will do whatever the hell I want with this, indeed.”

Only then it truly is valuable feedback.

Minimal Viable Product (MVP) is such a nice idea. Let’s build something that is as small as possible and at the same time viable, which translates to “provides value and thus make sense to build it.” Two adjectives in a mix where one counterbalances the other and vice versa.

Since I currently run a web software house I hear the term MVP very frequently. Or to be precise I hear the term MVP being abused very frequently. On some occasion the viable part would be ignored. Much more frequently though the way people understand MVP has virtually nothing to do with the minimal part.

During the early discussions about products our potential clients want to build I would typically ask about a business case behind a project or an app. It’s not about what it is that someone wants to build. It’s about why it is worth building that thing in the first place.

Note, I’m not judgmental. We contributed to better or worse ideas but I don’t reserve the right to know what’s worth building and what’s not. In fact, my questions have a very different purpose. What I want to achieve is to learn the value behind the app so that we can have a meaningful discussion about stuff in a backlog.

Now, this is the part where typically I’d really like to have people read Lean Startup before they are even allowed to talk to any software shop about building their product. And then, read it once again to understand what they are reading in depth.

The reason is that most of the time I can instantly come up with a batch of work that is one third, one fifth or one tenth of what was labelled an Minimal Viable Product by a potential client and it would still validate a business hypothesis behind a product. It likely means that with a bit of effort and better understanding of the context our clients would be able to cut it down way further than that. It may mean that they’d be even able to validate the basic idea without writing any software at all.

These so called “MVPs” wouldn’t recognize a real Minimal Viable Product even if it kicked them in the butt.

A sad part is that most of the time discussion around what really is minimal is futile. While I can provide my insight and encourage to learn more about the topic an argument often boils down to “we really need to build it all because, well, we don’t believe anything short of that would work.”

The long story short, I believe that MVP is in the top 5 most abused terms in our industry. By now referring to MVP is mostly meaningless unless you ask a series of questions to understand what one means by that. We could have skipped he MVP part, have the same discussion and we’d save a little bit of time.

That’s why I believe we need another frame for discussing what the initial increment of a product is.

What I caught myself on a number of times was proposing our clients a different constraint. Let’s step aside from discussing what is minimal and what is viable. Let’s figure out which features will be the part of the product in every single, even most crazy, scenario that we can think of. And I really mean every single one of them.

What I try to achieve with this discussion is to find the set of features that is a common denominator for all the options of building the product. There’s always something like that. A core process that the app support. A basic idea that the app is built upon. An ultimate issue that the app attempts to solve.

What I don’t expect is to see the full solution, even the most basic one. It would be an MVP on its own and we’d be back to the square one. What I expect is just a bunch of bits and pieces that are required to eventually build the app.

It is neither minimal nor viable.

It is indispensable though.

There are a couple of reasons to do that. The first one is that it reframes how both parties, the client and us, think of a product. We don’t try to settle on what is viable and what is minimal. We simply go with something that we know will be useful.

The other one is that it addresses the huge challenge of building a relationship. In fact this part goes really deep. It typically starts with a question how much building something would take. Some sort of an estimate. Well, it’s another thread. I’m not fundamentally against the estimates and see value in understanding generally how much something would take. At the same time I acknowledge that humans are simply not well equipped to estimate as we can’t learn to assess stuff in abstract measures. At the end of the day though, the smaller the batch size of work the smaller the potential risk and the smaller the estimation mistake.

In other words the smaller the initial batch of work the easier it is to start working.

It is true from another perspective as well. The most important modifiers of the cost of building a product in a client-vendor scenario isn’t anything related to the product itself. It is the quality of collaboration. It’s about both parties feeling like they’re the part of the same team. It’s about short feedback loops. It’s about working together toward the goal.

Unless it is about lack of transparency, distrust, and exploiting the other party.

The tricky part here is that you don’t know where at this spectrum you are until you start working. Building the smallest possible batch of work together pretty much gives you all the knowledge you needed. Seriously, you don’t need more than just few weeks to get a good feeling where collaboration part is going.

That’s why this the idea of Minimal Indispensable Feature Set is so useful whenever more than a single party is involved in building a product.

Minimal Indispensable Feature Set is perfectly aligned with building an MVP. In fact it is a subset of an MVP. At the same time it addresses the part of the setup that goes way beyond simply defining of what product is.

We live in a world where more and more frequently the building part is outsourced to another party. Getting the collaboration right at least as critical as getting the product idea right.