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

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

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

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

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

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

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

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

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

Recipes are useless.

OK, OK. Almost useless.

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

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

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

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

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

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

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

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

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

There’s a fundamental flaw in how we manage project portfolios. What typically happens is we focus on estimated cost of work and expected profit. After all these are parameters that decide whether a project is successful or not.

Estimated Cost and Expected Profit

There’s whole ongoing discussion on how to estimate, when estimates give us value and whether we should estimate at all. A bottom line is that getting estimates right is extremely hard.

A problem is that, even if we got our estimate right, the scope of a project will change anyway thus it will affect the original estimate. Few companies would bother to change the estimates but even for these few there already are some numbers in contracts and budgets that won’t change anyway.

It seems that one of the critical numbers we use to make decisions about our portfolios is vague.

By the way if we are in the context of fixed price contracts it automatically means that the other number—expected profit—has changed as well.

It’s not a rare case to see these values changing drastically. I can come up with examples from my experience when, because of misestimate or increasing costs instead of margin of 30-60% the project ended up costing a few times more than the revenue a company got for doing it. Not only wasn’t it even close to breakeven but the company paid a huge toll in terms of both direct costs and lost opportunities.

A partial solution to that is transiting to time and material contracts where the revenue is a derivative of effort invested in building a project. While that definitely helps to avoid direct loses it doesn’t really fix the variables. The time span of a project can be changed thus the absolute numbers will be altered.

What You See Is All There Is

Even if we potentially could get our number right it wouldn’t really help. A root cause for that is a concept described by Dan Kahneman: What You See Is All There Is (WYSIATI). Human brain doesn’t look for data points other than those readily available. In other words if we define existing and potential projects from a perspective of estimated cost and expected profit these will be the main, or even the only, inputs for decisions on starting new projects.

This has very sad consequences. In neither case we assume that in normal circumstances we will be working on unprofitable ventures. If we are in the world of fixed price contracts the final price will directly depend on an initial estimate.

We’ve already discovered one painful dependency between an estimate and a profit. While costs are changing the contract terms remain the same affecting profits. It is even worse than that. The price was calculated based on the same estimate most likely by multiplying it be a factor of expected margin. Unfortunately humans are crappy at estimation.

And don’t even get me started about all those dysfunctional situations when there’s a pressure to reduce an estimate because a client has a limited budget or something.

In either case, a picture of all the potential projects will be rosy. We won’t allow it to be different than that. We will tweak the numbers back and forth until they fit the rosiness of the picture.

The ultimate issue of this is that, because WYSIATI kicks in, our decisions about starting new projects will be overly optimistic and heavily biased toward perceived attractiveness of our endeavors. A simple fact that it has very little to do with the real outcomes of projects or our appalling track record with assessing attractiveness doesn’t change it. What you see is all there is.

Overcommitment and Multitasking

The end result of this bias is easy to predict. Since all things seem to be overly attractive we tend to start too many projects. Eventually, and pretty soon, we are overcommitted beyond the point where we can comfortably finish everything before agreed deadlines.

Even in the cases when a flash of sanity keeps us from jumping off the cliff and stop one step before there’s usually not nearly enough slack in the system to account for any emergency that would happen.

Of course there’s no plan whatsoever in case our initial estimate was wrong and we need more effort to finish a project, because we’ve proven to be perfect estimators in the past and never got anything wrong. Oh, wait…

What does happen next? Expediting of course. When heroics within a team is not enough we pull people from other teams just like there was no tomorrow and they weren’t doing meaningful work on other committed projects. Anyone wants to guess what happens in the projects that we cannibalized to save the other one?

More of the same vicious cycle.

Not only such work is ultimately inefficient but it also hits sustainability of the business as it damages relationships with clients.

Informed Decisions

To reverse that cycle we need to go to the first place, the point of commitment, and change the drivers that influence our decisions. Bearing WYSIATI in mind, what we need is access to meaningful bits of information.

