|
Joel and Kaizen have a lot in common
I just recently finished up a school research paper on Kaizen (pronounced Ky'zen), which stands for Kai (change) and Zen (good or better) and found many of the concepts to be in common with Joel's essays.
My main thesis was that the software industry in the United States is facing a threat right now from offshore competition much like the 1980s United States Automobile Industry and like that Automobile Industry has to fundamentally change how it produces software in order to stay competitive. Kaizen was the method I suggested as one way of doing that.
Very briefly, Kaizen is the method Japanese Automobile manufactorers used to improve the quality of their projects and consists of small daily incremental changes to the process with the goal of achieving the best quality product possible.
One quote from Dr. W. Edwards Deming, the American founder of the concept, really stood out. Keep in mind this was aimed at a difference audience about 4 decades ago.
“We are in a new economic age… We can no longer live with commonly accepted levels of delays, mistakes, defective materials, and defective workmanship. Transformation of Western management style is necessary to halt the continued decline of business and industry.”
I am going to post the report section that outlines four main points of Kaizen to see what your guys thoughts are. These are drawn from the book "Gemba Kaizen" ( http://www.amazon.com/exec/obidos/tg/detail/-/0070314462/qid=1065084311/sr=8-1/ref=sr_8_1/102-1809771-1381707?v=glance&s=books&n=507846 )
++++++++++++++++++++++++++
• Process versus result.
• Putting quality first.
• Speak with data.
• The next process is the customer.
Process versus result means “processes must be improved for results to improve.” (Imai 4) Failing to achieve the results you wanted is not the result of bad or lazy employees, but instead indicates a failure in the process. It is management’s job to isolate problems with the process and provide solutions. For the most part, American programming shops focus on results. If you focus on the results instead of the process that created those results, then you will not be able to change the results.
For instance, if management’s goal is higher productivity, the managers need to provide methods for achieving that goal. Most of the causes of bad quality and low productivity are part of the system, and are beyond the control of the work force. Work methods will not improve unless the workers are given changes to the process that lead to improvement.
Part of focusing on the process is to “eliminate the use of slogans, posters and exhortations for the work force” (The Leadership Institute). Management cannot expect higher levels of productivity by Dilbert-ish approaches such as posting motivational posters in everyone’s cubicles or having pep rallies. It is sad that Kaizen was created over three decades ago, but many software managers still think such artificially motivational methods are a valid way to improve their workers’ productivity.
Putting quality first indicates that, of all the goals of a business, such as generating profits or lowering costs, quality is by far the most important focus. No matter how much a company works on other aspects of their business, “the company will not be able to compete if the product or service lacks quality” (Imai 6). Management is always under great pressure to make compromises to meet deadlines or raise profits. If management loses focus that the quality of the product is their number one concern, then the business will have unhappy customers and will not be a business for long. Instead, managers must take the approach of “if you build it, they will come”. If the company puts quality as its highest concern, then customers and profit will follow.
Again, this ties into the aspect of process versus results. It is not enough to give the employees t-shirts bearing the slogan “We put quality first.” Management must make sure the work process produces a quality product beyond all other concerns. The software industry primary focus seems to be “time to market”, which has led to the culture of software patches and buggy software being the norm instead of something to be ashamed of.
Speak with data. For meaningful decisions to be made specific, metrics must be agreed on and tracked. This way, you can figure out where you are and how to advance. Without measurable data to refer to, you are cast into the darkness and have no way to know if you are improving on the process, staying stagnant, or actually regressing. The books on Kaizen are chock full of charts and diagrams to aid in deciding which data to track and how to track it.
The next process is the customer can be broken apart as follows. Each employee’s work can be seen as a process in a chain. The work you do as an employee is based on work handed to you by someone else (the supplier) and after you are done, it is passed on to someone else (the customer). While there are two types of customers, internal and external, each individual should be aware of whom their “customer” is even if the customer is internal.
Now that we have a workflow defined, our goal is for each person in the chain to have a commitment to “never to pass on defective parts or inaccurate pieces of information to those in the next process”. (Imai 7). Yet again, we need to keep the first axiom in mind to focus on the process and not the results. Management cannot just tell everyone to make sure they never pass on a defective product. They must ensure that there is a process in place, such as standard operating procedures or daily work methods for the workers to follow, that allows them to produce quality products for their internal or external customers
Jon Kenoyer
Thursday, October 2, 2003
Many people say that you can apply Kaizen in your personal life, too.
It think this is BS.
Why?
Because you improve one thing. That takes effort, usually every day.
Every time you improve something, you add to the effort you have to do every day.
So, one day, you'll break down.
NoKaiZen
Thursday, October 2, 2003
I specifically mentioned this in the paper as a knock against Kaizen.
"Another problem with Kaizen is that many shady organizations try to link themselves to Kaizen, either trying to make it a more spiritual movement than it was intended to be, or as a buzzword to sell their consulting services. So the reader must exercise caution when reviewing Kaizen sources and keep in mind that Kaizen is only a process to improve the work environment. "
I think one of the ideas is to improve your effiency so you accomplish more with less, not just do more every day.
Jon Kenoyer
Thursday, October 2, 2003
One of the problems in your thesis is the presumption that software is bad. Although this is a tremendously popular theme in popular culture, I would put it to you that software is tremendously good.
For a few hundred dollars it provides almost anyone with powerful transforming capabilties that did not exist even a decade ago. Those capabilities are the equivalent of things that used to cost many millions of dollars. Software works every day in thousands of different configurations.
Wagontrain Strike
Thursday, October 2, 2003
He is not saying that software as a product is "bad" (that is, he is not saying that software does not deliver or does not achieve worhwhile results). He is saying that the processes for developing software have unacceptable levels of delays, mistakes, and defects; and that the delivered product has problems such as unreasonable numbers of bugs and unsuitability of purpose. (If you have read Alan Cooper's book "The Inmates are Running the Asylum", you may recognize this sentiment as [paraphrasing] "people are not amazed because the lumbering bear dances *well*, they are impressed that the bear can dance at all".)
Yes, software is "good" and achieves worthwhile results, just like American automobiles of the 1970s allowed you to get to your destination much faster than you could walk, but software (and the software development process) could be so much better (as the Japanese automobile manufacturers demonstrated to the American manufacturers in the late 1970s and early 1980s). Today automobiles from all manufacturers in all countries are much better in many ways (glorified memories based on nostalgia notwithstanding), and some of us hope that the software industry can also go through such a dramatic improvement.
Philip Dickerson
Thursday, October 2, 2003
Actually, I dispute the basic premise of the original post.
Kaizen are not post-mortems. Kaizen is not about improving quality. At least, not directly. Kaizen sessions, as conducted by lean organizations, is about removing "muda" or waste from their processes. Waste also includes inventory, motion, waiting, extra processing, etc. Waste is anything that does not add value.
Removing waste often has the side effect of improving quality, since defects are waste, but it goes far beyond that. Kaizen is about improving the "flow" of production and improving the "pull" of goods from end-customer to base resources.
This might seem like nit-picking but if you simple equate kaizen with quality then, when you try to kaizen your shop you will get the kind of push back seen here: "what's wrong with our quality?". On the other hand, even the highest quality shop has muda, be it as simple as a milestone in production that adds no value.
The agile s/w development methodologies borrow heavily from philosophy and techniques of lean manufacturing. For example, the XP story board is essentially a simple, mixed kanban and andon board. The "value stream" of an agile project is far more compressed than say, a waterfall project: it has less waste.
Just my $0.02
anon
Thursday, October 2, 2003
I'm well aware of what he is saying and what do you think I'm referring to when I refer to popular culture? It is that attitude of Cooper and others.
I would have thought it was obvious in the context of this discussion that in referring to bad software I am referring to whatever the original poster means, which includes what you choose to define as process.
My point, and I make it explicitly to you, is not to blindly accept things just because so-called gurus espouse them.
Wagontrain Strike
Thursday, October 2, 2003
Oops. I should also say that I agree with the original post in that "lean" development is much less vulnerable to off-shoring than traditional development practices. Not immune, possibly, but less vulnerable.
It's taken for granted in the lean manufacturing world that oceans generally defeat leanness. This is why Toyota pretty much manufactures all it's cars for North American consumption right here.
Of course, software is a whole lot less sensitive to distance, but transporting goods is only one part of the equation. Agile development teams, like lean manufacturing teams, are much more dependent on communication in order to operate at top speed. It's that 8-12 hour time delay and lack of face to face communications that can be used to defeat off-shoring.
anon
Thursday, October 2, 2003
NoKaiZen,
It depends what you are improving.
Linking to the Joel test, lets say that todays effort improves my build process.
Now I have a one click build process, so instead of spending 25 minutes every day building, I spend 5.
Overall effort reduced, leaving me more for todays improvement.
Ged Byrne
Thursday, October 2, 2003
The above refers to Dickenson's post.
Wagontrain Strike
Thursday, October 2, 2003
[Now I have a one click build process, so instead of spending 25 minutes every day building, I spend 5.
Overall effort reduced, leaving me more for todays improvement. ]
Bingo. Perfect example. You have removed 20 minutes of waiting which was pure "muda" from your system.
After a while, you may actually kaizen to the point that you need fewer bodies on your project. Now, that may seem like a problem, but, around here at least, we have at least a half dozen potential new products that are not being developed because we can't afford to hire new people. Suddenly, those bodies can become available.
anon
Thursday, October 2, 2003
Kaizen doesn't work well for software commercial development. I might want to do daily incremental improvements, but I still need to do full QA testing before release.
Why should I make 10 changes (and do three days of QA) to version 1.0 so I can come out with version 1.0.1, when I can make a 100 changes (and still do only three days of QA) and release version 1.1.
Kaizen doesn't work if you have to do QA, and you have to do QA before you release your code to possibly millions of people.
NY.Software.Developer
Thursday, October 2, 2003
NY Dev -
I might be confused, but I thought the concept of Kaizen as applied to Software Development was referring to continuously improving the process of writing code, like documentation procedures, coding standards, methods of testing, mentorship programs, etc, not actually making continuous improvements to the *code* itself. Sure, you might refactor the code as needed, and that might be a part of Kaizen, but it's not the end all.
nathan
Thursday, October 2, 2003
[I might be confused, but I thought the concept of Kaizen as applied to Software Development was referring to continuously improving the process of writing code, like documentation procedures, coding standards, methods of testing, mentorship programs, etc, not actually making continuous improvements to the *code* itself.]
Right.
You don't kaizen the code, you kaizen your process and the way you develop product.
Btw, this doesn't only apply to coding, but to the entire organization. For example, let's say marketing is in another building and it typically takes at least a month for them to sign off on the requirements for your next release. The answer might be to move a representative of marketing into your team and eliminate the delay (possibly not as satisfying as shooting the entire marketing department, but probably safer in the long run).
anon
Thursday, October 2, 2003
One element of the OP's essay that I can relate to immediately is the disgust and low regard in which the process of software development is regarded by most employers.
I have worked in the anti-intellectual flyover country (midwest) for about half my career. The most stunning single element of technology company's lack of clue here is the way that owners and managers beat on programmers and engineers mercilessly for "pure" results and state emphatically that process means absolutely nothing to them, only results. In fact owners here HATE process implemented by techies because they see any diversion from the sweat shop mentality of pumping out the exact specific thing that you're hired to do as "waste".
IE: if a manufacturing plant were run like most SW shops I've seen, there would be no assembly line, there would only be workbenches with specific craftsmen working adhoc on the product, because the assembly line itself would not be associated with productivity because it's not "the product".
At a micro level, a typical example of this is being yelled at for developing tools or scripts to automate a tedious hand coded process. The usual comment is "why aren't you doing your work?" So, many times I've gotten my job done by subverting managements' "get it done directly" edicts and doing what needed to be done to do my work. IE: I've had to misrepresent my work in order to complete projects.
So, I am not sure that kaizen itself may be directly applicable to SW development. However, I think the thought process of designing the work process itself is important.
But such a thought process is probably 3 orders of abstraction above the capability of the meatheads that it could help the most... like any lesson, the people that need the help the most won't listen.
Bored Bystander
Thursday, October 2, 2003
I think there's a lot to be learned from Kaizen, TQM, Lean, etc, but none of them offer the silver bullet. You have to be careful. For example, the original post says:
"If the company puts quality as its highest concern, then customers and profit will follow."
Obviously this is true in some cases, but it is not a universal truth. You might be making the world's most perfect buggy whips, but that does not mean that you will make a profit. Quality is only a necessary condition of achieving your profit making goals, not the goal itself. Blindly following the "quality above all" mandate, while noble, can drive your business into the ground.
Similarly, the absence of quality is not necessarily a guarantee of unprofitability. Imagine you create a machine that is supposed to grant wishes. Unfortunately, it's a piece of crap and only works for every tenth wish. Do you think you might still turn a profit? I'd buy one :)
There are similar considerations when talking about measurements, muda, productivity, and so on. All of them are necessary to achieving your goals, but not always sufficient. They are tactics that need to be incorporated into a robust, goal-driven strategy derived from a clear understanding of your organization, its environment, and its capabilities. This requires thought, not fanatical adherence to a bullet point.
Read Goldratt (especially), Umble, Woeppel, Dettmer, and so on to flesh out the understanding. Check out David Anderson's new book, too, for a good argument for applying this kind of stuff to software:
http://www.amazon.com/exec/obidos/asin/0131424602
Muda
Thursday, October 2, 2003
[So, I am not sure that kaizen itself may be directly applicable to SW development. However, I think the thought process of designing the work process itself is important.
But such a thought process is probably 3 orders of abstraction above the capability of the meatheads that it could help the most... like any lesson, the people that need the help the most won't listen. ]
It's not really all that different in a manufacturing environment. How many CEO's, or even lower level managers, actually make it out onto the production line on a daily basis?
The key to success for this in software is also the same as in manufacturing. You have to have a change agent with sufficient power to make it happen. Unfortunately, most organizations only really embrace change when the only alternative appears to be death. This was the case with Porsche, Pratt & Whitney and other lean success stories.
It's very typical, when an organization goes lean, for the initial changes to be made at lightning speed. This is basically to break the inertia, show so quick, obvious improvements, and to not allow the anti-change forces time to really dig in.
So, while the process of making software is not at all like manufacturing, the problem of initiating change is identical. People are people in any industry.
anon
Thursday, October 2, 2003
[Similarly, the absence of quality is not necessarily a guarantee of unprofitability. Imagine you create a machine that is supposed to grant wishes. Unfortunately, it's a piece of crap and only works for every tenth wish. Do you think you might still turn a profit? I'd buy one :)]
That's why I emphasized that kaizen's are not about quality, but waste. If you can make that crappy quality wish machine with as little waste in the system as possible, you'll make more money, be more responsive to changes in customer demand, have less inventory, etc. Or so the theory goes.
As you said, it's not a silver bullet. I'm sure there was at least one really lean maker of clothespins that was put out of business when dryers were invented. The thing is that the lean clothespin makers are more likely to find some other business line than the old style batch and queue thinkers.
anon
Thursday, October 2, 2003
Thanks, anon, I agree with you. The main point I wanted to rant on is that one line preachings can't replace careful thought and clear understanding.
As far as waste, I've even seen this abused. For a while, "inventory is waste" was a mantra recited all over some manufacturing industries. The problem is that this is not always true. Sometimes inventory is necessary to protect you against Murphy. It requires a clear understanding of your organization, though, to be able to discern which inventory really is a problem, and which is giving a benefit.
Muda
Thursday, October 2, 2003
According to Philip Crosby, "quality" means "conformance to requirements", and hence that is why quality leads to profitability.
Quality does not mean "goodness, or luxury, or shinines, or weight". Unless the requirements of the product include these things (like when I was a NASA shuttle part vendor).
Quality is measurable, and the cost of quality is equal to the expense of nonconformance: missed deadlines, warranty service for bugs, rework and repair (patches and minor versions), etc.
Ankur
Thursday, October 2, 2003
All I was saying is that software development is a unique and pathological case in that most companies doing it believe that they are too smart to need to improve their internal process or to listen to anyone else.
IE, it's adequate just to "program" w/o considering how people go about their jobs. And what the programmer does is either regarded as elite rocket science and creativity not amenable to logic, or as something too filthy to consider. In fact, it's not uncommon in my area to see both tendencies in the same company: the self congratulating gurus who shelter their work from the anti-process oriented management.
Either end of the spectrum results in major waste and mediocrity.
Bored Bystander
Thursday, October 2, 2003
"All I was saying is that software development is a unique and pathological case in that most companies doing it believe that they are too smart to need to improve their internal process or to listen to anyone else."
I think there are additonal reasons for this. For one, there doesn't seem to be a lot of external pressure to improve. Computer users happily buy flaky software by the truckload, especially if it's from Microsoft. Internally, management looks at process/product improvement as a cost rather than as a means to increase future revenues (i.e. an investment). Also, many programmers feel that it's impossible to improve past a certain level because the OS and libraries that they use are riddled with bugs. Some even use this as an excuse. I've seen lots of instances where big bugs get swept aside with "it's that damned internet explorer component. We can't do anything about it."
mad at the world
Thursday, October 2, 2003
This whole thread presupposes that software developed in India and China is of higher quality, in a way very obvious to the mass-market, than software developed in the West.
Is it true? Can we see some examples?
Dennis Atkins
Thursday, October 2, 2003
I think the main reason for some of the skewed thinking in software development is that it's easy to see/measure the costs to crank out CODE, but the hidden costs of SOFTWARE are harder to nail down.
For example, it's pretty easy to figure out the costs of 10 developers working on a project for 6 months. What's harder to see is the cost of the defects that inevitably result. If I want to add 2 people or change the way the team works in order to reduce defects, it's difficult to justify in business terms since the costs aren't typically identified in the first place.
This even crops up in arguments against agile development. How many times have I heard the argument that pair programming is a stupid idea because it "cuts developer productivity in half" and therefore is wasting money. Now, that may be true (I dispute it) but what's clear is the people who make those arguments are usually not including defects and the effort to fix them in their calculations.
anon
Thursday, October 2, 2003
[This whole thread presupposes that software developed in India and China is of higher quality, in a way very obvious to the mass-market, than software developed in the West.]
Woah there.
No one has mentioned anything about the quality of off-shore development as far as I can see. I only mentioned that being agile is POSSIBLY a way to combat the transference of jobs off-shore.
anon
Thursday, October 2, 2003
"presupposes that software developed in India and China is of higher quality"
I actually used the low cost (American developers make 60 an hour on averge vs Inda developers who make 10 an hour on averege) as the main point. This is a bit confusing since I did not want to punish you all with the full paper :P
If both shops produce the same quality of code (crappy or otherwise) but one is 6 times as expensive then the more expensive one is going to be in trouble.
So the Japanese comparision is an analogy, not exactly the same.
Jon Kenoyer
Thursday, October 2, 2003
I think documenting your code is also a big waste of time since it doesn't directly contribute to getting the project done. Same goes for beautifying your code, or making it look "pretty". What's the point?
If Kaizen is about productivity, there's no point in wasting time on anything other than getting the project done, and going on to the next project.
VB6_Kicks_Ass
Thursday, October 2, 2003
"If Kaizen is about productivity, there's no point in wasting time on anything other than getting the project done, and going on to the next project. "
Kaizen is not about productivity. See anon's post above for a nice summary. Also, notice that it's not all about getting the project done, it's also about enabling you to get subsequent work done (the next project, bug fixes, whatever). Some kinds of work that you do now can be leveraged on many future tasks. Look up from your keyboard for a few minutes and think about it.
bah
Thursday, October 2, 2003
> I actually used the low cost (American developers make 60 an hour on averge vs Inda developers who make 10 an hour on averege) as the main point.
Actually, you said "My main thesis was that the software industry in the United States is facing a threat right now from offshore competition much like the 1980s United States Automobile Industry", hence my comment.
The advantage of Japanese cars was that they were of higher quality for comparable cost, not that they were cheaper. When Japanese cars were of lower quality and lower cost, they were not competitive and wer.e not a threat to the US industry, although some people bought them. It was only when the quality was higher that they became a competitive threat. So if you paper is claiming otherwise, the entire premise of your thesis is flawed.
Dennis Atkins
Thursday, October 2, 2003
[The advantage of Japanese cars was that they were of higher quality for comparable cost, not that they were cheaper. When Japanese cars were of lower quality and lower cost, they were not competitive and wer.e not a threat to the US industry, although some people bought them. It was only when the quality was higher that they became a competitive threat. So if you paper is claiming otherwise, the entire premise of your thesis is flawed. ]
Actually, the turning point for Japanese cars was the oil crisis in the 70's. Since Toyota was already in the process of "leaning" it was better able to take advantage of the changing economy (Toyota's time to market a new model was almost half that of Chrysler).
IIRC (having lived through those days), the big advantage of the Japanese cars was they weren't gas guzzlers. Quality became an important characteristic later. My old Corrolla was a total rust bucket, but it was good on gas.
My memory may be fading, though...
anon
Thursday, October 2, 2003
Hmmm. This makes me think ... one reason why execs can outsource/offshore IT jobs so easily is because they see "building software" conceptually as an equivalent task to "building cars". I thought the "community" (is there one?) would oppose this misconception (as some have done in this forum), but obviously the "community" already adopted that idea, and now is argueing based on that misconception.
See, that's what happened in the music industry some years ago. Basically you had a bunch of musicians and producers who had some sort of informal agreements with record labels. A new song was finished when it was finished. A few songs balanced a vast amount of mediocre ones. Enter fat cats. Creative musicians became slaves, giving away all rights to their works, while marketing experts unleashed a hurricane of marketing buzz because they "invested so much in that new talent". Production changed from small communities to huge "hit factories".
Why? Because musicians accepted the idea that it's better for them to "concentrate" on their work and let the execs do all the rest, i.e. decide how the creation and performance of their work is perceived in the public, how the listeners judge whether the musician created a remarkable piece of art (do you believe the billboard top 10 is a fair representation of artistic achievement?), and in the end put deadlines and schmemes on "content" being "produced" by the "artist".
"Look, Stacie, we've found out people are waiting for some Avril-Lavigne-Semi-Grrrl-Like-But-Sounding-Like-Christina-Aguilera-Performance. So you will sit down with our producer Bob this weekend, and get this song recorded Paul wrote for us yesterday. Don't worry, you'll get this done. Just listen to our trainers. (...) What? (...) Why? (...) Don't talk like that to me! You know, there's lots of girls out there who just wait for this one big chance. Ok?"
Johnny Bravo
Thursday, October 2, 2003
[Hmmm. This makes me think ... one reason why execs can outsource/offshore IT jobs so easily is because they see "building software" conceptually as an equivalent task to "building cars". I thought the "community" (is there one?) would oppose this misconception (as some have done in this forum), but obviously the "community" already adopted that idea, and now is argueing based on that misconception.]
Huh? Not sure who this is directed against, but...
This is an important point, but not just for software. There is a class of manager out there that thinks that making ANYTHING is basically the same. The lean/agile models fight this. The first thing a lean sensei will do is drag all the managers out of their offices and set up their desks on the shop floors next to where the real work is done. The idea is that only when you are in close contact with the work can you actually make intelligent decisions. I'd say this is generally true of any industry.
anon
Thursday, October 2, 2003
This is based on the assumption that any manager could unerstand the very nature of any work once he is in close proximity to the workplace. I believe that assumption is wrong.
If you put ten people each in a seperate room, all of them being music listeners for 20 years, and tell them to compose a song - how many of them will step out with a song which deserves being called "a nice song"? Or which deserves being called "conducted in an interesting way"? Or just "that sounds different"?
Johnny Bravo
Thursday, October 2, 2003
Not everyone working at a construction site and a helmet on his head is an architect. He might as well be a construction worker.
[no offense meant]
Johnny Bravo
Thursday, October 2, 2003
[This is based on the assumption that any manager could unerstand the very nature of any work once he is in close proximity to the workplace. I believe that assumption is wrong.]
Again, huh? I get the distinct feeling I'm not tracking your argument. Are you arguing for or against lean thinking? I can't tell.
Anyway, I'd think that putting your managers close to the workplace and then finding they don't understand it is a valuable piece of information to have, don't you? If they don't understand it in close proximity, what are they gonna be thinking when they're at arms length?
anon
Thursday, October 2, 2003
That piece of information generally was discarded in any IT company I've been working at. Many former team-mates have been displaced since then, their managers are still there. What does this tell us (or at least me)? Industry (especially the IT industry) is not based on rational choice or logical thinking on behalf of managers, nor do they believe it's necessary to understand the way a programmers thinks and works, otherwise the manager would quit his job once he realizes that. Thus I think the application of Kaizen or other "schools of thought" is futile in this field.
Johnny Bravo
Thursday, October 2, 2003
[Thus I think the application of Kaizen or other "schools of thought" is futile in this field. ]
That's a big leap of logic there. Your past managers were all idiots so applying some new thinking is pointless.
Ok, that's cool. I hope that, sooner or later, you find a manager that actually does more than occupy space.
anon
Thursday, October 2, 2003
Do you ever try informing or educating said manager? Or do you just complain to him so often that he gets numb to it? It's true that there are some people out there that just will not listen to reason, but that's not predominant in my experience.
contrarian
Thursday, October 2, 2003
Whose managers I talked about represent some 3 billion Euros stock exchange value. It's not your average 10-heads-startup where you just head for the manager's office and say "Let's talk for real: We've got some issues!"
Johnny Bravo
Thursday, October 2, 2003
[It's not your average 10-heads-startup where you just head for the manager's office and say "Let's talk for real: We've got some issues!" ]
What do you want me to say? It's hard to effect change in any organization, especially one that is not in immediate danger. Often you have to wait until there really is no other option.
But you're wrong if you think that's an issue in the software industry alone.
anon
Thursday, October 2, 2003
"But you're wrong if you think that's an issue in the software industry alone."
Hm. That's interesting, because that was my initial point: some issues apply not only to the IT industry. OTOH it's inappropriate to apply solutions to the IT industry which have been drafted in the car manufactoring industry.
Anyway, cool down, I never meant to have an argument with you.
Johnny Bravo
Thursday, October 2, 2003
[Hm. That's interesting, because that was my initial point: some issues apply not only to the IT industry. OTOH it's inappropriate to apply solutions to the IT industry which have been drafted in the car manufactoring industry.
Anyway, cool down, I never meant to have an argument with you. ]
I am cool. Apologies if my tone was argumentative.
I would say that I wouldn't assume that just because lean was driven by Toyota means that it's tailored for the auto industry. It is, and has been, applied to other companies outside that industry (Pratt & Whitney is a good example, Dell is another).
The agile methodologies borrow heavily from the philosophy of lean but the actual practices are tailored for our industry. It's more than simple physical production practices transferred to software.
anon
Thursday, October 2, 2003
I thought we've been talking about the software industry ... ? P&W and Dell both build hardware systems. I have yet to discover a software company which applied any Toyota/Kaizen/Five S methods successfully.
Johnny Bravo
Thursday, October 2, 2003
[I thought we've been talking about the software industry ... ? P&W and Dell both build hardware systems. I have yet to discover a software company which applied any Toyota/Kaizen/Five S methods successfully. ]
Is that surprising given the resistance in some organizations to agile methodologies? The software industry is only now beginning to learn about lean thinking. You may be right in your objections. The jury's still out.
We do XP where I work, but I wouldn't call us lean. We're starting to think in that direction but there have been no real initiatives as yet.
anon
Thursday, October 2, 2003
[ I have yet to discover a software company which applied any Toyota/Kaizen/Five S methods successfully. ]
Just to add to that, I don't know of any software company that's tried to apply lean and failed either. If you know of some examples, please share. I'd love to read about them.
anon
Thursday, October 2, 2003
EDS in Europe. You need more examples?
Johnny Bravo
Thursday, October 2, 2003
If you got 'em, post 'em.
anon
Thursday, October 2, 2003
Mature industries repond better to incrementalism than younger ones. Henry Fords assembly line wasn't a small improvement. As software processes mature, they will increasingly benefit from the rigrous application of kaizen.
"Incrementalism is innovation's worst enemy" - Negroponte
Look at how well the US and Europe compete with Japan in software vs automobiles.
fool for python
Thursday, October 2, 2003
I think Kaizen actually contradicts Joel's philosophy.
Joel's philosophy, as I read it, is that developers know more about development than most business managers and produce better software if allowed to.
By comparison, Kaizen, as explained here, seems to be yet another externally imposed edict. In other words, yet another attempt by generalist management to try to impose order on something they don't properly understand.
This analysis also explains why foreign outsourcers have no background in successful creative software development. They are the companies that develop industry breakthroughs.
.
Friday, October 3, 2003
That is, companies with a background in successful creative software development are the ones that develop industry breakthroughs.
.
Friday, October 3, 2003
In the OP it was not clearly stated but one of the main Kaizen rules is that the employeers must collect and listen to feedback from thier employees, and that most improvements in the process come from the people actually doing the work.
I agree that in the software development world having a formal system is a bit much but the basic idea is so obvious hopefully software managers listen :)
Jon Kenoyer
Friday, October 3, 2003
Johhny Bravo, are you saying EDS tried Kaizen and blames it for failing, or EDS says Kaizen helped?
In either case can you post a link to the source?
Jon Kenoyer
Friday, October 3, 2003
> In the OP it was not clearly stated but one of the main Kaizen rules is ... that most improvements in the process come from the people actually doing the work.
OK. Interesting.
.
Friday, October 3, 2003
[By comparison, Kaizen, as explained here, seems to be yet another externally imposed edict. In other words, yet another attempt by generalist management to try to impose order on something they don't properly understand.
]
This is almost completely opposite of the idea of kaizen. Kaizen are meant to be frequent process improvement sessions driven by the people that actually work with the process.
For example, if a team at an auto manufacturer holds a kaizen session it would be the workers in the actual cell that drive the improvements. Management would be there as well, but there input would be no more, and probably less, than the average employee.
anon
Saturday, October 4, 2003
[That is, companies with a background in successful creative software development are the ones that develop industry breakthroughs. ]
Kaizen and lean techniques have little or no relationship to "creative" processes.
For example, 3M, which might very well be the most creative single organization in the world, uses a lot of lean techniques. They also have a rule that their research scientists are supposed to devote at least 15% of their time to new, startup projects.
There's absolutely no reason why you can't be creative and eliminate waste at the same time. In fact, you might argue that eliminating waste helps people be more creative.
I'd also argue, at least in the manufacturing world, that industry breakthroughs do not automatically guarantee success. Toyota is case in point. Toyota is not a particularly innovative company. They are usually behind the curve on new product types (see their late entry into the mini-van and SUV markets). On the other hand, by about 2010 (and perhaps earlier), they are going to be the biggest automobile maker in the world.
anon
Saturday, October 4, 2003
 Recent Topics
Fog Creek Home
|
