IT Project
Organization and Project IT management
Agile – always the best way ?
Recently, there has been a lot of talk about the Agile methodology from both the Client and the IT Service Provider perspective. With a great deal of enthusiasm (and less criticism), its advantages are presented, such as better adjustment of the delivered software to the end user through constant cooperation in "self-organizing" Client teams or mixed Client and Provider teams. Delivering software in successive increments (sprints) as working prototypes is to ensure the achievement of the best final solution, etc..
So much for the theory, but what about practice
For years I have been running projects using various methodologies, including those using elements of the Agile methodology. I have also created dedicated methodologies several times using various elements of other methodologies, in order to optimally match the subject of the project. On the Internet I found a very interesting publication, in which, based on research in the UK and the USA, it was determined that companies using the Agile methodology have a 268% greater chance that the project will end in failur.
268% Higher Failure Rates for Agile Software Projects, Study Finds | Engprax
Unfortunately, my practice also confirms this. Uncritical use of this methodology (generally any other methodology too) leads to disappointment of the Client and the Supplier. What is more, in my opinion it indicates a certain misunderstanding of what a project is and insufficient project practice and ... marketing well-done work of various, mainly commercial, business messiah 😊.
In my experience, the main causes of this state of affairs would be the combination of several or even all of the following problem:
- Both the Client and the Supplier, often declaratively and/or without much understanding, try to apply Agile. Although, like any methodology, it is a set of good practices, not a recipe for successful project implementation. Therefore, it should ALWAYS be adapted to the realities of a specific project. i.e. project goals, the subject of the Project, project teams, deadlines and budgets, etc.
- The Client expects the Supplier to "sign with blood" under the deadlines, budget for an unspecified scope of the project with unspecified declarations of the Client regarding the involvement of their own resources in the Project. The Client usually expects the delivery of the work in the form of a working IT solution. The Client will tell the Supplier about the scope of the project (expected solution) during the project, because "that's how Agile works". In sprints, they will assess whether the prototypes being created are what they wanted. However, with such an approach, it is rather a recipe for disaster or at least a designed future disappointment of the Client that the project, neither in this scope, nor in this budget, nor in this time, does not happen/happen.
- The supplier expects the Client's team to be highly involved in defining requirements, setting the tone in the project, and directing the work. After all, we have Agile and it has its requirements. Somewhere here the thought gets lost that the Client does not run a business aimed at building and implementing IT solutions, but runs its own business, and IT solutions are to help it. Working on an IT solution is an additional huge effort on the part of the Client. Therefore, after an enthusiastic start to the project, the Client begins to realize that Agile means too much of a burden for its people (perhaps if it knew what an Agile project means before the project, it would have prepared itself accordingly by creating space for its people for the project - this can be done, but who among the managers thinks about it). When faced with the problem of whether business or project will always choose business. Therefore, on the project, the Client starts to use 'workarounds', tricks such as, or maybe Professional Supplier, work there yourself in sprints, because we have to earn for all this and come with something that works... And from the whole idea of Agile, only sprints remain. Then, mutual complaints begin: the Client does not cooperate and the Supplier is unprofessional, because he himself should know what and how to do it, and we have a growing problem in the project, even though both Parties created it.
- The client usually does not realize that the project means a very large involvement of their best resources in the Project (usually their core business is based on them). Therefore, preparation for the project, especially one conducted using the Agile methodology, requires good preparation and temporary redesign of one's own organization for the duration of the project. Otherwise, both the business and the project will suffer.
- The supplier is in a comfortable situation because, according to Agile, they wait for the Client rather than showing any desire to complete the project. They have a good explanation for why the project is dragging on, getting more expensive, and why its scope is expanding. And here it varies. A good supplier will want to complete the project, so they will take over the Client's role a bit and will actively start proposing solutions that may or may not be right. But that's not what Agile is about (!). It's supposed to be close daily cooperation, not a "game of ships" about who will sink whom.
- Agile assumes the gradual discovery and implementation of the Client's needs. Therefore, it is very difficult for the Supplier, the PM Supplier to declare deadlines, budgets and manage changes in the Project to the Client. In particular, when the subject of the project is a large system (e.g. ERP), with a high degree of internal integration between modules and many integrations. In such a case, the arrangements and implementations in one sprint may not match the arrangements and implementations in subsequent sprints and you either have to wait for firm arrangements or some of the implementations will be unsuccessful (mainly cross-area topics). And the Client (understandably) does not want to sign up for a project where he does not know when, what and for how much he will receive. And again we have a situation in which either the Parties pretend at the beginning of the project that there is no problem, or in the end the Client agrees to such an arrangement complaining about deadlines, budgets and an unprofessional Supplier. In extreme cases, we have a stalemate and the parties part with a bad taste in their mouths...
- Another aspect that is rarely raised, but has long-term effects. Agile strongly emphasizes the importance of the solution over its good documentation (I know that there will be people who will say that this is not true, and I am writing about Agile practice on real projects). In my opinion, this is a very controversial and harmful assumption. Why? If there is no proper documentation, both substantive and project-related (who, when, why changed from which to which arrangements), then often everyone understands these arrangements as they think, and the assessment of the project becomes increasingly subjective (depending on who is asked whom). THIS has the consequence that we have a process of creeping arrangements and creeping project scope. Of course, someone will say that sprints are for doing it right away, but practice shows that this is not done. Therefore, it is difficult to implement, test, train, service and develop a system after a production loss based on "the collective memory of arrangements". Why something works this way or that (I optimistically assume that people on both sides remember these arrangements consistently). Additionally, the lack of good documentation is also an area of potential disputes about what the Supplier was supposed to deliver and what they delivered. What is a change to assumptions, development, and what is covered by warranty, etc
Of course, Agile, like any methodology, has its advantages, provided that we apply it correctly, to the right projects and with the right approach of the Client and the Supplier. In other words, it is used wisely! My experience tells me that Agile works well in smaller projects, where the IT solution is actually written from scratch or based on some initial solution. Also in projects where the Client's business feels the need, but is unable to define it at the beginning of the project and agrees to the consequences resulting from the nature of Agile and is well prepared for this type of project. The parties must also be aware and accept that due to the undefined/unspecified scope of the project, both the deadline and the budget can only be estimated and then gradually verified during the project implementation. However, they cannot be a goal in themselves and be treated as a delivered work with such parameters, i.e. with a pre-defined scope, deadline and budget. Managing change in the Project is difficult, because the essence of Agile is the search for the best solution by the project team - i.e. constant intention.
That is why I prefer methodologies optimized for a given undertaking, a project, which draw on various good practices, from various methodologies. However, this requires project experience and a broad perspective on the subject, so as not to lose the success of the project. What I will write about in the following articles.
Ostatnie wpisy
Zaproszenie
Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.
Zaproszenie
Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.