We need to know how our current commitments affect our capabilities over time. In other words we want to know which teams are working on which projects. Not only now but also in reasonable future. What reasonable future means will of course vary depending on a context.

How would a new project fit available capabilities? Do we have people with the right skills and knowledge available? When are they available? How much slack do we need to be able to respond to uncertainty in existing endeavors?

We need to know, at least roughly, what is Cost of Delay for new projects. Is it possible to delay start of this project for a month? How about longer? What kind of costs, or lost future gains will it incur?

What is value of a new endeavor? Is it money that earn only? How about long-term relationships with a client or bringing more financial safety thanks to a steady flow of work?

By the way, when we are talking about value, it is crucial to remember that value for our organization doesn’t equal value for a client. Of course, the more aligned these two are the better, but it’s almost never an ideal fit.

What are the risks attached to a project? How sure can we be about all the assumptions we make?

These are all crucial factors that we should be taking into consideration when making a decisions about starting any new project. If we don’t have them at hand, as a result of WYSIATI, they will be ignored and we’ll be back to our rosy, overly optimistic and utterly harmful view of portfolio.

Bad news is that to do better we need pretty broad understanding of the mechanisms that drive us sideways. Good news is that once we know that the change isn’t that painful. Focusing on different kind of data will alter decision making process on a portfolio level.

When I first discovered how Kanban in general, and Work In Progress limits specifically, worked as a catalyst for deep systemic improvements it was like an epiphany. Kanban, which at the beginning seemed like a neat and light-weight process management tool, proved to be far more than that. Not only was it helping to clean up the mess short term but also steered sustainable changes in the long run.

When Tools Fail

These were my early days with Kanban. Since then I’ve seen a lot of teams applying Kanban in all sort of ways. A thing that surprised me was that, even among the teams that achieved a certain level of maturity of the adoption, the results were mixed at best.

Some of these teams are doing great and the early results I’ve seen no longer stand as exceptional. Most of them though weren’t even close. Clearly the magic of WIP limits that induce slack time, which in turn results in a steady stream of sustainable improvements, is neither obvious nor granted. There has to be something else.

No curious person, and I tend to consider myself one, would pass on this observation without a second thought. No reasonable person, and I tend to consider myself one, would keep sharing the success stories ignoring all the counterexamples.

Of course, one obvious reaction would be that the teams that failed to achieve exceptional results got it wrong. In fact, if you want to look for such attitudes among our thought-leaders it is pretty common. The method works, only those unskilled folks mishandled it, they’d say. No wonder these teams still crawl in the misery, they’d add. Actually, they sort of deserved it by not doing the thing the way we preached, the thought-leaders would sum up.

Fortunately I’m not a consultant or an owner of a business that depends on popularity of a specific approach. I consciously chose to stay in practitioners’ camp. This leaves me with no neat and simple (and wrong) answer to the puzzle.

A nice thing is that, given enough experience, we will stumble upon such puzzles on and on. Gemba walk which seems to be mentioned in every other important management book from The Goal to Lean Startup was another such realization for me. Failed stories of applying Kaizen boards and holding Kaizen evens was one more. Organizations struggling with Improvement Katas is probably the most recent one but the list goes on.

Cargo Cult

A cargo cult is, in short, defined as mechanically following practices or rituals without understanding why they worked in the first place and expecting the same results as achieved originally. In case you wondered it doesn’t really do miracles. In fact, the only known successes are creating prophets of cargo cults.

A common observation, and a sad one, is that our efforts with applying different methods are surprisingly close to that definition. Even worse, such attitude is often encouraged. By the book applications of any tool means spreading the disease. It is like saying that we need to trust an enlightened prophet who guarantees two-, three- or fourfold productivity increase as long as we do exactly as they say.

Don’t get me wrong the other end of spectrum, which is NIH syndrome, is equally bad. If NIH syndrome was a good guidance it would mean that entire management knowledge is useless because no one in the world was exactly in the context such as ours.

