Photo by: acute_tomato

The field of Interaction Design has (rather) recently started to approach the Lean way of thinking, in the shape of a methodology called LeanUx. I welcome this, and it prompted me to write down a few words on the “expansion” of Lean into other areas.

As readers of this blog probably know, I find myself drawn to all things Lean and/or Agile. They appeal to me because they are methods based on pragmatic and realistic ideas about our limitations in relation to the challenges we face. These methods try to embrace the unknown as learning opportunities, instead of succumbing to guess work. Guessing can, in a worst case scenario, lead to a variation of “second order incompetence” (you don’t even know that you don’t know). The direct opposite of this can be found in the word of Socrates, who is credited with the quote:

“True knowledge exists in knowing that you know nothing.”

Word up!

Now, why does Lean propose this? Because at the core lies an idea about eliminating waste. Lean considers…

…”the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.”

This means that Lean focuses on creating a process that ensure the creation of high customer value as efficiently as possible. This is done by finding and eliminating waste. In my (our?) world, this translates well to what is captured in this wonderful quote, for which I have no source:

“The biggest form of waste is building software nobody wants. The second biggest form of waste is fixing bugs in software nobody wants”.

Moving on: If you accept that you are in the business of creating something new, it follows that you are venturing into the unknown. That which is not known cannot be planned for in any meaningful way, since planning involves predicting the future – which is guessing. Sure, you can do it, but the risk that you invest a lot of time and money in the wrong guess (e.g: “waste”) is high, and probably not worth taking.  But you are still forced to relate to the unknown. One way to relate is to have a process with a focused effort to generate information by way of experimental work. To do this we start off with some assumptions, and when information has been generated, we revisit these assumptions and hope to validate them, or kill them off. This is what people talk about when they say things like “fail early, fail often” and the idea of “good enough” is also related.

So, basically, the Lean movement incarnations- be it just plain Lean, Lean Software Development, the Lean Startup or the most recent (I think) incarnation: LeanUX, all share the one same basic “idea” about the nature of our work.

The idea of design thinking in business comes to mind. In this fine book Roger Martin writes about how the exploration of the “mystery” is moved through “the funnel”, via iterative experimentation, towards the validated algorithm that can truly scale. This is one another way of illustrating the flow of work and ideas in a more holistic perspective. Only after a certain critical point can our efforts be turned in to “business as usual” and scale. I don’t have to tell you that that the point in time when you are ready to scale is also the point in time where you start to make money.

Even if this is a more “light weight” process compared to many others, actually doing it is quite difficult. Partly because it forces you to live with uncertainty, rather than living under the illusion that you have killed uncertainty with your Gant chart. The latter might give you a warm feeling in your tummy in the beginning of a process, as you role around in a mud-pile of assumptions and projections like a happy project manger piggy, but when you are closing in on your deadline and your assumptions turn out to be false, there is quite the price to pay for your initial delusion.

But the ideas found in Lean does not start nor stop with things defined as Lean. In my mind, Lean is but one expression of a general zeitgeist that exist well outside the Lean movement and these ideas resonate well with other areas of interest, in particular the wonderful world that is System Dynamics and Systems Thinking.

For some examples close to home, take Steve Krugs excellent books “Don’t make me think” and “Rocket Surgery Made Easy” or the Jakob Nielsen now famous “only test with five people” scaled down approach to usability testing. All calling to trim it down. It’s been a while since I read the books, but I cannot recall any of them calling what they propose “Lean”.

Another example from the opposite side: Take this fine book on Landing Page Optimisation by Tim Ash of sitetuners.com , which truly makes a science out of multivariate testing. On reading I was fascinated but I kept thinking “who in their right mind would spend all this time on that – it’s too complicated, too complex. Can the benefits really justify the effort?”  The very same thought crossed my mind when reading the also very good “About Face”. Truly the bible of Interaction Design. But the process that Alan Cooper and his friends suggest is simply too much. Who has the time, money and resources to do all that they propose in a world where the idea that you are investigating can be made obsolete in nano seconds by a change in some Apple-, Google- or Facebook- Terms of Use? Or what if the next truly disruptive game changer lies lurking behind the corner and makes your offer as interesting as, well, iTunes Ping. The good people at Cooper understands this though, hence this interesting post on LeanUx.

