Management science's impossible quest: in search of predictability

Many years ago some people came up with a brilliant idea: "what if, we could turn abundant lead (Pb on the table of elements) into scarce gold?". A brilliant idea to be sure, but as we know now, impossible. What made Alchemy grow and thrive as a science, was that people at that time did not know that it was impossible. They did not have enough knowledge of chemistry to know that you cannot turn an element's atom into another element's atom. That did not stop them however! And thanks to those crazy idealists today we have Chemistry. How about that for a twist of fate?

Alchemy's history can be traced back for millennia, and that name stands as the prototypical failed science (except for poets and … idealists). Failed because it based its existence on a belief that was impossible to make reality in our world.

I find many parallels between Alchemy and Management science today. Alchemy wanted to find the magic Philosopher's Stone that could turn led into gold, Management scientists are in a similar quest: in search of the method that can make management succeed as a science. Management science's goal today is to find the magic ingredient that can give us predictability.

Basic Science

Many management-fads are based on the hypothesis that you can control the world around you, mold it in a way that can give you predictability. This (mythical) predictability is a core assumption that enables the management's idea of success: I will do X so that I can achieve Y and therefore succeed.

This predictability is, however, a form of causality. Many, perhaps including you, will not think of it that way, but predictability is only present in systems where you can determine causality. A predictable world is one where we can reliably predict what happens when we do X, i.e. a world where we can establish causality.

Newton's laws gave us predictability in the physical macroscopic world of objects, because they told us what would happen if, for example, you rolled a sphere in an inclined plane, or shot a bullet from a canon, or shot an arrow with a bow. Relativity theory gave us predictability (to a certain extent) in the microscopic world of atoms, or sub-atomic particles also because it established useful and applicable causality rules

Medicine gives us (mostly) predictability in the world of diseases and biologic systems like the human body because it has a system of studying and documenting causality: if you take Aspirin after a great Saturday night party, you will feel milder effects of the oncoming hangover.

You can see why management theorists (and practitioners) would want to achieve the same goal: predictability.

Predictability is management science's Philosopher's stone.

The Philosopher's stone

Planning is one of those attempts at achieving predictability. We plan, because we believe that planning will give us the predictability we seek. Without the goal of predictability we would not plan, there would be no point.

But planning itself rests on the assumption that we can predict (here it comes again) causality in the world where the plan is to be executed. If we did not believe that we could predict B to happen after doing A, then planning would not be possible. It would be illogical.

We plan to be able to predict, but plans only work if we can predict in the first place!

The problem with what is stated above is that it is a circular dependency: we plan to be able to predict, but the act of planing rests on the assumption that the world is predictable. You see where this is going, right?

The sad fact is that there are many other management techniques that both rest on, and try to achieve predictability. For example: pay for performance, management by objectives, or the yearly strategic plan.

Going around in circles

All these management techniques have one thing in common. They are static. They exist at a precise point in time: Strategy is defined in the Spring or Autumn and is supposed to be executed for the next 12, 18, 24 or more months. Objectives or goals upon which our evaluation is based are set several months in advance of the point of evaluation.

All these techniques require perfect, 20/20 foresight. How likely is that?

The basic problem with most perspectives on management today is that they are static analyses of a future environment. And all decisions are made because we believe we can predict the future.

We make these predictions to help our businesses be more predictable, but our predictions depend on our business being predictable. This circular dependency is why most management approaches are doomed to failure. Like Alchemy.

Looking forward

We need a new Management Science, one that does not require the existence of a predictable world. When it defines goals, it does so in a way that is dynamic, i.e. the goals change with the observation of reality. This dynamic adaptation process is what we, in the Agile community, call a feedback loop.

A future-proof management approach must start by basing it's core assumptions on the existence of feedback loops that must be studied and tested as we make decisions. And these feedback loops must be the driving factors for action in management. Not the plans!

How would such a management approach look like?

The first assumption of such a management approach must be that the world is not predictable beyond a very short time. This may be a simple statement, but the consequences of this simple statement are fundamental.

