On the way from a historic factory to an IT developer, many things can change, improve – even go wrong. The methodology can easily turn into a marketing motto and charade. Good intentions can do more harm than good. The final number in our dark series brings a summary and a few poignant answers.
The dark side of agile development (5/5): Is it worth it?
A brief history excursion: in the 1940s, Toyota’s Japanese factories began to focus on eliminating “muda” (waste, anything that does not create value for the customer). The rules included, for example, not sending defective workpieces for further processing, producing exactly the amount needed for further processing, and communicating via kanban (taskboard).
Active communication between the representatives of the individual sections of the production process was vital. With this philosophy, based on “kaizen” (continuous improvement), Japanese factories began to enjoy a greater and greater competitive advantage over the American ones. And as you may have noticed, it is from this philosophy that current agile development and SCRUM has evolved.
Back to the present. What does SCRUM look like in reality?
I mean to say, we value all our clients, regardless of the methodology they prefer. We know how difficult it is to implement true agile. It is clear to us that stakeholders are always limited within organizational matrices, and a change in such an aspect can require a change in the entire corporate culture. The following is not a criticism, but an objective view, one we would like to help with.
There are agile developers who use the name as a marketing slogan, when in fact they do not use the method properly. Clients demand it because it’s modern – and yet often do not understand it fully. This is similar to a customer buying a camera, looking only at the amount of megapixels – regardless of the type of sensor and other major, more complicated parameters.