Admittedly, not all of us work at startups, but I can’t really see how it would be any different in a more established business. Developing a new product is a mini-startup. Sure many things come easier, (but not innovation – but that’s another blog post) but the general idea remains the same. The fast moving market doesn’t really care if you’re a startup or if you are established. You are competing on the same terms as far as the market is concerned.

So in conclusion:

Today’s truly valuable manager, be it executive-, project-, product- of otherwise is someone who understands the whole process on a systemic level: How to facilitate ideation, pushing the process of exploration through the funnel towards the scalable algorithm. How to operate a Lean Startup with a Lean Product Development Process where the LeanUX process is in place creating and validating mockups, ideas and designs in close collaboration with the designers and the developers – who all soldier on in an Agile/Kanban process. All components working together; maximising learning and the creation of information and eliminating as many forms of waste as possible.

That is a valuable skill. And it can be a lot of fun if you’re doing it with the right people. For this is an attitude towards work that requires a collection of very talented people who have their egos in check. It requires entrepreneurs who are open to reinventing themselves and their vision on a daily basis.

That makes it hard. But the rewards will be great if you can make it happen.

And yes, I know that there is a lot more to both Lean and Agile than brought up here, but I would call those aspects tools of the trade available to you once you have embraced the Lean mindset.

But here’s a question to you: Which areas will be next to receive a make over and earn the Lean label?

Lean PR? Lean Marketing? Lean Sales? Lean HR? Lean Education?

You tell me.

For the interested, a lot of fine literature on Lean and related subjects can be found in the Good Reads section

Now, the Ford quote is so popular in some circles that it is used in the form of an abbreviation, as in:

“venture capital… mumble, mumble… vision… you know… ’faster horses’… ‘aint it? something, something… exit strategy… IPO”

The quote is not seldom used to masquerade the fact that the “great vision” have yet to experience contact with a little place we call reality. If you’ve never been there, I can tell you that reality is a happy but rather weird place where customers live and prosper blissfully unaware of most entrepreneurial visions.

Let me illustrate: If Ford had actually asked people what they wanted they would probably eventually have said that they wanted to get from A to B faster. Potentially, the only way for a person who lacks Fords’ strength of vision to foresee how this goal could be attained, would indeed be to have “faster horses”. But it doesn’t take much scratching on the surface to understand that a real need was involved. The Ford quote is not absolution from listening to your customers or having some sort of relation with reality.

If this misunderstanding of the Ford quote is intentional or not is hard to say. If it is intentional, the entrepreneur is just shady. This would worry me. If it’s unintentional, perhaps the entrepreneur simply have yet to construct deeper thoughts on the subjects. This too would worry me.

To sum up: If customers are to your company what fact checking is to a good story – well, then things need to change. Please don’t let your vision get in the way of creating/building/developing stuff that people actually want. Next question: Are they willing to part with their hard earned money to get their hands on your stuff? No? You didn’t think to ask? *sigh*

Placed in a Product Development context the “good enough” concept is not hard to understand. As I have described earlier – the Agile mindset is to cut back on the scope side of a project triangle, in favor of delivering value at a certain set point in time. This means that all requested features might not be present in the first release. Naturally, a “good enough” mindset works very well in this context, if for no other reason than that it can help prevent “feature creep”.

This mindset also encourages a “release early” concept, based on the belief that the sooner customers get to fiddle with your product, the sooner you can gather information about the value of what you are building and how the users and “the market” feel about your efforts. This belief is supported by basic information theory, and I subscribe to the idea. After early release, continuous cyclic improvement follows, and iteration after iteration you improve your product – based on feedback – striving to reach the Product Vision.

