Agile methodology in a mature organization such as Bank

The article is based on real experience of transformation projects in which I participated. As a point of reference for further discussion, I have chosen the report of Deloitte Digital entitled:

"Is it easy to be agile? Agile transformation in a big organization".

It organizes several topics connected with transition to project methodology in Agile model.

In the article I will try to pay attention to the vital elements of transformation that are key to its proper implementation, and I would like to discuss two elements related to transformation:

The competences of teams
The question of continuous delivery and continuous deployment

Agile Manifesto

At first, I would like to remind the basic assumptions of Agile manifesto:

Individuals and interactions over processes and tools
Customer collaboration over contract negotiation
Working software over comprehensive documentation
Responding to change over following a plan

The above assumptions are interpreted as fast delivery of efficient software to production and simultaneously taking care of creating comfortable work environment for the team, mainly to ensure its effective performance.

To begin with, I would like to quote a very important sentence from the above mentioned Deloitte report. Deloitte Digital report proposes the following thesis:

Agile philosophy assumes that teams are self-organising and cross-functional. In practice it means that teams decide independently about the best way to do their work and their members have all expertise and skills needed to finish particular iterations. Delegating such big resposibility to teams of developers has a very positive influence on the employees’ motivation, who, being resposible for creating the product, show greater willingness to everyday work.
(page 6 of the above mentioned report).

Competences of a team

The key to effective implementation of a project in this model is competence.
Let us have a closer look at this issue. We take into consideration a situation in which we change the model of running projects in an existing, mature organization. Such an organization has got IT infrastructure, in the sense of environments, applications and service processes.

What is more important in the area of competence of an Agile team? Experience in participating in this kind of project? Knowledge about the organization?

My experience shows that the knowledge about the organization is more significant, and by this I understand:

the knowledge about the processes of leading IT projects,
the knowledge about business internal processes and software architecture as well as component deployment,
the knowledge about the functionality of the IT systems which are going to be changed,
the knowledge about the people who are important from the deployment point of view into production

If a team does not work in an isolated environment (and this is usually the case), they have to understand how their activity influences the rest of the organization and how the activity of the organization may influence their own activity.

In addition to the competences related to the technology in which the task is carried out (i.e. knowledge of a given programming language, tools and technologies used in terms of frameworks, applications), teams must understand how the organization works and how to make their activities effective in interacting with the organization.

Service orchestration in complex environment

In mature organizations, IT architecture is based on a service model based on the enterprise service bus (ESB). Functionalities are made available not by large, monolithic applications, but are scattered into many modules that provide services that implement individual elements of a given functionality. The implementation of new functionalities assumes either the use of existing or the implementation of new services and their proper arrangement in the process.

Let's look at the typical implementation of new functionality in a service-based architecture.

The team has to prepare a screen with credit card details in a mobile application.
Let's assume that one application screen is one service. At the beginning we would like to display the available balance and daily limit. To download these two information, you need to call two services on your system: A and B. To meet this requirement (1 application screen = 1 service), we need to create a new service that orchestrates the other two. But it turns out that there is already a service in the system that collects the account balance, monthly limit and the last 10 operations on the history, only this service is more burdensome for the system than the service that the team planned to create. It is therefore necessary to decide whether to use the existing one or implement a new one.

The entire above process requires detailed knowledge of the system and services of domain systems. The necessary knowledge, however, results not from documentation, which often omits important elements, but from practice and experience. Documentation often does not indicate which service is efficient and which is not.

The criterion of success, regardless of the methodology, is therefore expert knowledge about IT systems, functional nuances or the way they are currently working. Agile methodology can help as long as people who have information about the current operation of the system are included in the communication regarding the functionality created.

Do not ignore what is happening around you.

Apart from functional knowledge, it is also important to have knowledge about IT infrastructure. Orchestration on the intermediate layer between a mobile application and enterprise service bus (ESB) may require coordinating actions with other teams.

Continuous delivery

Even if we manage to agree and prepare the appropriate services and implement the required changes, we come to the point when we want to deploy our application on the test environment and then on the production environment.

Until now, the deployment process took a noticeable quantum of time, sometimes several days, sometimes weeks. It is very expensive. For what reasons? Production implementation requires detailed analysis:

does the software provided work properly?
what exactly is being deployed?
how the deployment of the new version influences the functionality which has already been implemented (regression tests)?

Establishing frequent deployments on a production environment forces the organization to find a solution on how to do it properly. The goal of implementing the Agile methodology is to shorten the service of the deployment process. In my experience, the methodology implies positive changes in this aspect.

Application stack need to be included in continuous delivery processes

If every two weeks we want to provide working software that is to be deployed for production in a large organization, we must first have a streamlined process of deploying and maintaining such software.

You should diagnose current processes and verify what changes they require.

In addition to verifying functionality, it is also necessary to check the application stack - versions of libraries, frameworks, operating systems used. IT infrastructure is always alive, new versions or updates appear very often, and their appearance forces verification before deployment to the production environment.

Therefore, close coordination is needed related to the simultaneous implementation of software that contains dozens of changes of various types.

Knowledge about the processes within the organization

The development project in the agile model should precede the project change of implementation and maintenance processes, because the current processes are not 100% prepared for a new approach. Such an issue must be addressed by people who know the organization well and have representation to change such processes.

Why is this so important?

Highly parameterized systems require knowledge of where and about what values parameters should be set, as well as knowledge of how to analyze its operation after these changes. Therefore, not only knowledge and experience in the field of implementation is required, but also technical knowledge about system environments.

To sum up, for a team to be effective, it should consist of 80% experienced employees of the organization, and 20% may consist of new people who do not know the organization, but know Agile processes.

Conclusion

Agile methodology is not difficult and does not require a complicated learning process. Competences related to understanding the issue to which the project relates and knowledge about the specificity of the organization are very important.
The biggest problem that I noticed during the transformation from the model in the PMI methodology to Agile is the difficulty in accepting the fact that we do not design and implement the final solution.