Let’s be Agile

Leider ist der Eintrag nur auf Amerikanisches Englisch und Europäisches Spanisch verfügbar. For the sake of viewer convenience, the content is shown below in this site default language. You may click one of the links to switch the site language to another available language.

In 1970 Alvin Toffler published Future Shock. In this book he highlighted the accelerated nature of scientific and technological progress and stated the hypothesis that under this kind of change, in a few decades, individuals and societies would simply be unable to handle the, continuously modifying, reality . This would eventually make our societies fall into a state of paralysis (shock) on which progress would suffer, even to stop abruptly.

The future is here. The pace of change in our days is of such magnitude that it is absolutely impossible to keep up to date in any area of ​​knowledge. It could only be possible by means of an unprecedented level of hyperspecialization.

However, we have not been paralyzed.

We have found techniques and developed tools that allow us, not only to handle the enormous complexity of the accumulated change, but to carry on creating change and continuously accelerating it.

Agile Methodologies are one of these tools. The agile methodologies born in the universe of software development, but they have been quickly adopted -without excessive adaptations- to different types of projects in very diverse professional areas, including business management itself.

What does it mean to be Agile?

Traditional development methods began to be questioned during the last decade of the twentieth century. Until then the key was to plan and document in an extensive and detailed way all the work to be done, then go to execute what was planned taking care fundamentally in managing any deviations that may arise. However, this way of working did not allow the project team to adapt to changes that could arise during the execution of the plan. When the project came to an end, in the best case it no longer fit all the needs of the users, at worst it was simply unusable. As bigger the project, bigger the deviations.

From that concern the software industry start to adopt working methods which put the emphasis on speed development, rapid adaptation to change and gradual learning about user needs. Methodologies such as Scrum (1995), eXtreme Programing (XP, 1999), Lean Software Development (2003), Kanban (2004), among others, were able to incorporate these capabilities, giving solution to the shortcomings of previous methodologies.

In February 2001 a group of specialists in software development created the name of Agile Methods to refer to this new way of working. They drafted the denominated Agile Manifesto in which establish four distinct values of such methodologies:

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
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In short, we need to be focused more on people and their needs than on the processes they develop to meet those needs. Become Agile.

Of course, understand -or even apply- those values is not enough to affirm you are using an agile methodology in your projects. It is common to find professional project management that claim to use a given, Scrum or XP, for instance, when in fact they are not doing so.

Agile as approach to project execution

When we start using a new approach to project execution with an agile methodology where are encouraged to adapt the methodology in order to fit our particular needs, abilities, culture and project characteristics. Led by this recommendation we sometimes modify or suppress fundamental elements of the chosen methodology, obtaining results that are not attractive or even counterproductive. Doing so, we are not obtaining a real experience and creating a wrong perception about an Agile approach, putting in risk a successful Agile adoption.

Freedom is not the same as chaos. Agile methodologies are highly customizable, but to modify them it is mandatory a deep knowledge of the chosen method and some degree of exposure working with they unmodified flavor.

Finally, become an Agile is much more than adopt a specific methodology or toolkit. By the use of an Agile methodology organizations gradually change its gravity center from processes and control to people and their needs … from the means to the goals. Having an open mind is an is essential in order to make that change, and take advantage of it.

Schreiben Sie einen Kommentar