The misunderstanding here is that the Product Vision, or even the whole business idea, should also be surrounded by a “good enough” mentality. Obviously, it shouldn’t be. And I’m not sure if anyone really has suggested that it should?

But I can see where the confusion comes from. In the debate, I felt the spirit of Seth Godin hovering between the lines of the “good enough” bashers rhetoric (don’t be good enough – be remarkable). But even Seth Godin is paradoxical when dealing with the subject.

Godin has in many books propagated that we reach for the stars, that we strive to be “remarkable” or make remarkable things (Tribes, Purple Cow), but he also propagates that we deliver (Linchpin). Because what we do is “art” and art only happens when our efforts meet the outside world. The last section represents a debatable, but interesting point.

It boils down to this: We have to deliver. We have to throw ourselves out there. The good enough mentality is a very helpful idea that can help us get there. An early focus on perfection will severely damage the work process, your spirit will be crushed, and you will run out of money. So start with good enough – find your feedback loops and then go conquer the world with your remarkable vision.

Believe it or not, this is my angry face.

I touched upon this in an earlier post. But I thought it was worth repeating from a team perspective.

If you’re on my team a very quick outline of some sort of expectations management statement could read:

I expect you to speak up when something is wrong.
I expect you to speak up whenever you spot a problem.
I expect you to speak up when something doesn’t make sense to you.
I expect you to tell me when I’m wrong.
I expect you to bring your skill and passion to the table.

And what can you expect from me?

I will listen to you.
I will gather as much input as possible and facilitate a process that leads us forward.
I will kill all nonsense coming your way.
I will get out of your way and let you work your magic.
I will trust and support you.

Basically, we are all problem solvers. If the circumstances surrounding our project, or the very essence of our project deliverables, are completely free of obstacles, or in no need of solutions, I would venture a guess and say that the project in itself is probably rather meaningless, or rather: of little value. In a sense, value is created when difficulties are overcome. For this very reason, hiding problems out of sight out of mind, means compromising the whole process of delivering value.

If you are on my team, you are allowed to fail, if you just made an honest effort and hope to learn something from mistakes made. But the one thing you cannot do. The one thing that will earn you a shit storm of hellish wrath, is this line of thinking:

“It’s crap, a road to ruin, but that’s what the customer wants so hey, by any means – let’s go build it, see if I care!”

Think like that? Time to quit.

Anders Lindqvist - someone who knows.

- As part of a major reorganization of Sony Ericsson back in 2006, I was involved in creating a global organization focussing on what we called “launch support and management”. In very simple terms: We tested, customized, profiled, packaged, and sales-supported the whole portfolio towards our Sales and Marketing teams. Vice versa, we funnelled and aligned the feedback from the markets towards our R&D teams. Previously this had been carried out both by each product business unit and by teams in Lund, Sweden, who had been doing it since the dawn of time. In other words, we undertook a major defragmentation operation.

In this context I built and managed a project/expert office responsible for customization, packaging and documentation, customer launch quality management and launch schedule alignment between markets and product development. When the big bad recession hit we were approx. 120 people in China, Sweden, Taiwan, USA and Japan.

I was able to take away a lot of extremely valuable experience and learning from this, not only from successes but also from biting the multi-cultural dust at times.

What in your mind were the greatest challenges in managing people from different cultures?

- I must be frank and say that I might not have seen the greatest challenges there could be. One reason for this is of course that the industry we work in is quite young, and thus it’s not extremely different culture-wise between countries. Also, having different cultures working together in one room, in one country, is not that difficult in our industry. But if I am allowed to base my answer on my recent environment, i.e. working with telecom professionals with similar education, in a multi cultural AND multi-site environment – I’d like to mention a few challenges that we faced:

One obvious challenge was to throw the stereotypes overboard and realize that the Japanese CAN say no, and that the US folks are not ALL Cowboys. A very real challenge was also the differences in attitude towards authority, accountability and lines of command communication. These differences are known to most and would normally not create any major problems. But when conflicting or tough decisions were called for, such as cost savings, increased workload, reprioritizations, negative feedback etc, these issues pop up as hot bread from a toaster.

