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.