• First, management techniques must not be based on the existence of a perfect, predictable future. Management techniques must be based on the acknowledgement that we cannot predict what is the best (or worst) possible outcome of our actions. What good is it to plan to sell 100 widgets when the market is - unexpectedly - demanding us to produce 1000 widgets? or 10 widgets?
• Second, management techniques must be designed to include feedback loops that inform action. Not just as information collection loops, but as fundamental action-defining loops. For example: every single decision is temporary. Every decision must state it's assumptions and when one assumption is proven wrong, the decision must be reverted or at a minimum re-evaluated. When we execute our plans, we must be alert to surprises; without detailing our assumptions we can never be surprised. Surprises are triggers for action - no surprises, no learning, no adaptation.
• Third, an individual's performance cannot be predicted up front. This tells us that we can only evaluate an individual's performance after we have the facts of what happened. Maybe a sales person failed to meet their sales target, but that could be because they helped R&D get the first pilot customers for an entirely new business!

What would your world look like if you believed and followed the three principles above? How would it differ from your current perspective on management?

Image credit: John Hammink, follow him on twitter.

We need proof! For a better understanding of our business, without religious arguments

Whenever you hear someone talk about Agile being better than X or X being better than Y don't assume they are right. Ask for proof.

For many years our knowledge and society at large have advanced through the tried and often questioned, but always upheld view that it is not sufficient to merely claim something convincingly to have it accepted. Sure, in politics that happens all the time, but would you trust a politician to pilot the next aircraft you fly on? I thought so... It is not enough to be convincing or to tell good stories, you actually have to know what you are doing!

The point is that our knowledge, human society's knowledge, evolves by having many people look at the same issue, over and over again, doing experiments to prove an hypothesis and then learning from it.

An important point in this context is that success in the experiment is not needed to learn and advance knowledge. Failure in the experiment often yields as much learning as success would. Take the most famous failed experiment in history:

The Michelson–Morley experiment was performed in 1887 by Albert Michelson and Edward Morley at what is now Case Western Reserve University. Its results are generally considered to be the first strong evidence against the theory of a luminiferous aether. The experiment has also been referred to as "the kicking-off point for the theoretical aspects of the Second Scientific Revolution".
-- wikipedia

It was, in part, thanks to this experiment (a failed experiment) that we got the theory of relativity, arguably one of the most important advances in science in recent times.

But there are more examples of how science delivered progress. How it created knowledge that helped create the world we live in today.

What does this have to do with Agile SW development? You ask. After all, that's why you are here, right? Well, it just so happens that Agile SW development and our SW development industry have a lot to learn from science and the scientific process. We have to start taking the responsibility for the development of our craft/art/science.

Despite all of the buzz about agile, we don't have much in the form of evidence for us to say, yes agile is the way to go. Don't get me wrong, after having worked in this industry for 12 years and with Agile software development for 6 years. I would not want to go back. But as an industry we are making transitions to agile SW development that cost us millions of Euros every year. Most of those transitions will have been the result of a successful visit by a high-flying, expensive consultant that told us some stories we already knew we wanted to hear.

Are we betting our industry on a bunch of stories? Do we want to fly in that plane piloted by a politician?

I refuse to believe that's what we want to do. I refuse to believe that we want to go and bet our entire industry on a bunch of unsupported ideas that some good story tellers have come up with! I want facts, I want the evidence. I refuse to believe without seeing the evidence.

So, if we chose to be coherent with the growth of knowledge as opposed to the beauty contest that the Agile consulting world has become, we must start questioning the received knowledge that Agile "just works". The statement "it works for me" is utterly useless if what we want is to learn and to improve! The fact that it worked once for someone and that led to a successful consulting career has no statistical significance! Or do you believe that the waterfall consultants don't say the same? Of course they do.

So this brings us back to the key question I want to raise in this post: "How can we improve the state of our industry in a consistent, long term and sustainable way"?

The answer, which should be clear by now, is in the numbers. Or as a famous person once said: "show me the money!"

Show the numbers as they are so that we can have a conversation about the real results and can learn, ultimately improve.

Feel free to add your data to this blog post. I hope this can be the beginning of the real advancement of our industry. Show us what you learned, we will show you what we learn, and from this a conversation can emerge that will hopefully take us forward, make us more professional, deliver more value to our customers.

