Agile Development in Large Companies

Mario Magnanelli, Former CIO, Six Payment Services

Mario Magnanelli, Former CIO, Six Payment Services

Have you come across your IT department lately? Have you heard the IT guys telling, that they are now developing their own applications in an agile way? But at the same time, you hear your business guys demanding delivery in time, budget and scope? Well, this is not strange, it is rather a fact in larger companies, which have been existing for years now and have not just recently started as a new tech company from scratch. Managing business critical applications that exist for years— whether described as legacy or not—requires strict processes and discipline from all involved parties. And therefore, the request from the business guys is not new. It is good practice for years now, and they have good reasons to demand so also in the future.

On the other hand, we know that big applications usually have grown over time, they are well embedded in the whole company’s application architecture, and there are many dependencies on other self-developed applications or other bought software. Everything is connected, and therefore so called simple changes can lead to unexpected larger projects, with hidden dependencies and difficulties to meet more than just one of the three major goals scope, time and budget.

At the same time, IT has learned from the problems and risks coming up with the good old practices from waterfall project planning. Mostly, in such a big company, the IT guys start to bring in new ideas and methodologies, also known as agile development. Whether it is Scrum or Kanban or others, the movement comes from small IT teams, and as they start to exploit the possibilities, they bring in new roles (e.g. the scrum master) and the directly involved people start to get motivated. This movement may come from IT managers as well as from engineers, and is a good example of the will to realize continuous improvement along the processes and methodologies.

However, soon the problems of a transformation start to get transparent, when these teams ask for the role of a product owner, who should be from the business and work closely together with the IT guys.

Learning new things not only includes new products or technologies, but also new methodologies and best practices.

That is the point where usually the business guys start to feel uncomfortable, because they do not understand the approach, do not see the benefit, and maybe they even fear that the nerdy IT guys could take over business and tell them what to do and how to work? No way! At this point, everyone realizes: It is a change. A real transformation. And not in IT alone, in the whole company.

In theory as well as in a few real-life examples, the best chances to implement agile methodologies in such a company, is to have a CEO, who believes in this and demands the whole company to do such a change. This power of course helps also for other major transitions, but at most when it comes to changes in the behavior of people. We all know, agile development is very critical, as it relies on a different way of understanding and living the culture in a big company. However, there are only few such real-life examples. Be it, because of only a few CEOs really having a flair for understanding their IT department and the business units alike, or rather because only a few CEOs want to take such a risk. And transformation is always a risk.

Learning new things not only includes new products or technologies, but also new methodologies and best practices

So what should the CIO do in such a situation? Experience shows, the CIO is the main mediator in such a case. On the one hand, he is the one to encourage his IT department to do such steps, to gain experience with it, and find out how the methodology can best help the employees to improve their way of working and hence their output. This is important, because in every company the best process how this should be built up, looks different. With this, the IT department gains knowledge about what works, and what not.

On the other hand, the CIO is also the most important salesman of the new target process. He must visit his peers on C-level, and convince them to support the process or maybe even sponsor a pilot project to gain real experience throughout the whole product value chain. Thanks to this, he is able to understand the fears of the rest of the company and becomes able to bring in valuable feedback towards his teams. And on the other side, he is able to learn how to address these fears with proposals or solutions.

Finally, not to forget, the CIO must stay on top of his role. It is always important to learn about such new “things”. This explicitly not only includes new products or technologies, but also new methodologies and best practices. The CIO should bring over coaches to accelerate the progress of the learning curve. There are always more experienced people around to support the teams. And additionally, this improves the credibility of your whole IT department.

The conclusion is that as a CIO, you should see proposals for change coming from the grass-roots level always as a chance. Let yourself be convinced of the good ideas, let them grow, and gain experience with it. On the other hand, do not let your team be stopped by other departments. No matter if it is because they don’t understand it or just do not like it. But be prepared to do intensive stakeholder management with peers and other departments. This is as important as the change itself. The transparency, which you are displaying at this whole journey, will help you succeed later. And most important: You as the CIO are in the driver seat.