When IT specialists signed the Agile Manifesto back in 2001, they aimed at developing better software and at reaching this goal much faster. Since then, many companies have introduced agile methods – both in IT and in other fields. But not everybody is enthusiastic about that, as agile methods do not make teams more productive at the push of a button. In our practice, we encounter the following four problems again and again:

1. The wrong method

Scrum is the best known agile method, but it doesn’t fit every task. It unfolds its greatest potential in IT or product development. Product features can be very well defined as short-term intermediate goals. In The situation is different, for example, in project management: sprints are not so easy to define here. As an alternative, an agile method derived from Lean Management may be viable: Kanban. It can also be combined with a classic waterfall method.

2. Inflexible systems, rigid structures

Not every IT system supports agile methods. Therefore, many companies have to introduce new tools first. At the same time, IT is faced with breaking down familiar structures: Every project team should have end-to-end responsibility for a product and the associated systems in order to avoid interfaces to other areas. There is no blueprint for an agile IT organization that any company can apply. For example, some companies work with a matrix organization consisting of so-called Chapters and Guilds. Each team has an interdisciplinary structure and is assigned to a single IT product (Chapter). For this purpose, the employees take over the entire system and database administration, the ongoing development and associated tests. IT specialists who share the same roles belong to a Guild across Chapters, for example the developer Guild, which is also given disciplinary responsibility. It can be difficult if a company does not separate Guilds properly: Usually, a Chapter should not be charged with any further assignments; neither should any specialist work in several Chapters.

3. Growing pains

Most companies will test agility in a smaller IT team. This usually involves pilot or prototype projects, which are generally very innovative. If this turns out well, the principle will be scaled to other areas. Problems will arise, for example, when resources are lacking, for example when there are not enough testers available. Maybe the company underestimated the price of agility and will have to make additional investments.

4. IT colleagues as outsiders

A difficult, unfortunately quite frequent scenario: IT has gone agile but the rest of the organization is not prepared for that. Internal customers in the business units also need to understand agile methods, value and support them. In the best case, agility is part of the corporate culture, regardless of the extent to which areas outside IT apply the method in everyday life. In practical terms, this means that not only IT employees receive training in agile principles; their internal customers will also be prepared.

These four challenges have one thing in common: there is no single, universal solution to them. In the best case, every company finds its own way by questioning doctrines and adapting their key elements: Should the entire organization become agile or only those areas that deal with IT systems? Does every IT team use agile methods – or does it make more sense to stick to the waterfall method in certain cases? Does an IT system really require its own Chapter or could a team support several systems or even products? The future of agility is flexible: Teams will develop individual approaches that incorporate elements of Scrum, DevOps, Kanban or other methods.