Agile Methodologies: Transforming Organizations to Minimize Errors and Costs
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 and pry it open before you can introduce change.
Agile methodologies are well suited to problems that are mysteries, but not to problems that are puzzles. They are useful if you want to build something whose final solution is unknown, or if there is much uncertainty surrounding the technique. In software, for example, you can have an idea and design it, but you don’t know if you’re on the right track until you present it to the potential user.
What businesses want can be summarized as follows:
- Greater involvement of all stakeholders in the definition of digital-transformation projects.
- Starting production sooner.
- Doing more projects simultaneously.
- Improving the perceived and internal quality of development.
All sorts of environments 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. And of course, companies want to complete projects more quickly, in a simpler way, and at lower cost.
All sorts of environments 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.
The first order of business, therefore, is to learn a different way of defining projects and integrate past projects (modifications and corrections of existing systems) with future projects (those which anticipate where the market will be in a few years). To do this, you have to contextualize your customers and put yourself in their shoes: in other words, empathize with them. You must study the user and his needs. Wherever you find customer frustration, there is always an opportunity.
For example, when a 13-year-old boy gets home from school, he starts using WhatsApp and watching television while paying attention other activities as well. If you ask him to go pick up a loaf of bread, he might get annoyed. For a company, this sort of frustration could be an opportunity to begin a digital transformation. This could mean developing an app that allows users to order home-delivered bread from the nearest market. For the company that owns the market, however, this would mean installing more ovens, hiring deliverymen, applying for the appropriate licenses, etc. In other words, the app is just the beginning; business models will need to adapt to new patterns of customer behavior and existing companies will need to be restructured. In any case, remember to exercise caution. A seemingly small idea can quickly snowball. Limit the scope using the concept of minimum viable product: fail fast, fail cheap.
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 allow developers to imagine the project as if it were already built. The idea is to imagine how all parties would use the product and prioritize 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. But in agile methodologies, a simple definition allows you to start building the project and deliver it quickly, in accordance with the established hierarchy of priorities. The team must be competent (the process must be completed in two or three weeks). 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 finished product is delivered several months after the contract is drawn up. In the new agile model, you build what the business needs little by little. If, at any point, you find that you’re on the wrong track, you can correct your course. And if 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.
A company that uses a waterfall approach—in which everything is defined perfectly, analyzed, designed, and built impeccably—can do a project well and at the same cost as a company that uses an agile model, but with one important difference: the user gets involved at a very late stage. In an agile system, the user gets involved very early in the process. In the waterfall model, the developer delivers what he was hired to do months earlier; in the agile model, he delivers what the customer really needs right now.
With a waterfall project, the risk is absolute; you build the product and then deliver it. 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—forcing corrections to be made at the end, with stress and conflict—disappears.
To be able to undertake more projects simultaneously and do good work, you have to create high-performance teams. Search your organization for a team that craves change, has the right skills, and is eager to learn and study. Work with that team to develop a predictable work model—and then split it in two.
With a waterfall project, the risk is absolute; you build the product and then deliver it. 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 provides great value in adaptive projects—that is, environments where you cannot foresee what is going to happen the next day (for example, a hospital emergency room). In most cases, the team has to do both things at once; this mixed methodology is called Scrumban.
In the Scrum methodology, you start by defining the “product backlog.” Stories are prioritized by business value. 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—always the shortest time possible. Every day, the team conducts a quick review: team members report what they have done, what they plan to do, and what obstacles they have encountered. All team members are expected to post their progress on publicly displayed charts.
You also have to integrate quality; you don’t just trust that what you’ve done will ultimately work out. Verification mechanisms are in place throughout the process; you try to avoid generating waste by maintaining uninstalled work in progress.
Competition has changed. We must work differently than we did before. New principles, values, work dynamics, and spaces are needed.
These agile models make work more visible. Stories are broken down into tasks. You can see at a glance what’s finished and what’s not; supervision is simplified through trust. The result is a flatter organizational structure. The staff is no longer divided into teams that execute and teams that define: there is only one team. You might not need as many people as you did before, but you do need more skilled multitaskers who can do multiple things at once and provide valuable knowledge.
Lean + agile principles
In summary, agile methodologies can be a combination of lean principles and the agile manifesto:
- 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.
Leading Innovation with Soft Skills and Motivation
By Balvinder Singh Powar. Creativity, the capacity to think differently, and soft skills to complement technical abilities.
11 / 05 / 2017
Diversity in Organizations: Different People, Rowing Together
By Celia de Anca. Diversity, if managed properly, nourishes organizations with individual differences that come together...
09 / 05 / 2017