In either case the missing bit is understanding the underlying principles behind the tools. One exercise I typically start my Kanban training with is asking a group about practices and principles. While they always know a few practices, sometimes most or even all of them, almost no one remembers any of the principles.

By the way, the same thing is true when it comes to Agile Manifesto. Everyone knows “this over that” part but most of the time that’s pretty much it. It seems like we haven’t understood what we read. Alternatively, we never read that thing at all but heard about it somewhere where they used only the marketing part of the manifesto on a slide.

It is kind of like knowing how but having no clue whatsoever why we’re doing something. And then we wonder why we fail so frequently.

Understanding

I know that belief in universal solutions has certain appeal. It doesn’t require us do to the hard work of trying to understand what is happening around. I don’t think there’s a shortcut here though. I mean one can get lucky, as I did during my early adventures with Kanban, but this experience can’t be easily translated to different contexts.

Now, certain techniques give us a promise of help in facilitating the understanding how we work. Visualization and Gemba walks come as obvious examples. However, before we rush to apply them we may want to ask ourselves a question do we understand how and why these techniques work. Seriously. Even something seemingly so straightforward as visualization may be a waste unless a team understands that one of its biggest powers is reflecting current condition and current process and not projecting an expected state, or that too much burden on keeping it up to date will render it irrelevant, or that that too many objects on a board makes it incomprehensible and, as such, pretty much useless.

I think the most common practice across all agile teams I know, no matter which method, if any, they follow, is a daily standup meeting. I believe I can safely assume that vast majority of agile teams have their daily standups. Now, how many of them asked themselves why they are doing that? Why are standups a part of a canon of Agile and Lean? Why were they introduced in the first place? And why, the hell, are they so prevalent?

It doesn’t seem to bug many people. That’s interesting because they may be just following a cargo cult and maybe they could have been doing something much more useful in their context.

Take pretty much any popular practice, technique or method. The same story again. We don’t understand why the tools we use work and simply blindly apply them. Doesn’t that fulfill a definition of a cargo cult?

By the way, I think that one of significant contributors to the situation we have here is pretty common perception that Shu-Ha-Ri model universally applies in our context. A basic assumption that when being on Shu (apprentice) level we should do as a master say because we are incapable of understanding what we are learning doesn’t seem to be an extremely optimistic view of our teams.

Call me lucky but most the time I worked with teams that are perfectly capable of better understanding how the work gets done and how specific tools contribute in that. The missing bit was either knowledge itself or curiosity to get that knowledge.

A side note: the higher up we go through hierarchy the less of that curiosity I see, but that’s a bit different story. Most of time talking about tools we are in the context of teams, not VPs and execs.

A Fool With a Tool is Still a Fool

Any time a discussion goes toward tools, any tools really, it’s a good idea to challenge the understanding of a tool itself and principles behind its successes. Without that shared success stories bear little value in other contexts, thus end result of applying the same tools will frequently result in yet another case of a cargo cult. While it may be good for training and consulting businesses (aka prophets) it won’t help to improve our organizations.

A fool with a tool will remain a fool, only more dangerous since now they’re armed.

Not to mention that I don’t think orthodoxy is anyhow helpful in this discussion.

By the way: as much as I didn’t want to engage the recent TDD versus anti-TDD discussion you may treat it as my take on it.

If you are in broadly understood context of Agile you eventually has had to hear about being hyperproductive. Sources reporting a few hundred, or even as much as more than a thousand, percent productivity improvement aren’t unusual. In fact, 200% improvement seems to be “guaranteed” by some.

That’s great! Good for them! They’re going to get hyperproductivity badge or something. Yay!

What Hyperproductivity Is

Let’s start with the basics though. What is this whole thing? When a team becomes hyperproductive? How much do they have to improve? Oh, and by the way, if a super-crappy team improves three times and guys that were already great only by 20% would that mean that hyperproductivity was reached by the former, the latter, or both?

