Agile Methods: how to survive the anxiety for results?

Confusing agility with haste is a risk for newcomers to agile projects and teams
By: Roger pascoal, from the Sensorama Design team

We can agree: you can no longer say that agile methods are a novelty. It is easy to find, even on a quick ride on Medium or Linkedin, who is now involved in some kind of work with “kanbans”, “sprints”, “squads”, etc. And not a few people.

For some time now, these methods are no longer restricted to startups and software and information technology teams. And, with the Covid 19 pandemic and the acceleration of digital transformation, agility has established itself as a new standard and has further increased its presence in companies.

Remote work encouraged adherence to these work models. They make it easier to manage activities and goals, even in situations where teams need to work remotely. In traditional, departmental and highly hierarchical work structures, managing activities and goals can be very difficult when people are not close.

Will haste kill agility?

Despite its success, the recent history of agile methods cannot be told without a few tense moments.

Newly converted teams face difficulties that have led skeptics to say that these methods are just a “fad”. And, trendy or not, it has to be admitted that they are not the ultimate solution to all our problems.

Companies tend to accelerate projects to remain competitive, but the rush for results and the difficulties of adapting to new ways of working can create difficulties for teams.

Thinking that agile methods accelerate projects often creates deadline pressures that can generate more anxiety than results.

The argument that it saves time is very common and helps to publicize agility in companies. But, if it works for this purpose, the idea also creates a barrier: it’s hard to explain that the time we finish a project is not the only metric to evaluate its results.

Teams are agile, products are… products

Given this, and first of all, let’s say that being agile is not the same as being faster.

Even Usain Bolt — when he was already a world record holder in sprint events — was accused of not being agile. That’s because he wasn’t very efficient at race starts.

The first “agile methods” were not intended to speed up work or even increase productivity.

In the years when companies began to gain prominence, globalization was increasing competition in various sectors of the economy and the main concern was with the need to adapt production to meet new markets in different countries.

It was the 1970s, and “Kanban” — one of the grandfathers of agile methods — helped Toyota workers adjust the automobile production line whenever they needed to change products to be delivered.

The number of cars produced per day or week was very important, but it was not the only metric of success for the workers’ teams.

Simplicity was the method’s strong point: work management was done with clear objectives and goals, using paper cards that were pasted on the factory walls.

Short cycles and fast deliveries

In the following years, when technology companies faced similar dilemmas, software development teams found it difficult to adapt their products to different markets, countries and cultures.

As software became increasingly complex, with new features and a greater number of lines of code, traditional development methods became the target of criticism. Traditional methods organize work in cascades and can have long planning steps.

Although there was a lot of planning, it was not possible to foresee all the difficulties that would be faced by the project teams. And without agility and flexibility, teams could not meet the demand of projects with agility and flexibility. So they couldn’t avoid constant delays in deliveries.

The teams needed to be more agile, that is, they had to be able to change whenever necessary. In addition, they had to deliver products that really met the demands of users.

Agility met this type of need as it presented new ways of organizing projects, with shorter, faster and more accurate delivery cycles.

Learn to evolve

Waterfall methods prioritize the control and predictability of deliveries. For them to work well, teams need to have as much information about the context of the project as possible from the beginning.

What agilists understood a few years ago is that the ability of teams to adapt is essential to minimize the risks that characterize high uncertainty scenarios.

Agile teams are more adaptable because they can learn and evolve during the project.

For this, in addition to operating in shorter delivery cycles, these teams also gain agility when they are multidisciplinary. Blending skills helps build teams capable of learning more efficiently. The fine synchrony between areas related to innovation, development and management, favors the business strategy.

In addition to all this, if the intention is to learn from the process, it makes no sense to keep research and design professionals in isolated departments and not even separated by stages of project schedules.

Thus, today it is also common to find research and design professionals involved in different areas of companies. They help these areas at a time of transformation, when business digitization can no longer be postponed.

Be efficient to be competitive

By integrating learning skills and creativity into projects, agile methods embed the ability in teams to act in line with the expectations of stakeholders as well as users.

There it is possible to generate solutions and products that both meet business goals and are suited to the real needs of customers. This is a competitive differentiator: it makes the company capable of working on strategy and technology simultaneously to deliver products that are always updated to those who need them.