Share the data. "Show me the money"!

Photo credit: mr.beaver @ flickr

Agile Scales, Waterfall doesn't - Video of a talk at Agile Eastern Europe

Sometime ago I did a talk about Scaling Software Development at Agile Eastern Europe in Ukraine.

The slides are up in my slideshare account, but now you can see the video of the talk that Agile EE made available.

In this talk I try to describe what "scaling" means and come to the conclusion that Waterfall-like practices just don't "scale". Check out the video and let me know what you think

Vasco Duarte, "Agile Scales, Waterfall Doesn't", Agileee conference, 2009 from Alexey Krivitsky on Vimeo.

We don't need software engineering religion, we need software engineering science!

During the Scan-Agile '09 conference there was a lot of discussion about why Agile works and if a specific flavor of it would be better than other flavors (you know, the Scrum vs Kanban fight).

Despite those surface issues, there was a deeper debate going on. Why does Agile work? And in what context should we use certain practices? The essence of this dialogue was, in my view about what we really understand or know about Software Development.

Many of us came to Agile from different backgrounds. Some of us are closer to the development disciplines (testing and coding), others are closer to project management/management or product management.

The common thing is: we believe, based on our experience and observation that Agile is a better way to develop software. But why is that so? Where is the evidence, and what parts of it work in certain contexts?

The core of this dialogue is about science. We need the scientific process and scientifically proven theories to learn. That's how we learn as a species!

That's why I found this presentation so important. Even if I disagree with somethings that are stated there. The debate must start, we must stop practicing blind religion with our industry. We need to get scientific!

Hopefully many of you agree...

Bits of Evidence

View more presentations from Greg Wilson.

What can Science teach us about Agile? (or why you must come to Scan-Agile)

I'm sure that you've heard many things during your life that made you think: "Boy, that guy/gal doesn't get the basics of (put your favorite subject here)".

Well, there's a reason for that. People make assumptions and claims that are false because they have a faulty model in their head. They simply don't know better!

For example, Aristotle made a claim that we now know is ridiculous: "objects of different weights fall at different speeds". That's just plain wrong!

How come a serious, intelligent guy can make a claim like that? What makes us make false claims and sometimes even live according to those false principles?

Aristotle could have easily known that different weight objects do fall at the same speed. He would just need to take two rocks of different weights and drop them a few times from a high place and measure the arrival of the two stones. He would have found that there's no difference. The two rocks fall at the same time.

It took more than 500 years to discover this simple truth. Galileo proved that objects of different weight do fall at the same time and he established Gravity as a constant force with a precise value.

Why am I talking about this in a software blog? Because in the software industry we still have a lot of Aristotles running around and telling us that rocks of different weights fall at different speeds!

In the Scan-Agile Conference we will have an academic session where presentations from different researchers and Universities will try to make us understand what is true or false based on concrete research. We will have our own Galileos to tell you all about the latest findings in research.

For example:

• Dr. Nilay Oza from VTT Oulu will present results related to aligning Innovation and Agile Software Development.
  
• Dr. Burak Turhan from the University of Oulu will tell us a dirty little secret about TDD. The truth is that we don't yet know what the impact is. You'll have to attend the session to find out what he means by that!
  

Among other sessions we will have a panel lead by Pasi Kuvaja on the status and direction of Agile Software Development. You can expect some news from this panel. Don't miss it.

There are other very interesting sessions in the Academic track.

Check out the full schedule at www.scan-agile.com/schedule and when you are ready go and register here.

Photo credit: jurvetson @ Flickr

Belief without proof is dangerous!

Believing in some far-fetched (or indeed any) explanation without having any proof is dangerous. It is dangerous in the case of the flat-earthers and it is dangerous for project leaders and team members.

Whenever a theory emerges why something works (or doesn't) in your project/company, it is your duty to either prove it right or wrong.

Oh, and by the way: yes, it is indeed true that there are still people who believe the earth is flat!

Spreading the happy flu, an experiment to study epidemics (meme-style)

In the interest of science (studying epidemics dynamics) I'm posting this "spread the happy flu" post.

I got the happy flu from Henrik Mårtensson.