Can you give us an example?

- Sure. This is a good one. I spent a week in Beijing with my trusted manager (Chinese). We had a very good relationship and no issues between us. After I left Beijing, the very next day a local executive manager stepped into his office and contradicted the decisions we made together. I can tell you that it’s VERY hard for my guy to say ‘nope – you are not my boss’, especially since my guy was locally employed and could even risk being suspended from promotion evaluation.

For similar reasons it could at times be hard for my local manager to act as a representative (there) of our management team (here) and enforce decisions that met opposition. If there would be a disagreement he risked escalation locally, not to me though, which would have been the right way. And once issues escalated locally – the chance that my guy’s local executive would call me up and asks for advice were slim.

I need to be clear here that although I choose a ‘neutralized’ Chinese example, the problems existed everywhere but in different forms. Sometimes the problem could even be the other way around. Let me give you a funny example. Once, a local executive with a conflicting directive approached my site manager in the US. My guy simply said ‘Piss off, my boss is in Sweden. Call him if you have a problem.’ Although in this particular example he had good reason to react like that, it illustrates the potential problems with global chains of command vs. local culture.

This sounds like problems originating in geographical distance, rather than culture?

- True, but it’s hard to clearly separate the two. But obviously, differences in how people think about stuff like gender, age, education and position of course add to the cocktail. Sending a female Swedish manager to Japan to manage a team of Japanese, in an environment where a majority of managers are male, and they have all worked at least ten years in the company and plan to retire there, is NOT easy. But it can be overcome and it can be really beneficial for everyone involved.

Can you give us an example of a time when there was a clash between cultures?

- There are of course quite a few. One could be that the attitude towards what is acceptable when it comes to jokes that can be perceived as sexist, or that make fun of religion.
Another is the tolerance towards being late for meetings because of a hangover; this differs a lot between southern/eastern Europe and Scandinavia. Another example could be the definition of what an assistant can be expected to carry out. My assistant was once asked by an Asian Gentleman to bring some fresh milk for his coffee. He didn’t exactly score any points with her, to say the least. But back at his office he had a lady that ONLY makes coffee and makes sure there are fresh lemon slices in the water pitchers.

On the other hand, our Asian and US colleagues sometimes marvel at the fact that Swedish managers spend a huge chunk of their time with travel planning, expense reports, invoicing, accounting etc ‘administrating instead of managing’. And a Swedish manager in Asia making his own copies and whom act ignorant to the local hierarchies is soon going to loose all respect. What is right and what is wrong? Hard to tell!

An important lesson for me has been to stop thinking that Swedes always know best, and – even more important – not to give the IMPRESSION that you think so. A strong and well thought through corporate/team policy to regulate what you feel is important is always more efficient than individual do-gooder managers running their own schemes. I’d say trying to treat women and men equal is the only thing I will never compromise with.

Interesting. And what about the language barrier?

- Well, indeed. That’s an obvious one. Sitting in a room, or even worse in a conference call, with people from six countries, with varying patience, language abilities, humour, and communication skills can be a circus at times. And then you need to make sure that everybody leaves the meeting with the same view of what needs to be done, and with an understanding of the urgency level of it all. That is truly a challenge, and if nothing else, very time consuming.

I have been surprised at times by the lax attitude towards enforcing ONE corporate language. Swedes emailing in Swedish because ‘there are only Swedes on the distribution list’ and Japanese executives corresponding with Japanese engineers in Japanese are only two examples of ignoring the potential of ONE common language.

You could of course argue that you need to respect the fact the people have different skill levels when it comes to English. But should that excuse falling back to a language that leaves a majority of the employees in the dark? Should you even be hired as a senior manager/expert without decent command of English? Training and/or stricter screening of new employees combined with enforcing a one-language culture is the key I think.

Do you feel that people from different culture respond differently to leadership?

