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.
In-demand approach
The current market demand can be summarized as follows:
- Greater involvement of all stakeholders in the definition of digital-transformation projects.
- Starting production sooner.
- Developing more projects simultaneously.
- Improving the perceived and internal quality of development.
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.
User stories
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.
Methodologies
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:
- Lean:
- See the whole.
- Deliver as fast as possible.
- Decide as late as possible.
- Eliminate waste.
- Amplify learning.
- Empower the team.
- Build integrity in.
- Manifesto for Agile Software Development: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools (people work together: the execution team and the decision team make and validate decisions together).
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan (do what the customer wants and needs, not what was written in a contract that you discussed six months ago).
© IE Insights.
