Tuesday, August 25, 2009

Presumption of intellect

I’d like to talk about yet another obvious public trend, opposite to the main vogue in choosing SLCM for a software development project.

Have you noticed that different institutions, be they business or governmental units, while communicating with people presume people’s foolishness from the very start? Just try to place your inquiry or claim to, for instance, a bank, or to a phone company, or to a local or federal government, and you instantly would feel yourself complete idiot. Having no real choice, you will be routed through unnecessary silly options, you will be forced to answer silly questions having nothing to do to your exact inquiry, etc.

As is customary, all this is covered up by striving for universality mixed with concerns about enough level of political correctness. Those guys who make decisions just say “We need to communicate with everybody regardless of race, age, sex, health, etc!” So far so good. However, the next decision “Whoever we talk to, let us do it in absolutely the same way!” is quite disputable. You cannot talk to all people in absolutely the same way. It’s obvious, because people differ greatly in their educational level, in their abilities to quickly absorb new information, in their current emotional state, etc., etc., etc. So, to make communication effective and comfortable to the both parties, reasonable gradation of possible audience should be presumed. Unfortunately, those who should do it, never trouble themselves. They rather prefer to consider all the people being at the lowest possible level of intelligence, and thus all the standard options and questions in surveys and in standard dialogues are intended for people on the brink of mental illness.

The result is disastrous, since in fact the brink of mental illness is suggested as the norm for the human society. Just have a look at the vast majority of sitcoms, of commercials, of movies, of fiction books, etc. All this cultural junk food is intended for “normal” members of human society, i.e. (see above) - for the people on the brink of mental illness.

Little by little the society accepts these understated norms, and little by little society becomes sillier and sillier in average. On the contrary: If norms were just a bit overstated, the society would have moved forward to be cleverer and cleverer in average. It’s easy: Try to talk to a person as if he is fool, and you will talk to a fool; try to talk to a person in a clever manner, and you will talk to a clever enough and reasonable individual.

So, what am I talking about? Strange though it may seem, I am getting at software. Absolutely the same excellent result of choosing presumption of intellect rather than presumption of stupidity can be seen in managing software development projects. Try to behave with your customer as with an idiot and you get a non-reasonable, stupid and very difficult customer. Behave with a customer as you would prefer others behave with you (i.e. in a clever way), and you get reasonable, interesting and efficient partner in working on the project. I think, it is one of the main reasons why the software community slowly shifts to use the Agile model, whatever is meant by “Agile” in each particular case and whichever related practices are used.

Monday, August 3, 2009

Rules for Agile wanted

Agile, Lean, Kanban and kindred software practices present different variations on the same theme: How to do software development more effective, i.e. how to provide customers’ happiness with more confidence.

At that, to large extent, lean/agile approach for software development still remains just an idea. It can be called culture, but anyway now it is more about general understanding, about attitude, about something in one’s mind, so let’s call it idea. Interesting, good and prospective, however just an idea. It works perfectly for development teams consisting of almost equal members, each of them of high knowledge, high creativity and high productivity. No doubts that for such an ideal team working for a reasonable customer lean/agile approach seems to be a perfect choice. Unfortunately, 99% of teams are not ideal. For instance, a non-ideal team can be of a following structure:

  • creative, knowledgeable and skilled team lead,
  • ¼ of the team is creative and skilled,
  • ¼ of the team is more creative than skilled,
  • ¼ of the team is more skilled than creative,
  • ¼ of the team lacks creativeness and skills, however these guys are sufficiently responsible and diligent.

Range of “non-ideality” of a development team can vary substantially, that is why we need definite clear rules of thumb to organize lean/agile processes for an average team.

Similar rules for widely used SLCMs are well known. Certainly, these rules are not carved in stone, and mostly they even do not exist as written lists of regulations. These rules are defined indirectly, being backed by something very well thought out like sets of standard documents/records that should be kept throughout the project and/or sets of special software to support all the stages of the SLC. It is true for the waterfall model as well as for the iterative one implemented by RUP/IBM or by Microsoft.

Existent rules not only make it possible for an average team to deal with a project, but they also eliminate misunderstandings and disputes between developers and customers: The both sides have the same landmarks from the very beginning. Absence of such reference points in the current agile projects is supposed to be compensated by flexibility both of the developer and of the customer as well as by common sense of the parties. Sounds more feasible than it really is for an average development team and an average customer.

So, what we need now to make lean/agile approach really applicable widely in software development projects is backing of this idea by clear rules. This situation can be compared to the early automotive era: Newly invented cars are able to move faster than pedestrians and coaches, that is why we are now trying to use these new vehicles, but it is difficult to drive a car along the roads because there are no traffic laws considering cars, and thus, we easily stir resentment of passengers, pedestrians, coachmen and policemen.