2020/08/20

Agile IT & DevOps: What is left of the hype?

by Hans Gaiser

Agile IT & DevOps

"Agile, everything must be agile. It's a good thing that now we only have moving targets and nothing is constant."*

(*Statement of an IT manager of a large telecommunications company on the currently inflationary use of the term "agile" in many companies.)

Agile methods are currently experiencing a hype and are now used for all kinds of projects. Most projects work with the Scrum framework. Originally intended for software development, Scrum is pressed into all kinds of projects and bent until it fits - the main thing is that you can say that you are working agile. I currently observe this trend in many projects. There is always some hype, and most of the time it behaves like a pendulum that first swings strongly to one side (everything agile), but will soon swing back and then settle down to a realistic level.

The 4 stumbling blocks when introducing agile concepts

The agility pendulum is still swinging strongly to one side. This is reason enough for me to point out four critical points which, in my consulting experience, are the stumbling blocks of this topic:

1. Does the agile approach fit to the result to be delivered?

If a software development including customers is necessary, the more likely it is that this can be affirmed. Also, if the delivered item can be incremental, then Agile may be the right choice.

My observations are that currently the organizational structure of whole companies is being completely rebuilt in an agile way instead of being limited to single software areas. However, at the same time the agile approach and especially Scrum is too often bent; in the agile community also called ScrumBut. However, the agile values and principles that actually define the term "agile" since the Agile Manifesto of 2001 get out of focus. Scrum is a method or even a suggestion how agile principles can be used for a project. When using Scrum, however, the core meaning of the agile principle is often ignored - an example is the consistent orientation towards MVP or non MVP content.

2. Is MVP* and non MVP lived?

It is a good idea to proceed incrementally and first build up the important (business) functions and then establish them in the market.

My observations are however that there is no clarity about what MVP** actually means. Basically, it's about prioritizing the functions that serve a business purpose and create value. The functions prioritized as important should then be implemented as "mandatory" and not later as "optional". This raises the question for whom is it important? -the product owner or for the architect? But even if this step should be clarified, it is still not consistently followed. Non MVP functions are often bent in such a way that they have to be implemented despite their low enterprise value.

The agile manifesto states that agile teams need decision-making competence and should be self-organized. In my experience, however, they will always rely solely on the product owner. Product Owners, who will fulfill their role to the end and whose task it is to be able to say "no", will be disempowered or will not even enter the conflict.

A new term in this context is MMF (Minimum Marketable Feature). These are the function(s) that I need at least to be able to market a product. In contrast to MVP, which is more about fast learning and feedback from the customer. The MMF approach, in contrast to the MVP, offers a first real customer benefit, even if only minimal.

3. Automation and CI/CD?

One of the key points of agility: Automated testing on a daily basis and the possibility to launch new developed software tested daily.

Unfortunately I have not yet discovered that this works. In my opinion, this is due to the fact that we are working too late on the prerequisites that need to be created for this - often only after the project has been running for a long time. Understanding and learning the necessary tools is as much a part of this as creating the understanding of roles and enabling key players (especially release/integration managers, development leads, testing leads and DevOps).

It is also necessary to provide capacities for automation, and to invest time and money. The alternative is manual testing, which also costs less. On the other hand, this often leads to errors in production or longer delivery times. Therefore, it must be considered whether automation is worthwhile, since not every product needs a rapid time-to-market. Nevertheless, I am convinced that customer feedback as early as possible in the development process, e.g. through prototyping, makes sense.

4. DevOps understanding and implementation?

Another keyword in the agile world is "DevOps". In my opinion, too often only people are appointed as DevOps for no apparent reason, which means that the implementation is only half-hearted.

To remove the separation between development and operations in one person would be my short definition of this agile and central role. The point is not, as in the old days, to throw the things developed by the developers in a project over the fence to the area responsible for the operation and leave the rest to them. If the DevOps role is correctly accepted and filled with life, its involvement in the development phase allows questions and problems that otherwise only arise in the operation phase to be addressed right at the start.

The most thwarted experience I had in the real world was when two DevOps managers agreed that one would take care of development and the other of operations.

To avoid such mistakes, it is helpful to first look at the Agile Framework and especially at the beginning to do a maturity measurement.

My conclusion

Agile and DevOps are not easy methods to "build in" with Scrum or the introduction of roles. They are based on fundamental principles and approaches, which often require a profound change of the previously used procedures. Correctly and adapted to the respective environment as well as with the appropriate investments, faster reaction times and higher quality can be realized.

I would be happy to discuss your specific problems and the appropriate solutions with you. One size does not fit all!

 

**A Minimum Viable Product, literally a "minimal viable product", is the first minimal viable iteration of a product that must be developed to meet customer, market or functional needs with minimal effort and to provide actionable feedback.

Share this page