The most common metric I hear about in the context of hyperproductivity is velocity. Actually, I consider using velocity to measure productivity evil or dumb. How much should my team improve? By the factor of three? Nothing easier. Oh, and by the way, we don’t use our estimation poker card worth 1 that often anymore.

Note: I don’t deny teams improve. I merely point that stating so purely on a basis of velocity improvement is naive at best. There are so many potential dysfunctions of such approach that I don’t even know where to start. How the scope of work is split into individual tasks? What is a distribution of point estimates? How has it changed over time? What do we understand as a task in the first place? How do we account for rework?

In other words without understanding a specific context mentioning hyperproductivity is meaningless. Just a marketing fad, which it might have been in the first place.

Efficiency As a Goal

Even if we agreed on a reasonable proxy for measuring productivity there’s a bigger problem ahead. We are not in a business of writing most code, delivering most features or achieving best velocity. If you think you are, go talk to your clients, but this time try to actually listen to them.

If you spend about 5 minutes looking for sources pointing how notorious software industry is in not building the right stuff you may change your mind. Is a half of the stuff we build utterly useless? How about two third? Oh, and by the way the rise of the methods that are literally aimed to avoid building things unless we know we’re going to need them tells a story as well.

So yeah, focus purely on productivity and you’re going to achieve your goal:

Processing waste more effectively is cheaper, neater, faster waste.

Stephen Parry

The most painful problem of software industry is not efficiency. If it was, we’d already be in haven, given how much easier it is to build a software app these days than it was a couple decades ago. The problem is we are building wrong stuff.

We may as well be efficient, but unless we are effective in the first place, i.e. doing the right thing, there’s no glory waiting for us.

How We Create Value

This brings me to the utter failure of pursuing hyperproductivity. Let’s (safely) assume that our goal is to deliver value to our clients. We do that by building stuff. Except the value almost never is clearly defined. In almost every case software development is a knowledge discovery process.

This has some serious consequences. If we go by this assumption we may take all the functional specifications with a tongue in a cheek. It’s just a sketch of a map and most of the time not even an accurate sketch. This also means that amount of artifacts, like code, features, etc., we produce is not nearly as important as figuring out where exactly the value is, which bits and pieces we should build and which should be ignored.

This happens when we discuss the features, look for solutions, research options, prototype, A/B test, change stuff back and forth to see what works. This happens when we don’t score on velocity or any other productivity metric.

But wait, to become hyperproductive we should rather avoid that…

That’s exactly why I don’t give a damn about hyperproductivity.

I use to say software development is a happiness industry. We thrive only as long as our clients are continuously happy. We don’t make them happy by delivering more stuff. We make them happy by delivering stuff that has value for them and their customers.

If I got a dollar each time I heard someone mentioning that they’d like to get more feedback I would be filthy rich by now. Heck, if I got a dollar each time I personally said that I would still got a decent sum. Most of us do want and like to get feedback. Most of us would love to get more of that.

There’s obviously one thing to consider, which is what kind of feedback and received in what context is most useful for us. I’ve heard a lot of theories on that. One example is that we should always focus on positive or supportive feedback as people would improve their weaknesses subconsciously while they’re working on their strengths. Another is infamous feedback sandwich, which tells that each critical bit should but in the middle of two supportive ones. There are dozens of these.

On one hand there’s a bit of truth in each. On the other I call bullshit.

I don’t believe there’s a single, universal way of delivering and / or receiving feedback that works in majority of cases. Personally, while I like to hear positive feedback as it makes me feel good, I really learn when I get critical feedback. In fact, it doesn’t even have to be very constructive or factual feedback; I typically can make much sense out of non-constructive opinions too. And I don’t give a damn whether you add a sandwich to the mix.

There are better ways of delivering feedback when we think about an individual context, but there is a universal answer in a general case. This means that the most useful feedback should be adjusted to the person who receives it. A nice thing is that we can tweak the situation so we get what works for us.

