Classic or agile? … the dilemmas of a project manager
In the previous article, we focused on ways to optimize the scope of the project to reduce unnecessary costs. However, it's important to remember that not only what is being delivered, but also how we choose to deliver it can impact cost efficiency. There are two widely recognized project management methodologies: traditional, waterfall-based approaches (such as PRINCE2) and agile methodologies (like SCRUM and DSDM). The traditional approach relies on detailed planning of the project schedule with a clearly defined phase of defining project requirements, analysis and designing the solution, which is then implemented in a subsequent phase, tested, and finally deployed. The agile approach is based on incremental and iterative development, where shorter cycles (e.g., Sprints) are defined, during which analysis, partial product creation, testing, and deployment are carried out (not necessarily after each cycle, but with the goal of deploying as frequently as possible). These cycles are then repeated multiple times, creating successive parts of the final solution. There is no methodology that is clearly better than the other one, it all depends on the specificity of the project and the circumstances in which the project is carried out. Many articles have been written comparing waterfall and agile methodologies, so I'd like to approach this topic from a slightly different perspective: the expectations of clients versus the expectations of software houses.
The initial expectation of a client when engaging a software provider is to be presented an estimation of costs and a project implementation timeline. It is understandable that every client wants to limit their risk and expects a precise definition of project costs, as outlined in the contract. From the perspective of the software supplier, this is a difficult task, especially if the planned system is an innovative system, unlike previously implemented projects. If a client insists on such an approach, it is natural for the provider to require a detailed list of all requirements and conduct a thorough analysis and design of the system. In many cases, it turns out that despite their belief that they know exactly what they need, clients are unable to prepare a description of the requirements on their own at a sufficient level of accuracy. We often receive a "requirements specification" for a system that fits on 1-2 pages of A4 paper with a request for a quote. This level of precision is insufficient to estimate or build an entire IT system, unless it is a very simple project. For us, such a document is merely a starting point for determining the project scope and requirements. Many clients do not realize that to write detailed requirements in the style of waterfall methodologies for a complex IT system, hundreds of pages may be required, and the process of creating and confirming such requirements can take several months. Additionally, it is difficult to write requirements in such a specification in a way that is always understood consistently by all project participants. The lack of current clarification of the product vision may result in significant differences in the interpretation of a given requirement being revealed during the product presentation. There are situations where a seemingly simple requirement is interpreted literally by a programmer, while according to the client who wrote it, it should be interpreted as many different functionalities linked together that were not described, because for them it was obvious. Proponents of Agile often illustrate these discrepancies using the example of drawings of a tree swing as seen by the client and the individual members of the project team (The tree swing analogy). While this analogy may seem exaggerated, several years of experience working at the intersection of business and IT have unfortunately proven to me that this is not the case.
For each project, it is necessary to consider whether it is worth starting with such a detailed analysis, or whether it is better to opt for solutions suggested by the agile approach, where analysis is conducted within each development cycle (Sprint) and focuses on a smaller scope of functionality. At the beginning, high-level requirements are listed, without details, and most importantly, they are organized in such a way as to determine which requirements are critical for achieving the project's primary objectives, i.e., constitute its MVP (more on this in the article "Should you be afraid of MVP?"). Subsequently, within the development of individual functionalities in subsequent Sprints, requirements are refined by the Product Owner (usually a client representative) and the development team. In this approach, the client is not guaranteed to implement 100% of the initial scope, but on the other hand, has greater flexibility in terms of introducing changes to requirements during project execution. Such changes often appear as a result of reacting to the dynamics of the market in which the client operates, but also as an improvement to the idea, during the gradual creation of the solution. When observing the creation of a product on an ongoing basis and having the opportunity to test how it works in reality, it is much easier to obtain quick feedback, which allows for product improvement. Of course, changes in scope in projects conducted using traditional methodologies are also possible, in accordance with defined processes for reporting, analyzing, and accepting changes. Larger changes may require a review of all written requirements and determining the impact of the change on them, making corrections to the analysis and schedule. It is generally accepted that projects conducted in an agile approach allow for easier, faster, and therefore cheaper, response to changes. One of my colleagues used a "nautical analogy" to compare the reaction to changes in both methodologies. The reaction to changes in Agile can be compared to the maneuverability of a motorboat when it sees an obstacle in its path, a few quick turns and it can continue on its course. In the case of traditional methodologies, introducing a change sometimes looks like trying to slow down and change the direction of a heavy ship when an iceberg appears in its path...
Despite the advantages of the Agile approach, clients sometimes find it difficult to work according to the principles of the most extreme agile approaches, especially if the supplier is an external company that needs to be contracted. Therefore, we often propose a hybrid approach that combines elements of both methodologies. Initially, we strive to understand the project's objectives and the external environment that influences its implementation. At this stage, we also discuss the client's vision for the product, analyze requirements together, and prioritize them. We divide the scope into phases/stages of implementation, starting with the most critical functionalities. We place a strong emphasis on dividing the project in such a way that it is possible to launch the product on the market earlier in an incomplete version, although the final decision on an early commercial launch always rests with the client and depends on their strategy. We strive to keep the initial analysis phase relatively short, rather sufficient to efficiently start the development process and estimate project costs. Since the development process is largely carried out according to the Agile approach, the analysis does not end at this point. In each Sprint, an analysis of the individual elements being implemented in that increment is conducted, and work is also done to prepare for the implementation of the scope planned for the next Sprint. We avoid creating extensive and detailed requirements documentation, but we often develop, in collaboration with the client, diagrams of business process, which will be implemented using the system being created. This allows us to better understand how it should work and find those difficult areas of unusual situations for which the system must be prepared, but which clients often forget to include in their specifications. This supports the search for optimal solutions and simplifications, facilitates communication, especially in the case of complex processes, and often allows us to better demonstrate how the software should work. An important stage is also visualizing the system's vision through mockups, as it makes it easier to identify potential difficulties that the end user may encounter and eliminate them at an earlier stage. It is not always necessary to create a full set of mockups at the beginning; often this task is also performed in stages.
The software development phase is now largely carried out in accordance with Agile principles in a significant part of software houses. Work is performed in shorter time intervals (Sprints), teams conduct Agile ceremonies such as daily stand-ups, retrospectives, and product reviews (demos), which improves work efficiency and supports the continuous development of both the product and the development process. Direct communication between the development team and the client representative (Product Owner), who is responsible for the product and its functionality, is crucial in the Agile approach. The availability of the Product Owner is crucial for the efficient operation of the development team, allowing for quick clarification of product details and its optimization. If the Product Owner on the client's side is unavailable or does not have sufficient authority to make quick decisions, it reduces the effectiveness of working in an Agile model. Therefore, if the client cannot provide such a person, the project must be reoriented towards more traditional methodologies, more detailed analysis, and writing down the specification of requirements earlier. An alternative is to delegate some of the decisions to the supplier, but for such an arrangement to work well, there must be a high degree of trust between the investor and the supplier. Client availability is also important from the perspective of project testing. Of course, in today's world, automated and unit testing are essential components of any IT project, but it is difficult to imagine successfully implementing a new system without performing functional tests. In the Agile approach, each phase of implementation includes testing, which allows for the rapid elimination of errors and avoiding their repetition in subsequent stages. Continuous testing and product reviews after each stage allow for obtaining feedback from the client and further improving the product. It is worth noting, however, that in the Agile approach, testing often constitutes a significant cost component. In the case of implementing complex projects and new functionalities, incurring these costs makes sense, as it helps to avoid many errors, the detection of which later could necessitate significant system redesign. On the other hand, if we are creating a less complex project or one based on functionality that we have already successfully built in similar projects, it is worth considering optimizing the amount of testing during implementation.
In conclusion, there is no single right method of project implementation that will work in every case. Each project has its own unique characteristics and circumstances that should be considered when determining the methodology to be used. Generally, it is recommended that innovative projects carried out in a changing environment be implemented using Agile methodologies. The traditional approach is better suited for projects with very well-defined requirements that must be implemented in accordance with strict regulations or laws, for which very detailed documentation is required. In reality, the IT world currently favours the use of Agile or various hybrid approaches. This is often due to the difficulties associated with contracting and signing agreements between the client and the supplier. The longer the cooperation and the more trust there is in this relationship, the easier it is to move towards a more Agile, less formalized approach. Many clients see the benefits of such an approach, but it is easy to understand a certain degree of caution at the beginning of cooperation with a new supplier. In the end, the best approach is the one that enables the successful implementation of the project.
Author: Alicja Polak
