First Topic - About Machines

[Daryl Kulak]

Hi again,

Wow! I'm so impressed with so many people (and such heavy hitters!) joining our group! Thanks.

This is the first article I'd like to post. It is from a speech that Hong Li (my co-author) gave a few years ago.

This speech was not specific to Agile or even software development, but it is very illustrative of the main points in our upcoming book, Agile + Rigor.

I'd like you to read the article, think it over and add your comments in the Discussion area here. I'd like everyone to comment on it if you can.

You may feel that this topic is too far adrift from Agile and software development, but I beg you to trudge through it anyway. We are laying some necessary groundwork for the Agile-oriented ideas coming up soon.

I will always try to keep these articles short out of respect for your time.

Let us know what you think!

About Machines

Is it your greatest hope that your organization should run like a well-oiled machine? Would you like to have a secret business recipe that keeps your business forever "Number 1" in your industry?

If your answer to these questions is Yes, you probably trust machines too much.

But don’t feel too bad. It's not your fault. Science itself is one of the reasons why we think and act this way. From childhood, in order to learn something, all of us have to start with something easy and simple. By the time we graduate from schools, we usually think the best things we will learn about our world are about logical thinking and reasoning. This “scientific view" of our world has been in our blood for generations.

Successful machines around us, particularly those that are automated, further enhance our impressions about the power of our logical thinking and reasoning. It is natural for us to think that sooner or later we will discover more computable formulas so that machines will eventually be able to do everything for us, including the power of thought.

As a matter of fact, the machine model is one of the earliest organizational models offered by systems science and systems engineering since the end of WWII. The image of an organization under the machine model is a well-oiled, calibrated, calculated and optimized business machine, always ready to fulfill orders with maximum productivity.

Once upon a time, a business machine was possible. For example, at the beginning of last century, the Model T produced by Henry Ford stayed around for almost 20 years with little change. When the demand of market was simple and predictable, Henry Ford had the power of monopoly to say, “You can have your Model T in any color you want as long as it is black.” Ford knew as long as he could produce, the product would sell.

But in today’s marketplace, the predictability and computability of Henry Ford do not exist any more. The global proliferation of the market economy is wiping out the foundation of "the machines of our dreams." When everyone has the same machines (as physical machines or even machine-like organizations), they have no choice but to compete based on lower and lower prices if they can’t come up any other new business idea. This will only lead to a global chase after low cost supplies, especially low cost labor, which in turn accelerates the proliferation of "machine thinking."

In the long run, the monotony of the machine model is sending its business followers to constant struggles in the thin profit margin, or even suicidal missions with no return.

The machine model business will be fine if all you want is short-term profit. As long as you don’t mind what will happen after you run your business machine into the ground. Otherwise, the desire for a sustainable business machine can only be wishful thinking in our current time and in our future.

If the machine model is not acceptable in a changing and unpredictable environment, it is necessary for us to learn how to invest in and experiment with different business models while we maintain our financial and technical discipline. It is necessary for us to learn how to conduct innovative Research and Development for the next strategic move and simultaneously take care of current business operations.

All these experiments, Research and Development are often expected to develop new “cookbooks." If the employees doing the research believe they are robots that need instruction from business cookbooks, the daunting tasks of real-time business experimentation and R&D becomes quite unproductive.

Therefore, trust-building between management and employees (far beyond a trustworthy organizational machine), will always be required in order to shift away from the machine model. For example, employees have to be trusted to question and modify their cookbook instructions. As a matter of fact, trust can be an effective criterion to test whether an organization is running based on a different business model, or just replacing one business machine with another.

Unfortunately, many people today don’t realize that it is their machine organizations and machine thinking that have suffocated many of their new business initiatives. One of the biggest lessons we should learn in business is never trust in any business model that doesn't have trust as its fundamental basis.

[Hong]

Real-time Research and Development is always complex. This applies to us doing R&D in a software lifecycle just as much as any other type of R&D product innovation.

A typical complaint is that we want to have something *simple*, but in order for R&D to work, it has to be risky and complex. There is no choice.

You can see many examples of companies that cannot stomach the risk and complexity of R&D and therefore become stale and die. You can also see companies that do take the risks and can deal with the complexity and make the best of it.

Google is a good example of this. They can constantly turn out innovative business and technology ideas and grow at a speed never seen before.

Some people try to interpret Google as a "great machine." You can see an article on that topic here:

http://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/item_de...

Harvard Business Review is saying that Google is a well-running machine (the article title even mentions the machine model!) and yet they also say they aren't too sure that you will be able to copy the "machine parts" from Google into your own company. Why not? If Google was truly a machine you should be able to take those pieces and scale up and out.

We feel that Google has created an organization beyond the machine model. Trying to categorize it in the limits of a machine organization doesn't work. Same for a software development team. Our current methodologies and processes force us into a machine model and therefore limit us from being a true "Google" that is able to cope with complexity and risk in our business.

[Ross Kayuha]