If you learn from feedback in a similar way that I do, meaning that critical feedback is what makes you change, the following part is for you.

I learned about the idea of ritual dissent some time ago. Back then I didn’t even know that it is Dave Snowden who should be attributed for creating it. Anyway, the basic idea is to create a situation where a group tears an idea apart looking for all the potential risks or holes. After a spokesperson presents an idea while everyone else remains silent, there’s a part when everyone dissents the idea while a spokesperson remains silent.

There may be two goals in doing that. One is obviously improving the idea itself by making it risk-proof. The other part is that ritual dissent can be treated as a listening exercise. It’s not that easy to remain silent when someone tears your idea apart. At the same time this is what differentiates it from a futile discussion full of personal opinions.

So here’s an idea: if you look for critical feedback you can use the same pattern in a personal context.

No, it’s not a theoretical idea. I’ve done that.

It hurt. A freaking lot.

And I got more of what I wanted in half an hour than over the course of past year.

And it was awesome. Once emotions wore out, that is.

The thing is that adopting ritual dissent in personal context is, well, very personal. I was asking to be criticized. In fact, not-critical feedback was forbidden. No matter how much I learn from critical feedback it was nothing pleasant.

I would even consider that idea as “don’t try that at home” one unless one has self-awareness in terms of how they’re going to react for such critique. Having a psychologist around when doing that wouldn’t be a bad idea.

There are a couple things that make it work but two are essential. One is trust. I don’t say that everyone needs to fully trust a person being dissed. What is full trust anyway? However, there has be a decent level of trust so that anything that gets said won’t be used again anyone in any way. It may make the whole thing a bit tricky especially for managers or leaders where some sort of power relationship is involved.

At the same time there’s a lot of followership. Once a few people who feel safe start dissenting others join. Especially when they see that a dissented person doesn’t break the rules and keeps the mouth shut.

Another thing that makes personal ritual dissent work is listening, which is an inherent part of the exercise. It is a double-edged sword. On one hand the dissed person remains silent so the whole thing doesn’t turn into futile discussion. On the other the silence creates the pressure on the group. Someone eventually has to speak up even if it means going out of their comfort zone.

An interesting thing is that it’s nothing pleasant on either end. The exercise, which we run mid-day, was basically a killjoy. At the same time it spurred a lot of spin-off discussions afterwards, which is a reason why I wouldn’t do it at the very end of a day.

The best part is that getting critical feedback is not the ultimate value of the exercise. Since it creates a lot of tension and moves people out of the comfort zones it breaks some mental barriers that people had, thus makes sharing feedback later way easier.

After all sharing one critical opinion is nowhere close to dissing someone collectively for half an hour in a row.

Finally, some of feedback won’t be really addressed to the person who asked for a personal ritual dissent. It may be formulated in a way as it was so, but the real addressee would be somewhere else in a room and hopefully they’d get it too.

So if feeling like shit for (at least) a few hours is a price you’re willing to pay for a ton of valuable feedback, this is an idea for you. Would you dare?

A theme of scaling Agile, or Lean for that matter, is all hot these days. You will hear it all sorts of contexts: as broad as Agile and as specific as one of the methods we use. No wonder. It sells.

You can tell that looking at tracks at Agile or Lean conferences. You can tell that looking at a rise of approaches that specifically aim at the big scale as their main target (SAFe, anyone?)

The interesting part of the whole dispute is how rarely we question scaling up strategy. I mean it seems to be some sort of unquestionable paradigm and when you decide to go against that everyone looks at you as you were an alien. I sometimes feel like rolling out a huge program to introduce Agile or Lean in the whole organization was the only thing there was for big companies.

How does it work for us so far? Not so well. We don’t have lots of success stories and those few that are available seem to be share at pretty much every Agile or Lean event there is. This tells a story about our success rates with scaling agile too.

Unscaling strategies are almost never mentioned in the dispute. It is so despite the fact that we actually know at least a couple of different approaches we can use there.

