The dark side of agile development 3/5: Our client, our soulmate

The Agile Manifesto is a very functional and effective concept. But multinational corporations sometimes interpret it in their own way and distort its ideas. Therefore, when I talk about the dark side of agile, I must also devote some time to the dangers of a foolishly designed project proposal by the client.

Agile can only be successful if all parties understand its working and its limits. The freedom offered by this method is redeemed by consistency not only of the developers, but also of the client. If you don’t have the capacity to accurately plan and follow a predetermined procedure, agile is not the right choice for you. Here we come to the problems that often arise when working with large multinationals, where a large number of people comment on the proposal, and the comments are often very random.

Within the agile methodology, the client can also resort to fixed price considerations, which are the foundation for custom development. Here, the client often requires the attainment of formal rather than content goals. And because the client does not have enough insight into IT/SW development, they may have difficulty understanding blockers and other challenges. Usually, the client expects a gradual delivery of software, along with the possibility of constant changes in the assignment. And, throughout the process, they often interfere in elements outdated and/or resolved.

Here’s an example: The client approves the design of a login form, and developers start working on it. They’re almost done when the client decides to add a brand new special box to the form. And then everything has to change.

SCRUM offers the client the possibility to change almost anything at any time. Thus, clients have been known to illogically modify targets for individual iterations. The agile method, on the other hand, requires binding confirmation of individual units, and focuses on delivering smaller, functional parts of the whole project.

It would then be good practice for the client to wait with their new box until the next iteration. (Of course, it would be ideal if they knew that they needed the box when ordering the latest software job.)

In addition to discipline and planning skills, agile development also requires face to face communication. Especially when ordering the project. In this way, it is possible to communicate a clear definition of the assignment with the client, and to understand each other and the procedures well.

For multinational corporations, it is also necessary to take into account common problems associated with the different time zones in which the project participants are located. And, perhaps a much more complex issue, the legal differences between the countries.

Nevertheless, we are still talking about resolvable obstacles. I don’t want to scare you – we’ll get to that next time, in the fourth part of this series, where we’ll describe what the world would look like without project managers and a well-set budget.

Dmytro Trofymchuk
Division Director

RSS