What I have read so far seems to compare a development effort with a R&D effort. To me they are different things. The development effort has a specific desired outcome and the R part of the R&D effort may not. R&D outcome(s) are planned in general, but they should allow for change, learning and serendipitous events. I believe a machine analogy fits for a developement effort because there is one desired outcome and intelligent people should be able to agree on the correct steps to obtain it. That is why we have methodologies, workplans and what-not to drive these efforts.

The problems arise when we do not allow an invidual to perofrm their role in the development effort with a degree of creativity. This creativity should be the source to future changes to the methodologes and workplans of the future. I see a methodology's lifecycle as similar to a flock of birds in flight. The birds work together in the same directiion until an exteral influence impacts their drection. One (or a small group) makes a change because of the influence and the group changes and adapts. Methodologies, and even individual devlopment efforts, shouldfollow a similar course.

An R&D effort however, should be more loosley directed with less stringent task requirements. The range of pure research to actual devlopment should be managed with stricter guidelines as you move from R to D.

[Hong]

Hi Ross,

Thanks for putting so much thought into your reply to this forum.

Let me ask more about your definitions of some of the terms you've used. How do you define the "machine analogy" that fits for the development effort? You say that people in development have a "degree of creativity." How does this happen inside a machine?

Secondly, could you compare the machine that you talk about for development to the machine metaphor that is mentioned in the above article about Google?

At Google, people can apparently do their own research about their own work using their own ideas. Is this similar to what you are talking about for the degree of creativity allowed for people in development?

Thirdly, I want to respond to the flock of birds example. You mentioned the birds in flight operating as a type of machine (I think). I would say that you are looking at the flock at a particular point in time (as they are flying together) and saying "Oh - look at this perfect machine." But is that a fair assessment? In order to understand the behavior of the birds' interactions with each other, shouldn't we look at the entire history of the flock, how the birds have grown up together from birth, and even mate within the group, usually for life. The mates fly side-by-side within the flock and the offspring fly with the parents, using the parents' airflow to allow the smaller birds to keep up.

Does this sound like a machine once you put it into this context?

[Mike Cornell]

I may be a bit of a cynic here, but I believe the reason Google allows the 20% rule is to make it easier to retain talented creative engineering types.

By doing so, they have the added bonus of throwing a bunch of ideas at the wall and seeing what sticks.

At my last job, I implemented clients onto a platform. That is, if a company wanted to offer its invoices to its customers electronically, I made it happen.

At a 10,000 foot view, this effort was operationalized. There was very little at a high level that was different between one project and the next. Every project had to do the same things. Enable user authentication and company acceptance, present the invoice etc. So when you looked at a project plan between two different efforts, they were 99.4% the same.

However, when you drilled down into the project itself, each effort was different. Some were very simple because the inputs were simple. Some were highly complex, high cost to get done, and high to support due to inputs that were not simple. The inputs in this case were print streams that were reverse engineered so that they could be presented electronically.

This is a long way to say that I believe that my last organization looked like a machine from afar, but once you got under the hood, it was far from a machine. The parts were very very different. The reason the organization looked like a machine was the team members. They were doing this sort of work for 7, 8 even 10 years. They knew what worked and what didn't through experience. They were able to make very disparate things look as though they were the same, even though they were far from it.

[Hong]

Hi, Mike,

I'm glad to see you come to the conclusion that for individual projects, "each effort was different." But I'm puzzled by your other conclusion:"The reason the organization looked like a machine was the team members. They were doing this sort of work for 7, 8, even 10 years ..."

I'm not sure I have fully understood each of your arguments in context. Do you feel that all members of teams chose to be machine parts of their teams? Are you saying that each effort of the teams represented different machines? Is that your conclusion for Agile teams as well?

Thanks,
Hong

[Mike Cornell]

More than likely, my post was not developed in context.

Last group I worked in was "operational" in context to the business. A nice black box.

However, the black box itself was far from a machine and certainly like a Mechanical Turk. This type of analogy is true for many software shops.

However, the black box itself became even more complex. As team members who played the Turk left, the Turk became less efficient due to the differences in the input for each effort. The less experience the box had, the less effective it was.

I think the point I was attempting to make was simply that the machine is only as good as the individual parts. But due to my propensity to ramble, occasionally I get to points in a circular manner.

[Daryl Kulak]

Hi Mike,

I'm sorry but I'm somewhat confused. In the third paragraph, you say that this organization was far from a machine. But in the fifth paragraph, you say that "the machine is only as good as the individual parts."

So are you saying this organization was a machine or not?

It seems like it is not, because when the "Turks" leave the team, the team becomes less efficient. To me, that sounds like it is not a machine. In a machine organization, we have truly interchangeable parts. You can replace one part (person) and never worry that there will be a problem with reduced efficiency. The only way you would have reduced efficiency is if the new part is defective.

[Mike Cornell]

Since perception = reality, it is both a machine and not.

From inside, I can tell you it was not.

From the outside looking in, it absolutely was a machine. The business organization believed it was, and so it was. The IT staff could easily tell you it wasn't of course, but that doesn't mean that it's being listened to, or that the IT management is skilled enough in technology to actually see that it is not.