One is skunk works. The basic idea is to create a group within a company that operates pretty independently on the rest of the organization. This creates an opportunity to try out a lot of stuff that would be hard to implement in a broader context. At the same it creates an environment of much smaller scale.

Applying Lean Startup within a big organization goes along the same lines. On the top of a product development strategy we create a context of work that is autonomous and that operates in small scale.

Quite a different approach is when an organization decides to find a partner to outsource some of their work to. With such a situation one thing that is easily done is scaling the context down. A difficult part is to find a partner that would live be the right values and employ the right practices. But then again, it may be used as a viable unscaling strategy too.

Interestingly enough, such approaches are rare. One exception may be outsourcing. However, outsourcing done in a common way has nothing to do with scaling down and very frequently criteria used to choose an outsourcing partner only make the whole situation worse. Believe me, I’m actually in this business on a receiving end so I’ve heard all the motivations for sending the work near-shore or off-shore.

If you wonder why unscaling is so unpopular you aren’t going to be surprised with the answers. Either of these scenarios means losing control and that is something that management is generally allergic to. Also to make it work you need trust as high autonomy is one of key parts of the setup. Finally, there’s a risk of doing something not exactly in a standardized way which may produce unpredictable outcomes.

Have I just said between the lines that one of the main drivers of scaling up Agile and Lean is complacency? Oh well…

Anyway, unscaling strategy not only makes it much easier to adopt Lean or Agile but at the same time it enables fresh ideas as many constraints are typically relieved. Not to mention that it goes along the lines of autonomy, mastery and purpose which drives individual motivation.

So the next time you hear about scaling Agile why not consider unscaling it?

Most change initiatives fail. How many of them? Well, let’s see.

In 1995, John Kotter published research that revealed only 30 percent of change programs are successful. Fast forward to 2008. A recent McKinsey & Company survey of business executives indicates that the percent of change programs that are a success today is… still 30%

This is from a McKinsey report. How about different sources?

According to international management consultants Bain & Co, 70 to 90 per cent of organizational change initiatives fail.

Now, obviously these statistics receive some criticism. After all, what is a change initiative? What is a success? My point is that what we see is that in different context we suck big time at improving how we work.

What’s more we are not improving really. Over the course of past 15 years we’ve seen a huge rise of the methods and approaches that are specifically aimed toward driving the change management.

Agile proposed a neat value container quickly filled with specific methods that should change and improve the way we work. Lean offered a thinking pattern focused on continuous improvements. Both are more and more frequently considered table stakes than game changers. Why nothing is changing then?

First, let me make a bold observation: neither Agile nor Lean seem to be making a difference. In fact, that’s not only my observation. Daniel Mezick points that:

If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, “freestanding” agility.

We have to be doing something wrong. Dave Nicolette offers some ideas what that might be. Anyway with such a wild popularity of Agile and Lean we should expect to do better than that. The problem is that most of the time we don’t even try to understand what made them work in the first place.

That’s a sad observation, but most of the time when I hear an Agile or Lean experience report it simply covers methods, practices and tools. The problem is that neither of these is pivotal in any change initiative. Basically, adopting practices and tools is simply a cargo cult. That’s not going to work unless there’s something more, the same way as it didn’t work for the Pacific tribes after the World War II.

In agile context we often mention values as the missing bit. I sort of agree with that. Sort of because the way Agile Manifesto is formulated it creates false dichotomies, yet it points us the right direction.

There’s a problem with values though. You don’t introduce values simply stating that you have them. You don’t incept them through mission statements and stuff. By the way, do any of you know value statement of your org by heart? Values are derivative of everyone’s behaviors and attitudes, thus they are a result of organizational culture.

There’s one more layer to that. Values can’t be inconsistent with the culture. Otherwise authenticity is gone and your claims about values have little to do with reality.

In other words a company can’t adopt Agile Manifesto simply by stating so. Not a surprise that change initiatives around Agile so frequently boil down to methods and tools. Not a surprise they fail at a high rate.

