Skip to content

Category: peopleSyndicate content

Chopper Shops

June 22, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

I have been watching an episode of American Chopper the other day. I must admit that I am a bit of a fan of this show – not necessarily because of its main plot premise of a clash of personality between the father and the soon (which is rather cheesy and quite clearly badly acted instead of real), but rather because I like watching “how stuff is built” - in this case, how you can build a gorgeously looking motorcycles from the rusty pieces of metal, using not much more than a set of rather primitive tools.

It was an episode where the guys at OCC bought themselves a super modern, computer-controlled metal-cutting machinery of some sort. At the same time, they had to resort to making order with some misbehaving part of the motorcycle being constructed by whacking it hard with a big hammer.

Watching this show got me thinking: this sort of work is very similar to what I am doing every day creating software. I always cringe when I read somebody likens software development to a factory line. Even if it is an “agile” factory line – like the Toyota Production System, which a lot of people in the agile community hold in such a reverence to that they almost pray to it daily. Because, you see, software development, in teams big or small , organizations huge or microscopic, is always a chopper shop rather than a factory.

Livestock

March 17, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

"How many resources do you need for this project?”. "How much headcount” - or even: "how many headcounts” – "do we need to hire?” If you are working or have been working in any sort of corporate environment, chances are that you have heared sentences like that. If you are a project manager, you are maybe even using them in your daily work. This sort of vocabulary became common in the software industry and people use it without giving any thought to what these words really represent. "Human Resources” is typically the name of your people-management departament.

If you use phrases like that, please stop. Now. Not because it is offensive to the ones you call "resources” (though it is), not because you are vulgarizing the english language (you probably are, but I am not a native English speaker, so I don't much care. But similarly ugly HR-type phrases made it to my mother tongue unfortunately).

The valid, business-related reason for stopping this sort of language is that reffering to your people as "resources” skews reality and does measurable harm to your projects.

To Motivate or Not to Demotivate

September 30, 2008 by JurgenAppelo

Motivation2

Some people tell me that "you cannot motivate a person". You can only "remove the impediments that prevent a person from being motivated". Or, in other words, "you can only eliminate demotivation".

Well, I don't agree!

Can you make a person happy? Or can you only eliminate the things that make her unhappy?

Can you make a person laugh? Or can you only eliminate the things that make him cry?

These sound like silly questions. But I have been told a number of times now that trying to motivate people is a bad idea. Yet, I simply could not imagine this to be true, given the fact that it is quite possible to (try to) make people happy, or to (try to) make them laugh.

The 1st Law of Software Development

September 9, 2008 by JurgenAppelo

Motivation There are at least three reasons why people are the most important part of any software project. And this leads to (what I would like to propose as) the 1st Law of Software Development...

Three Reasons for You to Feel Important
In an earlier blog post I have argued that software development is primarily a creative activity, and people are the most (if not the only) creative participants in any software project. (In my experience, they can also be the most destructive participants, but that's another story.) It appears that software development, as a creative endeavor, is all about people.

People over Process: a Universal Law

August 12, 2008 by JurgenAppelo

People Despite the progress we made in software engineering in the last two decades, some people still believe that processes can be more important than people. Sure, they have a more "balanced" view these days, claiming that people and processes are both important, and that you have to consider the business domain to see which one "trumps" the other. But they refuse to believe that People over Process is a universal principle.

Well, they are wrong.

Consider the Law of Requisite Variety:

"Only variety in a system itself can successfully counter a variety of disturbances in the environment." or "Any effective control system must be as complex as the system it controls."

Agile , Tacit and Web 2.0

December 22, 2007 by pinastro

I have consolidated some good definitions and principles on the topics Agile Development / Tacit Knowledge / Web 2.0

What Wikipedia says about Tacit Knowledge :

Are you assigning your top engineers to projects?

November 5, 2007 by Artem Marchenko

Soldiers in front of Capitol

Some companies are very picky at making sure that all their employees got a project to work on. Especially the top engineers. I've seen quite many environments, where senior guys are the ones who have to be "120% utilized" and who are actually doing the work, while juniors are expected to be floating around doing "something not critical" and being asked to help seniors, whenever those would need an extra hand.

Agile Layoffs

March 17, 2007 by Artem

Agile processes often enter the organization from the grass roots - from the developers appreciating useful practices and insightful low level managers seeking for ways to help their subordinates. However, if things progress well, at some point the top management might buy the idea of delivering incremental software faster, than the competition, and declare "we are going Agile" or even "we are going AGILE". While the top management support is something to appreciate, there is still a number of issues to be aware of, when restructuring mid to large size organizations. One of the most important changes is the potential career ladder restructuring.

Destructive bonuses

February 4, 2007 by Artem Marchenko

Many if not most of software development companies employ some kind of the bonus plan for their developers. Developers or teams get a set of targets to reach and depending on the target fulfillment the bonus is paid. The idea of compensating the extraordinary performance and success is a good one. Unfortunately there two major problems with the bonus plans:

Expected bonus is not a reward

As Joel Spolsky puts it "They [bonus plans]'ve become like tips in restaurants: everyone expects one, so they can no longer be used well to award performance". Most of the good managers I've heard of try to plan the bonus targets so that their subordinates would get about the same amount of money whatever happens.At the time when there is a reasonable lack of programmers everywhere, it is just too dangerous to have an employee that expected the bonus, but didn't get it. The received bonus feels like something expected, while the one that was not received feels like a punishment and most of bosses wouldn't like their employees to feel punished.

Process over the individuals

April 9, 2006 by Artem

Individuals and interactions over processes and tools © agilemanifesto.org

Lately on a Russian programmer forum I've read a story about the usual victory of a process over the individuals.

One software development company had Windows and Unix stations. As a result from time to time the wrong endline characters leaked into the repository and caused the build breaks. There were two ways to overcome the problem:
1. To oblige everybody to check the files before the commit

Best of AgileSoftwareDevelopment.com