- Yes, very much so. It’s however hard for me to talk about it without falling into the stereotyping trap. Let me just say that culture-originating difference in attitude towards management can only be overcome by clarity and earning your respect through living your mission and ensuring that everybody under your wings can see the goal and their own role in reaching it.

I also want to kill a common prejudice here by stressing that a very hierarchal, traditional and hard to penetrate leadership culture by no means causes more difficulties for a global enterprise than does a lax, accountability-shy and consensus-ridden ditto from another part of the world.

What in your mind are the benefits of combining the efforts of people with different cultural backgrounds?

- A given but boring fact is that my American direct report has a greater chance of implementing our decisions back in North Carolina than a Swede would have. The same goes for the fact that a Chinese ear to the ground in China picks up more than a Japanese would.
I would also say that the fact that different people that can contribute to the creative process from different angles really adds to the benefit, not different cultures per se. But the likelihood that the spectrum of different angles increase with the spectrum of culture is a given.

The easiest way to go management-wise would of course be to run a single language, single culture, and single country team with the exact right composition of competencies. But what you loose then are the social benefits. You enjoy time together, you learn new ways of thinking, and basically have fun together. All of this most definitely add to the quality of the output. Also, we mustn’t forget the stay-awake effect of a collective effort to keep it together over the borders.

When you first started working with internationally with people and projects in this way, did anything about these operations and this line of work surprise you – for good or bad?

- A positive surprise, and later something I was able to proactively use, was the enormous additional potential and productivity you could unleash by ensuring that every single individual in a global team agree on why, where and how to go about the work to reach the common goals, and also buy into what is expected from the individual in terms of contribution. Over the years I have learnt (of course also from mistakes) that this can not be achieved with emails, PowerPoints and the odd business trip, but have to be massaged into a multi-cultural organisation with a lot of time and face2face meetings invested.

I assume that leading operations of this nature requires a lot of travelling – how important is face-to-face contact with your crew?

- Recognising that business travel as we used to know it is soon a thing of the past, I’d still say face2face to some extent is crucial. Far too many companies, collaborations and projects have failed because people do not know the guy making the decisions and – even worse – maybe haven’t even seen him/her live in the flesh. OF COURSE it’s equally important the other way around. I mean, how can you make the right decisions if you do not know the guy at the receiving end? Then, when the personal connection is made, it’s easier to work remotely, do phone conferences etc.

What skills or traits do you think a leader of cross-cultural teams and operations need to have in order to be successful?

- Make sure you are well read up on the big picture but leave the details to the specialists. Ask questions to learn and to show that you appreciate expertise. Be yourself! Do NOT pretend to be someone else! The team will see right through you and it will be hard to gain back lost respect. Another important trait is to be humble, and arm your self with a lot of patience. Be prepared to explain over and over why the team needs to do what they’re doing, what the other teams are doing (and why) and what benefit it brings to the company. Motivation and agreements are so much more effective than orders and directives (that are oh-so-easy to fall back into sometimes if you are not on your toes)

Being a bit of a social chameleon helps too when you need to feel as home in a stiff boardroom-style meeting in Asia as you must by the cowboy coffee machine run-in in North Carolina. And last but not least you need to listen, enjoy learning, and show that you might not always know best just because you do not eat chicken feet.

Last but not least. You must never forget that it is as hard for a multi-cultural team to be managed by a single-culture manager, as it is for the manager to manage the team. Understanding this and working with it, rather than only marking your emails ‘important’ and bold your title, will help the team a lot.

If you want to get in touch with Anders you can reach him here

Angle Alert!

As always, I try to add a few notes for you to consider when it comes to press ethics and how a journalist works. But there’s really just one thing that’s fishy here, which is that Anders is my cousin. But that just makes him cooler.

Clausewitz

