/*Blog module replace 'read more' text*/

Agility is not a goal, but a tool

MINDSPIRE BLOG

Follow MINDSPIRE on social!

Introduction: The agile transformation

It’s safe to say that alongside the rise of home working, one of the most significant trends for the 2020s is the agile transformation among large Hungarian enterprises. A growing number of actors with multinational background or with regional importance are working on to embed agile principles in their corporate culture in order to gain an advantage over their competitors. This is understandable, since agility holds the promise of all these:

  • delivering results faster,
  • more flexibility to adapt to a rapidly changing market environment and thus to evolving business needs,
  • achieving all this with less administration, while increasing transparency,
  • and creating a better working environment for employees as well by focusing on people and direct, personal communication.
Gergely Gyenes

Gergely Gyenes

Agile project management supervisor

Gergely has more than 20 years of experience in the field of retail loans.
He is equally experienced in planning business and IT processes, as well as in project management, test coordination and data analysis.
He is committed to teamwork, constantly supports and encourages his colleagues to achieve the best possible performance.
In the past four years, he worked as an agile product owner on several residential loan projects, and also participated in the agile transformation of organizations and projects.

 

Let’s examine what is required for all these!

  • First of all, a well thought-out, comprehensive methodological description is needed, since the agile manifesto itself “only” sets out directions and values. But how to achieve and integrate them into the daily life of an organization, is not.
  • Then a roadmap is required to transform the organization from its current strict hierarchical structure into an agile organization.
  • The principles and the agile methodology should be communicated to everyone, preferably with a version already adapted to the organization.
  • Finally, new collaborative workspaces have to be set up, bringing together business, IT, other direct support areas, and some supporting software (such as JIRA and Confluence).
Andras Linczmayer

András Linczmayer

Head of Project Management and PMO Services

András has more than 15 years of experience in the financial sector. He worked as a project manager in high-priority projects, managing large teams of internal and numerous external vendors, successfully implementing complex system architectures and greenfield applications.
While leading MINDSPIRE’S Project Management and PMO service lines, he continues to manage and support large-scale projects, getting involved in the details professionally.

To carry out these tasks, we will need experienced facilitators who are already familiar with the methodology and who can help the teams to translate the day-to-day work into actual operations, be their scrum masters, or agile coaches.
Our organization is now agile, as we are not writing business specifications, but formulating “user stories”, which we refine, score and split through “plannings” and “refinements”. We work in sprints, hold daily “stand-ups” and present the results in “demos”. And at the “retrospectives” we explore what went well and not so well during the last sprint, as this is the key to getting better and more efficient.

If we go into more detail, we will see that we still have some challenges to overcome.

IT architectural questions regarding agile operations

Over the past 20 years, actors in the Hungarian large enterprise sector (with a few exceptions) have accumulated a huge technological debt. As a result, many functions are served by robust, monolithic systems that can be developed internally only minimally or not at all. In most cases, IT architecture has evolved organically over the past decades, always in line with the then current trends and needs. In addition, it is not uncommon that very similar functions, such as reporting or client registration, are served by different systems in different areas.

Why is this relevant from the agility viewpoint? Imagine that we want to create an agile squad to develop and operate a business process. Let’s assume that this business process is served by an “out of the box” system that could perfectly perform this task on its own two decades ago. But today, as a consequence of organic evolution, it is no longer recognizable. Many of its non-core functionalities have been outsourced to other solutions with which it communicates through different interfaces. Thus, from the IT side, modifying a business process now requires a comprehensive knowledge of at least two or three programming languages and the same number of communication technologies. In addition, the need for expertise on the business side is at least as complex, as we will need product and process specialists, as well as legal and compliance experts.

Relationships between IT architecture and organizational frameworks in the agile model

One of the biggest virtues of agility is that each team is empowered to make independent decisions, to determine for itself how to implement a business need in the most efficient way with the tools and resources available to it. This is essential in order to be able to react quickly to the constantly changing environment.

In reality, setting up a squad capable of delivering E2E, independently often stretches the agile framework. In practice, the following two options are basically available:

  • We set up a squad which has competent resources for each component. This will create a team of 13-18 people, which is capable of investigating and correcting all errors that arise in the given process, and can also expand it with new elements, but due to its size it stretches the agile framework. As a result, the efficiency of agile ceremonies is significantly impaired and the flow of information between team members is also weakened. In time, perhaps some competencies can be merged and staffing can be reduced, but until then there will certainly be team members for whom the squad cannot provide a full-time role on a continuous basis, which will have a negative impact on engagement and the development of a so-called “ownership mindset”.
  • We set up a squad whose headcount corresponds to the agile framework, but there will be functions that the squad will not be able to develop and improve on its own. In this case, the team, as a unit responsible for product and process, will appear in the role of customer towards other agile squads, which results a dependency. For tasks involving certain competencies, this prevents the possibility of independent and continuous delivery, which also violates agile principles.

