there a two stories I can tell from McDonalds on my own. First of all I was today at a local McDonalds and the personell there was creepingly slow. Some of them. There were clear queues, two counters open at lunch time, come on. This can’t be true. Well, it was. Not that fast for a fast food restaurant at all.

[I suspect that the workers were simply being slow, right? It's hard to "process improvement" that away, isn't it?]

Second some years back they had a one-minute bet at McDonalds Germany. After placing the order until it got served there was a bumper that counted down 60 seconds. Waiting 60 seconds for your meal seem rather short, but there fits a whole bunch in 60 seconds. (Maybe it was 30?) They removed it since it didn’t serve their needs. Maybe the personell at the store I was today ruined the company, I don’t know.

[They certainly ruined that store ...]

Just my 2 cents.

I enjoyed this post, thanks for sharing.

I think this kind of thing ties back to “individuals and interactions over processes and tools”.

[Totally man; I have an article coming out shortly on the people side of agile. I suspect you might enjoy it.]

There is a lot of value in a good process, however, if you’ve got someone THERE, who’s actually getting it done, and they have a better idea, you’d better listen to them. I think we’ve got to find ways to look for good processes, but at the same time encourage innovation, and not be afraid change (or failure). It’s not an easy balance.

How does this apply to code? Simply put, if there are modules or functions that have already been tested and proven to be the most efficient, then those artifacts should be reuse. While it’s great to be creative and write code to solve a problem, if there’s an existing solution you should examine it and determine if you can do it better. If not, you should use the existing code. If you can write it more efficiently, write it and submit it for the library of reusable content.

[No argument so far. A little nuance below, maybe.]

More lines of code does not mean you are a higher performer, less lines of code may be. How quickly the code processes information is the key measurement of performance and a developer should be held to that metric above all others.

[I'm not sure what you mean by "how quickly the code processes the information". If a dev spends a year writing a routine that runs in ten minutes to write checks, and the other dev writes it in a week and figured "it can run overnight", who is the better dev? I suspect you mean something a little deeper, but I'm afraid I don't quite grok it yet.]

Of course, this is only my opinion.

[I do respect your points, and, to some degree, that's what I was trying to get across when I wrote that a lines of code are not created equal. I do think however, there is some nuance we both assume that an uncritical reader might miss: For example, the process of figuring out what code should be reused, and how to reuse it - how, exactly, do you standardize that? I suspect that you can have rules of thumb, but the individual contributor will have to actually think. And I am okay with that.]

Seems to me that they key to what the staff in your example really needed was motivation. This could be driven through “raises and bonuses” as you suggest or simply an improved sense of team spirit, shared responsibility and making their work more enjoyable. The staff might then be encouraged to identify their own ways of acheiving performance improvements. They would certainly be in the best position to identify improvements that could be made.

[That's a good point, Adam. A little time away from the cash register for all-staff meetings to talk about the direction and goals of the company, or free passes to the waterpark on your day off, where your team builds a skit for the next all-staff ... people are motivated by all sorts of different things. Somewhere in that park, there is a manager in charge of that shack. Actually figuring out what is taking so long, helping to get it done faster, and figuring out how to help people with their internal motivation, is, very likely, a neglected part of his job.

Sometimes, he just might need to express appreciation and thanks. Speaking of which thank you for your contribution.]

Adam.