Agility originated in software development and means being able to react quickly and flexibly to changing customer requirements and market conditions. Agility was therefore first practiced in software development teams, e.g. in the form of Scrum.
A Scrum team in software development has all the knowledge and skills to work together to create the product. It is autonomous and self-organized. That sounds simple. But I remember well one of my first coaching mandates for a Scrum team in an insurance company. The team consisted of good developers, testers and designers working on a new consulting software. Everything worked well, a really cool solution with modern user interfaces was built, but the development never went live. What was missing? You never had direct contact with the real users and therefore you developed agile in a way that missed the point.
Business Agility now wants to focus the company on the customer.
The customer is the focus of the organization. That sounds good for everyone at first, but practice shows that everyone – from their own perspective – understands it differently.
Last year at a conference, we spoke with a group of experienced coaches about urgent future developments of agility and Business Agility quickly became hot shit. But when we went a bit deeper and tried to define what it was all about, we got 7 different opinions from 5 participants.
This is really annoying, because no constructive dialogue can be established if the same thing is not talked about. The result is mutual shaking of heads and turning of eyes instead of enthusiasm from common understanding and learning.
For our agile development team, business agility first of all means involving people from the real business in the development. They provide direct and quick feedback on the results from the sprints, enabling the development team to learn quickly and effectively about the real customer needs. Methodically, the team tries to travel through a customer journey with their business colleagues to really understand their needs.
Now it is mostly the case that complex products are developed in large organizations. This means that several agile teams work together in an Agile Release Train, which is responsible for the entire product.
In our insurance company, many teams work in one train on an insurance distribution system. However, this system should not be considered individually, but is only one system for the entire insurance business. The trick is to involve the representatives from the business directly and significantly in the development trainings – to create real cross-functional teams, even in such complex organizations. Especially in development organizations that have tried over the last 20 years to build a clearly separated client-contractor organization in which a pseudo-market is played, but in reality only a game of black and white ritualized in committees determines the course of events, it is a real cultural breakthrough to fill this gulf between IT and business with the mother soil of trust on which real cooperation can then grow.
Incidentally, NOKIA, too, has risen to this challenge in the shortest possible time from the industry leader to disaster, despite a great agile development organization.
But things get really exciting when we not only integrate business know-how into our daily work, but also when we take into account the fact that the software generally does not develop any direct value in our insurance company, but rather changes to the insurance processes. In practice, we see all too often that the software is rolled out as a result of the work of our development teams in so-called departmental projects: new organizational manuals are written, often more than a thousand insurance clerks are trained for weeks on the new processes, etc. The speed of agile software development fizzles out in this lengthy, classically planned and executed process.
Business agility at this level means: The solution is the insurance process that develops value together with the necessary software changes. And this solution is jointly developed in our agile teams – and delivered according to DevOps rules. Business process engineers plan and develop their work in sprints and program increments together and in the same rhythm – and in doing so, they jointly consider from the outset in the form of minimum viable products in which steps the software should be rolled out in the organization.
This is the first time that the agile approach to development has had an impact on actual business activities.
This means that we are really beginning to continuously improve the entire development process and its impact on the business and no longer view the software in isolation.
But we still haven’t managed to make the many insurance clerks, who are directly or indirectly involved with the customer, agile. Only the Development Value Stream, product development, has been affected so far. But the actual value creation takes place in the Operational Value Stream, the real customer journey.
We are tackling this task if the overall insurance – i.e. the operations (“run the system”) – not only the development (“change the system”) is to be organized in an agile manner.
To achieve this, we must also create agile teams in the company. These service teams then work just as creatively and self-organized as development teams. In daily business, they react flexibly to the “cases” that arise in varying quantities and complexity, usually by implementing complex Kanban systems that many are familiar with from the production industry. In doing so, however, they also constantly reorganize their own process. For example, they also use design thinking to really understand their customers. In our insurance company, for example, customers are then advised individually and quickly, depending on their requirements, with a product mix tailored to them. This is because a cross-functional team of consultants can quickly and easily determine the optimal services for the customer – without lengthy communication across silos. At the same time, the agile underlying IT systems allow them to exercise the same flexibility, as they can be adapted to different product mixes, for example. Business agility in this comprehensive form is still the exception in large companies today.
When our insurance company has made this step towards business agility, the effect often still fizzles out because it does not manage to work on the really most effective process and product changes. Often – as has always been the case – the things are done for which one has free capacities at the moment or which one has actually promised to do with influential board members for a long time. Prioritization is a carefully ritualized power struggle in which the word “strategic” is often used, but in which there is usually no joint alignment of the various business units on a common strategy, but rather local optimization is negotiated with often lazy compromises.
Lean Portfolio Management now aligns all development initiatives with the common corporate strategy and thus bundles all forces in the same direction.
At the same time, it means a real system change, because decisions are made decentrally, where the people who know the most about it are. Everyone knows where things are going and can decide for themselves how best to achieve the common goal.
In this way, we manage the people across companies and generate alignment across the entire portfolio.
The overall management of development has become agile, the effect on the customer is usually immense.
About the Authors
Dr. Thorsten Janning (born 1962) is a graduate mathematician and has worked in the IT industry since 1990. His professional career as an architect and project manager led him through consulting and user companies as well as a university professorship into the consulting and training business. As co-founder (in 2002) he is a partner and was a member of the board of KEGON AG until the end of 2017. His professional activities focus on the development of lean and agile organizations for IT service providers and software houses as well as the implementation of complex architectures in application products. Thorsten is one of the first European SAFe® Program Consultant Trainers (SPCT4) and the first German SAFe® Fellow and thus one of the most experienced and distinguished agile consultants in Europe.
Mrs. Caroline Schmidt completed her studies in Finance in Vallendar at the WHU Otto Beisheim School of Management and is now pursuing her PhD at the chair of Business Information Systems. She combines academic research with practical experience in her role as a consultant with a special focus on lean portfolio management and system design. Being passionate about what she does, she loves to pass on her knowledge in trainings and workshops. Various experiences abroad, e.g. in London, Milan and Tunis as well as her apprenticeship as a certified mediator help her perform and operate in different cultural contexts and difficult situations. Besides that, she is a passionate yoga teacher.