In two days, you can train and get certified as a SCRUM Master – online, mind you. This apparently misleads quite a few managers into the mistaken assumption that agile IT is easy and quick to implement. In terms of methodology, that may be true. But the decision for agile IT is a decision for a cultural change, which is underestimated by many executives. That’s what this article is about.
Do you find agile IT and agile project management exciting and interesting? Then you are like me! I see this as a great opportunity to flexibly and quickly implement requirements placed on the IT organization. But not everything that calls itself agile actually is – so take a closer look together with me.
True agile IT - or just painted agile?
Let’s get right to the point. How can you distinguish an agile IT from an IT organization that is merely “painted agile”? In my experience, there are two main conditions for this that a client of a project must fulfill.
The first is: My only point of contact is the product owner. This means full trust in the SCRUM team, no reporting or control authority, and regular participation in planning and review meetings. If this is the project culture you live or strive for in your IT organization: fine. Otherwise, you can assume that the project is only painted agile.
And the second condition? This is about money – of course. It is essential that the client is aware of one thing: there is no guarantee to get a predefined service at a predefined date for a predefined amount of money invested. So if, for example, there is talk of calculating costs and setting deadlines for backlog items, you can confidently assume that the client is also not serious about agile IT. Or simply did not understand it.
Agile IT means proximity to the business
It is also true for agile-led projects that the qualification of requirements is a decisive factor in determining how complex the realization is and how many iterations are needed to implement a requirement. The closer the Scrum team gets to the competence teams in the business units, the better. My personal experience is that direct exchange is particularly effective. And only minimal methodological competence is required.
Keywords in this context are epics and user stories. In this context, an Epic describes a business capability – i.e. a service that the competence team from the business unit provides internally or externally. An Epic is broken down into User Stories. These then each describe self-contained units that can be realized by the Srum team within a sprint of a maximum of 4 weeks. For example, for a retail company, an Epic could be the processing of orders. And the user stories then describe the support for the various channels through which orders are received.
The advantage: At the end of a sprint, a fully developed functionality can be presented to the client. This allows the client to experience the progress of the development. And if there were any misunderstandings in the requirements, they become clear in the Sprint Review so that adjustments can be made quickly.
Sounds good? It is - but how do you achieve it?
First things first: The cultural change for agile IT must be wanted and fully supported by IT management. Specifically, this means that the agile manifesto is understood at the executive level. As a consequence, competencies may have to be redistributed.
Secondly, it is necessary that the financing of Scrum teams is completely decoupled from the realized agile projects. In concrete terms, the employees with the necessary skills must be financed or purchased for a fixed period of time. And that depends solely on the company’s chosen IT architectures and standards. The agile-led projects in which these employees are then deployed are completely independent of the funding decision.
And last but not least: Agile IT and agile-led projects only really make sense if it can be ensured that finished developments can also be put into production quickly. On the one hand, this requires lean processes and efficiently organized acceptance tests, and on the other, automated test and build processes. The keyword in this context is DevOps – the topic is worth a separate article.
Final thoughts
Flexibility and speed are a decisive competitive advantage, especially in medium-sized companies. My personal opinion is: Agile IT is mandatory in the SME segment. Regulatory restrictions may exist – but that doesn’t stand in the way of agile IT. The same applies here: Those who want to, look for ways – those who do not want to, look for reasons.
I will be happy to analyze the existing strategy together with you. We find out what needs to be done to realize fully agile IT. With tailor-made coaching for executives and IT teams I help you with the implementation. I look forward to being able to support your company in this!