We see the same story with Lean as well. The bits that get traction are tools and techniques. It is so often when I see teams acting like limiting work in process, doing Gemba walks and having Kaizen boards was everything there was to improve continuously.

It’s not going to fly, sorry. We are back to organizational culture and everyone’s everyday behaviors. What do people do when they see an issue? Do they feel empowered to do whatever the hell they believe is the right thing to do to fix that issue? Do they even know what is the ultimate value they produce so they get good guidance on what is an issue in the first place?

These behaviors tell a lot about the culture. Unfortunately most of the time answers for the questions above suggest that there’s no freaking chance to make the tools work the way we intend them to. Typically we see over-constrained, siloed organizations where one neither knows what is the right thing to do nor has courage to go beyond the constraints.

I keep getting flak for bringing this up over and over again but I will do it once more.

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

Grace Hopper

Grace Hopper’s famous words are, in my opinion, the essence of the bit we are missing when introducing Lean or Agile to our organizations. That very bit is responsible for the appalling rate of success of change initiatives.

You can have all the hot tools and practices in place but when your people are driven by fear of consequences of their actions nothing will change. “Fear” may sound harsh but that’s what it is. It doesn’t mean that changing status quo by a tiny bit scares the crap out of me. It’s enough that I start thinking about potential consequences, what my bosses would think about that and whether they would even be happy. This is fear too.

When I think about the situation from a perspective of my experience as a manager I’m not surprised. I mean, really, promoting this whole “don’t ask permission” attitude is going to backfire on you on occasions. What’s more it means giving up control. Even worse, it assumes trust. It assumes trust to everyone, not only to few trusted people. Now, this is a huge leap of faith management has to take.

If you are thinking about continuous improvement or making your change initiatives work start with this leap of faith. If you can’t make it work don’t bother with all the tools, methods, practices and stuff. It’ll be just a waste of time. And the best part is that to make this work leaders have to start with themselves.

Only then you can dream of influencing culture so that it supports the everyday acts of leadership on all levels. If you got it right you may actually start thinking about all the helpful stuff you can introduce to keep the changes running. In fact, it’s pretty likely that you won’t need so much guidance as lots of them will emerge.

Oh, and if you wonder whether that change among leaders and managers is easy, well, it involves lots of pain and suffering. It is against of what we’ve been (wrongfully) taught for years. Sorry.

Few of us have comfort not to worry, or think, of changing a job ever again. If you’re not one of those few, this post is for you.

I have easily gone through way more than a hundred of exit interviews. No, it doesn’t mean that I changed job that many times. This means that so many people left my teams. Nothing to brag about, I guess. Anyway, if there’s a reason for leaving one’s job I’ve heard it. And I’ve heard it from a person who I knew and worked with for quite a while.

Obviously, more often than not I tried hard to keep people around and missed those who decided to leave. This wouldn’t make me an objective adviser at a time. However, from a perspective of time, once what had been about to happen already happened, I believe I can go beyond emotions and biases and be pretty objective.

There’s one thing that I noticed in my attitude when I talk to people about leaving. I feel and act differently when I try to keep on board someone who I believe may be making a good decision than in cases when I’m pretty sure they are making a mistake. While I don’t think any of you would find my feelings even mildly amusing, what is interesting is that my compass seems to be working surprisingly well.

So how the hell do I sense whether changing a job is a good idea or not?

It’s pretty much one thing. What’s more it sounds obvious. Surprisingly enough people very rarely follow the hunch.

It’s all about how values of an organization one is about to join are aligned with their own values.

Yup, that’s it.

I mean, seriously. Ask people what they value. It’s an individual thing so they’d come up with all sorts of stuff, like respect, safety, trust, transparency, challenges, health, happiness, authenticity, quality, learning, perspectives and whatnot. Interestingly, very, very few people I know would say “more money” and in such cases they’d likely have pretty good reason for that (which is fair enough too).