In practice, in addition to the above two solutions, many other “hybrid” setups have also emerged.

Such as, for example, when certain special resources are officially members of a squad, but in reality, they belong to a competence pool from which they are employed as drop-ins in a specific squad for one or two sprints or a quarter.

There is also a methodology where individual resources are shared between squads in a certain percentage, so that the given employee is forced to contribute to the life of several squads on a daily basis and to participate in ceremonies, which in the long-term causes tension both for the employee and for the squad.

We see that in most cases – thanks to the legacy architecture – the agilization of the entire organization is not even realized.

Several other specialized areas working in close cooperation with the areas involved in the agile transition perform their daily tasks in different rhythms, and a lot of internal and external supplier dependencies remain. This imposes continuous coordination, negotiation and additional planning tasks on the teams already operating in agile manner, increasing delivery risks, as they do not have an adequate influence on their external environment.

Organizational issues related to agile operation

The agile methodology basically thinks in terms of a flat matrix organization, as well as delegating operative decisions to the lowest possible level, where the actual work takes place. In this structure, there are basically two levels vertically:

  • The management level, who reports directly to the company leadership, and whose main tasks are the creation of a strategy in line with the company’s goals within the given area, the exercise of the employer’s rights, as well as the formation of the operational levels and their adaptation to the tasks.
  • The operational level, the Product Owner, who manages the individual squad. He is the one who defines the daily operations, determines the progress, breaks down the strategy and pours it into actual tasks for the team. Proceeding from sprint to sprint, he accepts the team’s performance and commitments, or makes comments regarding the implemented developments and the undertaken future deliveries, thus guiding the team in the direction of achieving the desired goal.

Usually horizontal, professional levels are also established in a supportive manner, the leader of which is primarily responsible for ensuring that the colleagues belonging to each competence represent the same quality and level of knowledge. Typically, they perform the selection, as well as the development of the professional standards according to which the employees belonging to the given competency perform their tasks.

It is no coincidence that agility as a methodology was born in the IT sector and became an effective tool primarily in startup companies that had no history of hierarchical organizational culture. For them, this was simply the foundation on which they built, this attitude and way of thinking determined their operation from the very beginning.

Agile project management post illustration

In the case of the so-called traditional large companies, it is not enough to approach the transition to agile operation from the work organization point of view.

In order for an organization to go through a successful agile transformation, it is necessary to review, and in some cases radically transform the IT architecture. In many cases, this is a painful, lengthy and expensive step, but if we choose the path of agility, it is inevitable.

Why is it worthwhile to start the agile transformation?

Based on experience, the implementation of the agile operating model and the agile transformation can present serious challenges to organizations, however, its advantages and the results achieved far outweigh the difficulties experienced during the transformation.

As the title says: agility is ony a tool, not the goal to be achieved. If we look at it this way and acknowledge that agile transformation requires a lot of time and sacrifice, both financially and organizationally, and if we only want to apply it where it really has a right to exist, then there is a chance that it will live up to the promises made by the agile manifesto. However, if we look at it as the organizational trend of the 2020s, a magic wand that will solve all previous corporate problems at once, then we will have a lot of disappointment and, despite the efforts, the result will be failure and organizational restructuring.

Despite the many difficulties, we must not forget that if a large corporate organization commits itself to agility, it can have many advantages in the short term, even if the organizational culture can only be changed with many years of systematic work. One of these indisputable advantages is the destruction of the invisible walls between business, as the customer side and IT, as the supplier side exist in the traditional organization. By eliminating these sides and placing the relevant actors in one team, in one physical space, we start a collaboration, a common thinking where the business side understands the limitations of the available IT architecture, and an IT developer the importance of business needs. In this way, they are able to jointly find compromises which can be implemented as quickly as possible within the available framework, and which satisfy business expectations as best as possible. In this way, they will not be parties on opposite sides with different interests, but colleagues sitting in the same boat, rowing in the same direction, and supporting each other.

And how to get started? We recommend exploring the areas and projects in the organization where the agile principles can be fully implemented, and lead the organization to agility step by step, in parallel with the IT architecture.

If you have any questions about the agile transformation, please contact the experts of MINDSPIRE Consulting!

Authors:

Gergely Gyenes and András Linczmayer

Please see MINDSPIRE’s related:

 

Project Management
Services

Project Management
Office

Agility is not a goal, but a tool
Project management contact form

Do you have a question or comment about this post?

Send us your message and our experts will contact you!

Project management office icon

Our latest Project Management Office References

Are you interested in our Banking PMO services?

You can find more information here:

Project management services icon

Our latest Project Management References

Are you interested in our Project Management Services for the Banking Industry?

You can find more information here:

Share This