Director of IT Operations at Raiffeisenbank Hrvatska

I have been putting off this article for a long time. I went through dozens of drafts. Why? IT infrastructure and the term agile are not on the best terms. Infrastructure, in most organizations, is considered as keep-the-lights-on service. And in some way, that's true.

But to get there, the development of IT infrastructure services is needed. Infrastructure products are like any other product. Clients are not the end users of the organization, unless it is the core business of the organization, but there are still users. With all its requirements and pain points. IT infrastructure products are developed for them as well. And the the organization.

At the mention of agile in the context of IT infrastructure, colleagues will turn green. I believe I understand why. Maintaining an existing service, i.e. the run phase, is difficult to execute according to agile principles. At best, according to the Kanban methodology. But not as Scrum. There are just too many ceremonies just to enable day-to-day operational activities. However, during major changes and the introduction of a completely new service, it makes sense.

"The book The Culture Code states that one of the basic methods of building a healthy culture in an organization is defining the purpose - why the team does what it does"

This is not an attempt to introduce a full agile methodology into IT infrastructure processes. That would fail. This is an attempt to make all stakeholders aware that IT services are also - products. And that as such they go through the same life cycle as any other product. Products that solve users’ problems and contribute to the business goals of the organization.

What I want to achieve with this experiment:

● ownership - when a colleague is a Product Owner, I really believe that he is the owner of that product

● legacy - the sense of pride of building a product from scratch to full functionality and leaving behind something they can be proud of

● freedom - each team has full freedom to choose how to solve a given problem

● awareness – that IT services are products

● collaboration – between employees from different departments

● growth – every product initiative manager gets an opportunity to grow

TWO-WEEK STEERING

Every two weeks, the lead of the product initiative (product owner) has a 15-minute presentation with the business owner and stakeholders. The goal of steering is for everyone involved to be aware of the progress. The most important is that PO can express its obstacles and risks so that BO and stakeholders can remove the obstacles and help minimize risks. The presentation is minimized to only two slides:

● done in the previous period and the plan for the next period

● risks and impediments

The most important goal of the steering, for me personally, is to build a product owner through mentoring. Also, the goal of steering is to recognize on time that the product is not developing as expected. There are several options: change direction, pause or completely stop the initiative. It is not necessary that every initiative is successful. Fail Fast and Fail Cheap.

LANDING PAGE

The book The Culture Code states that one of the basic methods of building a healthy culture in an organization is defining the purpose - why the team does what it does. Defining a purpose is not an easy task, and it is even more difficult to continuously communicate it.

One of the terms that is engraved on my memory is stealth expectations. Stealth expectation is an effect that occurs when not enough information is communicated, so expectations remain hidden. If the expectations are not communicated, the result of the team's work will not be consistent.

The goal of the landing page of every initiative is to solve the above-mentioned problems. The problem of hidden expectations and lack of clear purpose. The landing page contains all the relevant information needed to solve the given problem and communicate the purpose:

● which problem the team is trying to solve

● why the team is solving that problem

● how the team will solve that problem

● when the team will solve the given problem

● which is the expected outcome of the initiative

● where is the team currently in the initiative roadmap

● who are the team members and which task they are assigned to

● what the constraints are

I'm a big fan of the idea of ​​giving the team the problem instead of a list of features. I leave it to the team to find the optimal solution.

SIX-MONTH REVIEW

This principle of leading an initiative - as a product - is new both to me and my colleagues. We learn along the way. I envisioned that every 6 months all relevant participants meet and go through the good, the bad and the ugly of this experiment. A sort of a retrospective. No process is perfect and if we do not improve it continuously - it will degrade over time.