- Steinbeis Transfermagazine - https://transfermagazin.steinbeis.de -

So if it’s Agile, That’ll Do?!

Why do a growing number of companies want to be agile? The Steinbeis expert Prof. Dr. Kai Renz digs deeper

Agile – one of those modern buzzwords. Lots of firms want to finally “get agile” – and ideally they would “go agile” with all their projects, in all areas of the organization. Dissolving inflexible and rigid company process infrastructures would be a great way to boost customer benefit and deliver superior quality. And, it should make everything more fun for everyone. But is agility really so advantageous? And if it is, what’s the best way to go agile? What’s the underlying motivation for wanting to be agile, and can agility be simply ordered on prescription? These were the questions looked at by Dr. Kai Renz, Professor for software engineering at Darmstadt University of Applied Sciences and director of Agile Softwareengineering, the Steinbeis Transfer Center.

A firm is agile if everything it does revolves around the “agile manifesto”. The Agile manifesto was originally a reaction to the so-called “software crisis” but the items it contains work in all areas where a group has to produce something for another group. The manifesto covers four key points:

  1. Individuals and interaction over processes and tools.
  2. Functioning solutions over comprehensive documentation.
  3. Trust and collaboration over contract negotiation.
  4. Permanently responding to change over adhering strictly to plans.

But is agility really so amazingly useful? Everyone is familiar with projects taking too long, coming in above budget, and getting out of control. And anyone who has had to implement or work on a medium-sized or large (software) projects knows all too well that estimating the exact costs and delivery date is like a Gordian knot. There are a number of sometimes complex reasons why big projects are so difficult, but usually there’s one big reason: When you start a project, no-one can say for sure what’s actually needed at the end.

I’ve often seen requirements that were considered extremely important when the project kicked off turning out to be of zero use in the end. And often the opposite was true: Functions that were really important at the end were not even been spotted at the beginning of the project. Despite this, many projects are planned as if people could more or less say at the beginning what should come out at the other end. For example, many fixed-budget projects are carried out based on a requirement specifications that are fixed at the beginning – but as the project moves forward, changing requirements are consciously brushed away. Often, the fundamental belief is that change is expensive. It seems easier to plan a project if changes are not permitted during the implementation.

With agile methods like SCRUM or KANBAN, software-engineers will try to work out what the project objectives are at the beginning aswell. But the only factors that are specifically addressed are the ones that can be defined and are important at that given moment in time. The aim is to quickly – very quickly – deliver results that are useful to the customer. The fundamental attitude with agile projects is that change is good.

From my personal experience as a software developer and a team leader on software projects, I’ve seen that agile methods do indeed deliver usefull results that can be realized more quickly for the customers. However, introducing agile methods within a company involves a number of obstacles. Responsibilities change, as do the predictability of results, so it is essential that:

Management plays an important role when adopting agile methods. Previously it was responsible for all aspects relating to “what” and “how,” whereas in an agile environment the task of management concentrates on “why.” Management no longer decides how things are done; it explains why a project is important. A product owner then has the task of working out the specific user stories based on this “why” and setting priorities to be given to the team. The team decides by itself in short intervals which of the current requirements should be implemented. This way, management has a significantly more strategic focus. Managers who communicate boundary changes earlier and more accurately are a valuable asset for the people working on a project and are appreciated as such. In return, managers learn to stand back and stop deciding directly regarding “what” and “how.” As time goes by, there is growing trust that the team deliver results on its own and works professionally.

What can a company do to get people to think differently and in agile terms? In keeping with the agile approach itself, it always makes sense to underpin any changes with comprehensive communication. But it’s important that this is not just one-way communication. It’s not about supposing what would happen if agile methods were introduced. It’s about engaging in genuine dialog. It doesn’t work if the uppermost echelon of management announces at a January kick-off meeting that the company will now use agile methods for everything. You can’t prescribe agility. So it’s crucial that agility is introduced step by step, ideally based on specific projects. It’s also quite possible that not everyone is ready for an agile working environment. What sometimes happens is that team structures change because the team members redefine themselves or focus on different things. But if agile methods do work in projects and for the company overall, people will benefit from fulfilling work, useful results and an overall quality-increase.