Hi, guys! This time we are going to touch on the issue of software development methodologies. Undoubtedly, this theme is rather ambiguous and causes controversy among a lot of team members. Our users often express diametrically opposing views on the appropriateness of using different methodologies in the work process. At the same time, each side provides reasonable arguments in its favor. We could not remain indifferent to this question and tried to give our own assessments of the issue.
Agile, Scrum, Kanban… About each of them much is written, all their principles are well-founded and studied. It would seem at first sight, that their purpose is extraordinarily obvious — simplify the workflow. But in practice everything turns out a little differently. Suddenly, instead of making the work process more transparent, the methodologies impose additional obligations on developers. So it happens that for all theoretical benefits their usage proves extremely uncomfortable in reality for one simple reason: you always require some additional stimulation to comply with all the basic principles of the chosen methodology. All retrospectives, meetups, standups, backlogs and planning pokers are necessary solely as an incentive for developers to do something they really don’t want to do. And for this process of stimulation you need special qualified person in a separate position, whose task is monitoring the fulfillment of all the preordained commandments.
Of course, the main purpose of any methodology is not to confuse and complicate the development process. As well as it’s not about simplifying or making it clearer. The main aim, sought by applying any methodology to а project, is standardization. Having thought up (or borrowed) a set of rules of project management, it is possible to achieve a situation when any question can be solved using this very set of rules. And it does not matter what kind of issue this is, Agile/Scrum has an algorithm of behavior that will tell exactly what to do with this or that task.
If it seems to you that after the applying scrum to the project everything just got complicated, then it definitely does not seem, it really is. And this is normal. If you see that after the implementation of a methodology you need to do some complicated bureaucratic actions, then this is certainly inefficient from the view of a specific problem solution, but it is extremely effective from the view of managing the entire project as a whole.
Beware of Methodologies
However, sometimes methodologies can do you a disservice. Almost every team, as it begins software development, tries to keep under control the entire workflow in order to avoid any accidents and risks. For this purpose, managers turn to various methodologies, hoping that the experience of other companies will be applicable in their practice too. For some simple typical tasks this can really work. But, in our opinion, blindly following a methodology may be fraught with a significant reduction in development effectiveness.
Not so long ago, we came across a very old article of Joel Spolsky, which has not lost its relevance today and stays a canonical example of the correct company scaling. Or “methodology”, if you will. The article raises a question of a company’s success or failure (regardless of a field of its activities) and a role of a methodology in its fate. The author describes quite interestingly how the methodology arises, and why her seemingly noble goals ultimately worsen results of work. And it does not matter whether it’s about IT projects or about the food industry — the principles are the same.
Of course, nowadays it’s hard enough to surprise someone by comparing an IT company with the McDonald’s work organization, but in those days Joel’s article was very successful. And the term “Naked Chef” from this article is still widely applied to developers-improvisers of a high level.
We are not entirely sure whether this is a laudable term or an abusive one. And what do you think in this regard? Do not hesitate to share your opinion and experience with us on this matter.
What to read next:
- Agile Project Management with Riter
- Laws Of Productivity: Work Better, Not More
- Proper Task Management
Originally published at Riter Blog.