A nice thing is we can get pretty good hints whether these values are respected and embraced at our workplaces-to-be.

“You can’t know” one would say. Well, you can. It’s enough to realize one thing. Every publicly or semi-publicly known action of a company is emanation of how it operates inside. In other words if you want to know what is valued in any given org just pay attention to how that company acts publicly.

Are they worth of trust as a business partner? Why should they be as an employer? Do they care about well-being of their clients? Why should they care about yours? Do they respect any partner they work with? If not, why would you assume their respect would be extended to employees?

I don’t say that without a reason. It’s not a rare occasion when there’s a value match or at least there’s nothing that would indicate the opposite. At the same time I’ve seen way too many bad decisions ignoring the obvious hints. As you may guess it didn’t work very well.

So here’s my advice: ask yourself what is important for you. If an employer-to-be shares the key values with you then go for it. And yes, I do understand that I actually may be encouraging some of my people to look for alternatives. I don’t mind. After all, if I consider myself a leader I should care about well-being of my team, shouldn’t I?

At the same time if your employer-to-be doesn’t seem to share your values this is a single most powerful signal to take into consideration. It means that the whole setup would suck eventually.

And yes, it’s enough to look at, or ask about, relationships with partners or clients.

It’s all about values and you can’t lie about values. If you are fair to your partners you’re going to be fair to your employees. And vice versa.

Few people would take consider it when thinking about changing a job. Don’t be one of them.

A Kaizen board is a neat concept. It’s a visual tool that keeps track of all the ideas for improvements gathered across a team and then helps to analyze the status of ongoing improvement experiments. What we get from using a Kaizen board is we encourage everyone to participate in improvement process, visualize ongoing and planned improvements and give ourselves some sort of a tracking mechanism.

That’s the theory.

In practice I haven’t seen such a board that would work well.

I don’t say it isn’t possible to make it work. I just say it’s unlikely.

To answer why I think so, I have to bring the old story repeated multiple times in the context of Lean. When Japanese started kicking Americans’ butts in automotive industry in the second part of twentieth century Americans sent their managers to see what’s so different in factories in Japan. Surprisingly enough Japanese were super-open and transparent with all the tools and practices they had in place. Americans meticulously noted all the novel stuff they learned and implemented the same tools and methods back home. Guess what. It didn’t work.

It didn’t work because all these practices weren’t really game changers. The real game changer was underlying mindset that actually made these tools and methods work. By the way, this was also a reason why sharing all the secrets about practices wasn’t a problem. They weren’t nearly enough to make a difference.

We pretty much recreate the same story when we try tools like Kaizen boards or when we create Kaizen teams. We introduce a tool and believe it will change the game. It won’t.

The magic behind thousands and thousands of improvements implemented in Toyota every year is not any of the tools. It is a culture that supports trying stuff out. It is mindset that enables that. All that continuous improvement is happening not because people submit improvement ideas to Kaizen boards but because people are actively experimenting. They do stuff.

If you tried using a Kaizen board this picture may be familiar. There was lots of stuff submitted to the board but very few, if any, real changes were observable in your working environment. Now ask yourself: what would it take for any team member to try something out. Would people need to get permission and a blessing before they changed the way they worked? And then, when the thing failed, would they need to explain or ask forgiveness? Would they feel that they were co-creating the system they were a part of?

In most organizations I know these answers would tell you why your Kaizen board or Kaizen team or Kaizen whatever doesn’t have a slightest chance to work. In fact, in such a situation a Kaizen board would just be a nice excuse. I’d had that awesome idea but it wasn’t accepted. I’d come up with that great improvement but there wasn’t time to implement it.

Except then you shouldn’t call it a Kaizen board but an excuse board.

And the best part is: if you have right mindset and the right culture in place a Kaizen board isn’t needed at all. People just run their improvement experiments. Of course some of them last and some of them don’t. Then you obviously can use a Kaizen board as a tracking and visualization tool. Unless you get there though – don’t bother.