Read how large organizations can also benefit from the trend topic of agility. […]
In many smaller companies, IT consultants, departments and teams, the topic of “agility” is already firmly established. Especially in larger companies, from medium-sized companies to global corporations, the management still struggles with the implementation of agile methods. The more employees are involved and the stronger the interactions with other departments, the more complex the change to an agile culture becomes. The results of the agile teams also affect all other departments – because, for example, research and development, personnel or marketing depend on the availability of an IT solution. CIOs as well as the higher management level must open up the “tunnel vision” across the and adapt to a cultural change throughout the company.
But everything from the beginning: Fifteen years ago, hardly anyone would have expected how the world of work would change in the IT industry. While the pre-defined software architecture at the time was still like a “Bible” that developers had to adhere to strictly, today it is created in an agile process. This makes it possible to develop a product that really meets the needs of users in the here and now. Because otherwise it can happen that after a long specification and determination a product is created, which was still wanted and needed yesterday; but which is already outdated at the completion.
Agile methods such as Scrum and Kanban provide software developers with a model that allows them to review, evaluate and adjust their progress in high granularity. This is by no means mere deregulation or “planned chaos”.
The agile methods differ from certain approaches, but have the following points in common: They are “lean” and “agile”; require a “pull system” in which each team member picks up new tasks independently; limit the number of tasks currently to be processed; focus on delivering release-capable software increments in predefined work steps (“sprints”); are based on self-organized teams with flat hierarchies; evaluate the release plan based on the evaluation of empirical the average team speed. Thus, the agile methods are a highly structured, but at the same time elastic approach.
Agility is a mere necessity in times of rapid development of IT systems. According to Moore’s law, not only the performance of the circuits is constantly increasing, but also the requirements for the software frameworks. In addition, new providers of disruptive software-as-a-Service (SaaS) are appearing more and more recently. This means that a software solution that had to be developed with great effort yesterday can be purchased today at a fraction of the cost.
It must therefore always be questioned anew what kind of functionality is to be developed, in which interface it is to be embedded and which requirements are to be met by it. If you want to be prepared for the future paradigm shifts in the IT industry and fully exploit their potential, you can’t really avoid agile methods.
The advantages of this approach are obvious: The fact that a project fails is enormously reduced. Regular acceptance and testing, as prescribed by the agile methods, ensure a high degree of transparency in the course of the project. As a result, decision-makers are always aware of whether they should modify the requirements for the project and add or subtract resources. In particular, the time-to-market of the project is reduced, because users can already fall back on completed partial functions during development. The finished product is stable, tested many times and meets the current requirements resulting from the IT landscape and the wishes of the users.
The agile methods of the first such as Scrum and Kanban were mainly aimed at implementation in manageable teams. The Scrum method only knows three fixed roles for the participants (Product Owner, Scrum Master, Team Member). While it can still be seen that such relatively autonomous structures can work well at this basic level, the question of practicality arises at the level of several hundred or even thousand employees. In practice, some superordinate models have already proven themselves for this purpose, which will be briefly presented below.
- Nexus Framework: The Nexus Framework is a kind of” exoskeleton ” that mediates between three to nine Scrum teams. There is only one common backlog, on the basis of which an integrated increment is created. To keep dependencies as small as possible, the Nexus backlog is split into as small parts as possible and those that create the largest dependency are prioritized.
- Large Scale Scrum (LeSS): The less approach maps the Scrum method to larger organizations by simply “enlarging” the development team. Entire teams take on the role that the individual employee previously had. Basically, there is only one Product Owner, no matter how big the team is. In sprint planning, all teams are present, possibly only deputies. Here, the individual tasks are distributed among the teams according to the order of the backlog. In very large projects, the strong emphasis on a product owner can be avoided by dividing the functionality of the product into different areas with their own product owner. Thus, a middle layer can be added.
- Scaled Agile Framework (SAFe): This model distinguishes the three levels portfolio, program and team. At the portfolio level, all strategic topics such as investment and are located. At the middle program level, the “Agile Release Train” ensures a close interlinking of strategic and operational levels, for example when a product or one of its components is ready for delivery. At the team level, the known methods finally find their expression.
At this point, only a rough overview of the variety of individual methods can be given. Other offerings include the Agile Scaling Cycle or the Spotify method. Depending on the use case, it is necessary to decide which framework best suits the requirements of the company. SAFe, for example, starts at a very high level and is required when software and IT development actually plays a strategic role for the company. Depending on your organizational needs and culture, you need to set up the frameworks that best suit you.
In principle, the rule of thumb applies: as much freedom as possible, as few rules as necessary. In most cases, however, the ideal case cannot be implemented due to external factors, which is why models with more complex sets of rules also have their justification. Scaling also takes place on the horizontal (more teams, employees, etc.) as well as vertical level (more tasks, responsibility, deepening in the value chain, etc.). External consultants can be very helpful in this topic to clarify the need and find and implement the particular model.
If companies want to shape a change towards comprehensive agility, they are already facing a challenge at this level. Because agility is not just another” tool “that is simply bought in and plugged in as a”plug & play” approach, but requires a fundamental cultural change. Agile change presupposes that supervisors hand over responsibility to their employees and that employees in turn are ready to take on responsibility. Former lone fighters become team players who put their self-written code at the disposal and free disposal of the team.
The agile transformation takes place between two opposing poles: strict logic on the one hand and creativity on the other. Neither the one nor the other principle may completely dominate, which requires constant consideration on both sides. The path to an agile organization is therefore agile itself again: How the organization looks and works in the end, develops in the process and is only determined at the end of development. Those who consistently follow this path will also be able to enjoy the advantages of agile methods in the end: The functionalities of the IT products always meet current needs.
* Philipp Hellwig is a Senior Consultant at PENTASYS AG. He is certified as Scrum Master, Product Owner and Agile Leader. In this role, Philipp Hellwig supports companies in successfully implementing the agile transformation. Further stages of his almost twenty-year career include work as a developer and marketing specialist at the Boston Consulting Group, among others.