Take for instance a squad of Marines. The team is at the front line, they are there when it happens, they are at the scene. And when reality hits and renders most plans completely useless, (as Carl von Clausewitz, the famous strategist who wrote the classic “On War” is noted to have said: no plans survive contact with the battlefield [UPDATE: Now I hear that it's actually a quote from Helmuth von Moltke the Elder who was inspired by Clausewitz]), they still manage to adapt and overcome and get the job done. We can only hope for this outcome if the teams have the capacity to solve the problems they encounter themselves, without the involvement of others. This means that we need a combination of generalists, people who understand the basics of many things, and experts, that excel in one area. In other words: we have cross disciplined teams, and with the right team assembly, we have a shot at success. The team also has to be self organizing. There is no room for delays, and waiting for directions from a HQ somewhere is sure to slow things down. People at the HQ are not in a position to assess the situation nearly as well as the people at the scene. We need local initiative.

So we have cross disciplined, self organizing teams. That’s a great start. But how can we be sure that this team will work towards the correct goal?
To accomplish this the self organized teams need to understand the wanted outcome of the system in which they operate. One useful method borrowed from the military is the one of “Commanders Intent”. One can find a definition of Commander’s Intent here. It reads like this:

“A concise expression of the purpose of the operation and the desired end state that serves as the initial impetus for the planning process. It may also include the commander’s assessment of the adversary commander’s intent and an assessment of where and how much risk is acceptable during the operation”.

Here they talk about “the desired end state”. This is synonymous to what I throughout this blog have called the end game of things (and what Goldratt calls Global Goals). It’s about pin pointing the wanted outcome of any system. In other words, this is a question of understanding the whole picture. Take for instance the Lean method of asking “the five why’s”, i.e. five questions asked in order to discover root causes of problems. One might express this in terms of curing the disease instead of curing the symptoms. Curing symptoms are temporary solutions. Even with the fix, the system is still broken. Anyone who enjoys “House M.D” should be able to grasp this. Obviously, asking the many “why’s” is also a good practice for understanding the scope of possibilities, not just the scope of problems.

I believe it wise to have what the Poppendieck’s call a “framework” for proceeding – as plans will be subject to change as learning occurs, frameworks provide a space for this learning to occur. Basically this means that instead of getting upset when work fails to happen as planned (and it always does), you build this change into you work and embrace it as a learning possibility.

We enable and empower teams so that they can make even high end decisions themselves. We trust them. No need to involve a massive amount of people with MBA’s who are severely confused whenever they are forced to stray more than five feet from a spreadsheet.

To conclude: What we want is self organizing, cross disciplined teams with a good understanding of the whole system and what it is we want to achieve. Armed with the commander’s intent and a healthy level of trust, we are sure to succeed.

Note: I first read about the concept of “commanders intent” at the excellent Target Process blog here.

It's not war. Photo by: Jayel Aheram

In my mind your goal is to deliver the best product or service possible, your goal is to advice your client on how he or she could achieve his or hers goals in ways they never thought of. In pompous terms borrowed from Seth Godin, your job is to be remarkable.

When you enter a project together with a customer you enter into a collaboration – a relationship even. Just as in any relationship, we need involvement and passion. Much “us-and-them” thinking is floating about creating a lot of tension. There’s a clash between Customer and Client – which of course boils down to “payer of invoice” vs. “sender of invoice”. That’s a business transaction – and that’s probably where all tension originates. Nothing adds pressure as short-sighted financial goals. But this is not war, people. It’s collaboration.

I believe it was in a tweet from Jeff Patton where I caught this spot-on statement:

“We should be more like doctors – helping, and less like waiters – taking orders”.

Well put! How many times have you heard, or maybe even uttered, sentences like: “It’s crap, a road to ruin, but that’s what the customer wants so hey, by any means – let’s go build it, see if I care!”

Now for some prejudice based on experience: If you’re a consultant you’ve probably said the above one too many times yourself. Consultants are the hired guns of our world, and how to work with them intelligently is a whole different chapter for another day.

But back to essentials: All in all, it’s actually really, really easy: The customer has goals, you should go above and beyond in order to help the customer achieve these goals. Here’s where my much repeated mantra returns to haunt you: keep an eye on the end game. What is it really that the customer wants to achieve? This is a question of communication as well as commitment. Communicating what’s possible, what’s realistic and what is not. And committing to the work at hand, – whatever could anyone gain from NOT stepping it up and with solid and well researched arguments direct the customer in the proper direction?

You need to go above and beyond. Should your customer have a lousy process at their end, a process that you KNOW will cause an awful mess, then for the love of Taiichi Ohno, tell them so, and help them improve. If you don’t – go find yourself a line of work where such indifferent behavior is accepted. On the top of my head I can’t really think of one. But as you know, Absence of evidence is not evidence of absence.

It might be that this calls for a different breed of project managers, or maybe a different team setup – a configuration of people for whom system thinking and understanding of business goals is well rooted. A team where everyone involved truly understands the big picture and not only the role they themselves play. In my world, this means making designers and hackers take at least a minor interest in economics, law, marketing and other areas not directly associated with what they are hired to do. Difficult, but not impossible.

And again: a goal is an end game. I will repeat this until my nose bleeds. Helping your customer reach his or hers end game, even if this means not taking the job because what your customer really need is something you can’t offer.

Helping your customer excel. That’s the only success factor you should be interested in.

Evil triangle! Illustration by: TW Collins.

You are of course familiar with the project triangle, where SCOPE, TIME and COST represent a side each (feel free to substitute these with parameters GOOD, FAST, CHEAP or SCOPE, SCHEDULE, COST. Good, Fast and Cheap are usally used as an educational tool to describe that you cannot have all three. Select any two and forget about the third).

Anyway, all three parameters involved in the project triangle are uncertainties to be delivered in a very change-prone place called the future. So we are asked to bring out the old crystal ball and look into this future. And if this advanced guess-work turns out to be less than accurate, we call our project a failure. Let me rephrase that for the sake of clarity: the failure lies in us not guessing well enough. Isn’t that weird? Sure, there are techniques for estimating, often based on past performance, such as measuring team velocity or average cycle time, but even so that’s past performance (history) and we are headed into the unknown (the future). I have previously made my feelings about this clear.

It is important to recognize that all three parameters in the project triangle are burdened with uncertainty, and we need a release valve somewhere. Think of your project triangle and imagine it to be a steam engine. All that uncertainty boiling inside. If you don’t let out steam it’s gonna blow. This is where Agile comes in, and in the following example more specifically Scrum.

In a Scrum project we open up the scope side of the triangle to let out some steam. We let the customer adapt to the reality of our progress and cut features if we see that we cannot possibly finish the whole thing on time. In typical Scrum you cannot touch the TIME-side of the triangle. The one holy idea is to deliver value at a certain set point in time, and the negotiable parameter is scope, i.e “what value do we deliver”. That’s the M.O of typical Scrum. But it is of course also quite possible to attack other sides of the triangle. This means COST (spend more money) or TIME (spend more time).

Which side of the triangle to attack is determined by your circumstances, but at least one of the sides must be allowed to slide somewhat to adjust your plan to reality. This is because we need to make crucial decisions when we have more information, rather than when we have no information. This again, is Just-In-Time-thinking.

Furthermore, information theory states that the value of information created by failure is very, very high. We also know that changes in projects are more expensive the longer a project runs, which causes a lot of people to think that we need to get it right from the get go. The opposite is true, we need not get it right from the start, rather, we need to fail early. This is why iterations are used in processes that involve great uncertainty. Working in iterations is basically a way of saying “let’s try stuff out and see what happens”. Whatever happens (success or failure) we have generated information that we did not have when we started. And if we succeed we have learned a lot less than we would have learned if we would have failed. You see, as Nassim Nicholas Taleb among others has pointed out, humans have a tendency to attribute success to skill (when it could just as well be luck), and failure to external factors such as bad luck (when it could just as well be incompetence). We need to stop doing that. Right now.

Basically project management in 2010 is more about rolling with the punches than sticking to a plan. Change readiness in all parts of your project and process is more important than accurate estimating. And we serve our purpose better focusing our effort on activities that produce information early, than fooling ourselves that we can accurately look into the future. The challenge now is to communicate this to our stakeholders.

Carrot & Stick. Photo by: Bruce Thomson

We can spot the same misconception with regards to the various trends in how to organize work, projects and operations, and how to lead people. The trend is most certainly towards a higher degree of freedom and self organizing. It’s less strict. It’s more fun. We’re moving away from the factory and cubicle, into creative labs. I think it’s the right way to go under most circumstances.
But the end game is, very much like the end game of the “good Internet” described earlier, to produce better results. No one would suggest that we should let people play around at work, or work from coffee shops or from the couch if we did not think that the outcome (however we choose to measure this outcome) would improve. No one is doing this out of niceness. It’s really just another variation of the old “carrot or the stick” metaphor. Both methods are used to produce wanted outcome. Choose your poison.

I was at a job interview once where there was a lot of fluff (fluff is my term of choice for very loose approaches to leadership or management). They thought of me as a “doer” and well, I try not to fly in the face of public opinion. They pointed out that they work in such and such a way and expressed concerns that I would not fit into a system of that nature (a fluffy system) because I described in my application that I have a “zero tolerance for nonsense”, and that I insist on eliminating nonsense to ensure a healthy process. They obviously thought this meant that I was a grumpy suit who wouldn’t let people have any fun whilst working. What I meant to say was of course that I expect people to act as professionals in their line of work.

With regards to this inquiry about how I would fit in at their workplace with my insistence on a professional approach, I pointed out to the good people that the end game is the same. They too must of course be very interested in an approach that produces the best possible end results. If they think that their results will improve by them holding hands and talking about their feelings, well by all means go ahead. But you need to know why your follow this strategy. The reason must be that you believe that it will create a better output. If you are not interested in getting the job done in an intelligent way, you’ll end up getting a heart attack from the stress resulting from accumulated work. Not to mention the frustration, the arguments, the finger pointing, the bad mouthing, the time spent in useless meetings going nowhere, the constant rework. But at least you all got the opportunity to ventilate how you feel about the whole mess. Fun, fun, fun.

I didn’t get the job by the way. They said I was overqualified. The real reason, I think, was because I must have come across as an arrogant jerk. And oh how I can be. Especially when I try too hard, but you see I do feel strongly about these things. The proof is in the pudding: Just consider what I’d liked to have said to the person suggesting that I am a mismatch to their fluffy M.O.

- Listen friend. You work like this because you believe it to be the best modus operandi under your circumstances. If you did not honestly believe that, I would feel compelled to call you incompetent. If you work in this fluffy way because you think it sounds like a lot of fun, but you don’t really think it’s the best way to roll, i.e: producing the best end result, well then you’re obviously letting someone down somewhere in the value chain. That’s not leadership. That’s someone who has risen to their level of incompetence.

I did not say that. I’m a polite young man. But they could probably sense that it was on my mind. Funny thing is, I do believe that their M.O was the right way to go under their circumstances, albeit somewhat fluffy. Difference is; I know why.

So, with a bit of digression we end up here: The end game of fluffy leadership and management methods is to achieve goals either faster, cheaper or with higher quality (insert your own definition of high quality here). It’s not niceness. Please don’t confuse the two or you and your team will end up without a job faster than you can recite the words to Kum ba yah.

What my grandfather stumbled upon here was of course a version of Just-In-Time thinking (JIT), one of the two ‘pillars’ of the Toyota Production System. Had my grandfather built my father that stable, the stable would remain empty for sure. That would be waste (muda).

One of the many aspects of JIT thinking in software development (i.e Lean) is that decisions should be made as late as responsibly possible. Problems that will occur otherwise include overproduction (building stuff that no one needs and no one wants), abandoned code, and of course Premature Optimization.

So when told that you need to build this or that so that it can scale up to 5 millions users. Be sure to answer “bring me the 5 million users, and I will provide the scalability”.

The old stable – horse anecdote is actually quite powerful and does a good job conveying the point.