Agile methodologies are now in demand, but they are not the solution to everything. There are various types of practices, and an organization’s maturity may dictate which approach is the most appropriate. Traditional and agile approaches will coexist for many years to come.
Organizations cannot change their work methods instantaneously; transformation is a years-long process that requires resources. You have to find a crack in the operations before you can introduce change.
Agile methodologies are well suited to problems in which the final solution is unknown or there is much uncertainty surrounding the technique. One example is software, where you don’t know if the product is viable until you present it to the potential user.
The current market demand can be summarized as follows:
What this means is that environments of every sort are ripe for a digital transformation—which is another way of saying organizational transformation. Nowadays, project leaders, directors, and middle managers aren’t there just to carry out orders, but to contribute ideas. Moreover, it is necessary to develop projects more quickly, in a simpler way, and at lower cost.
The first think you have to learn, therefore, is to define projects in a different way, integrating modifications and corrections of existing systems and anticipating where the market will be in a few years. To do this, you have to contextualize your customers and put yourself in their shoes, empathizing with them. You must study the user and his needs. Wherever you find customer frustration, there is always an opportunity.
Environments of every sort are ripe for a digital transformation—which is another way of saying organizational transformation. Nowadays, project leaders, directors, and middle managers aren’t there just to carry out orders, but to contribute ideas.
In order to do things quickly, you should do very little, but with great specificity and added value. In agile methodologies, projects are defined on the basis of “user stories,” which consist in imagining the project as if it were already built. This requires thinking about how all parties will use the product and prioritizing those requests hierarchically.
In the classic model, the user is not involved until the end of the process, so feedback is provided rather late in the game. Using agile methodologies, however, you can start building the project on the basis of a simple definition and deliver it quickly, in accordance with the established hierarchy of priorities. In the first cycles, there is a good chance that the needs of the business or project have been misunderstood or that the team is unfamiliar with the technology; this can lead to miscalculations, but they can be resolved quickly because they occur at a very early stage. If, during these short cycles, the product is presented to the user on a regular basis, it is possible to make adjustments so that the customer ends up getting what he really wants.
What is needed vs. what you are hired to do
In the traditional model, the delivery of the finished product tends to take place several months after the contract is drawn up. In the new agile model, however, since you build what the business needs little by little, you can correct anything that doesn’t work. If, instead, everything goes extremely well, you can go to market ahead of schedule because everything will have been tested by the end user multiple times. That’s the main value provided by agile methodologies.
With a company that uses a waterfall approach—in which everything is defined, analyzed, designed, and built impeccably—the cost could be the same as with a company that uses an agile model. The major difference, however, is that in the waterfall approach the user gets involved at a very late stage. In an agile system, the user starts participating very early in the process. The waterfall model produces what the developer was hired to do months earlier; the agile model produces what the customer really needs right now.
In other words, in a waterfall project the risk is absolute because first you build the product and then you deliver it, whereas in an agile project the risk is small because the product is validated constantly. Agile models are therefore much cheaper because the risk of failing to meet user expectations disappears.
In a waterfall project the risk is absolute because first you build the product and then you deliver it, whereas in an agile project the risk is small because the product is validated constantly.
The agile approach encompasses various methodologies. The Scrum model is good for defining predictive projects. The Kanban model, in contrast, provides great value in adaptive projects—that is, environments where you cannot foresee what is going to happen the next day. Most commonly, however, the team has to do both things at once, with a mixed methodology called Scrumban.
In the Scrum methodology, the first step is to define the “product backlog”—stories prioritized by business value. Then you start building in short cycles and present the product to the users at regular intervals for validation. Each cycle lasts two to three weeks. During that time, the team analyzes the results and any obstacles they have encountered. In this methodology, the entire process is publicly displayed on a series of charts.
In parallel, it is necessary to integrate quality rather than just trusting that everything will work at the end of the process. There are numerous verification mechanisms that can be used throughout the process, with the aim of avoiding the waste of maintaining uninstalled work in progress.
Agile models make work more visible. Projects are broken down into tasks, so you can see what’s finished and what isn’t, thereby simplifying supervision and strengthening trust. The result is a flatter organizational structure that eliminates the division between teams that execute and teams that define: instead, there is only one team. Fewer people may be required, but those who are involved need to be more skilled and capable of multitasking, thereby providing more value through their knowledge.
Lean + agile principles
In summary, agile methodologies can be a combination of lean principles and the agile manifesto:
© IE Insights.
If you found this article of interest, subscribe to our monthly newsletter and receive further updates directly to your inbox.