June 14, 2018
Get in touch
Today, everything is agile and terrific. All the problems in projects and software development have disappeared into thin air. “Shiny, happy people” as far as the eye can see. Everything is simpler and simply better. Really?
Every self-respecting software- or Internet agency sells itself today as agile. And most of them have been claiming for a long time that they work according to agile project methods. In the vast majority of cases, this is simply not true and yet it is not really a lie.
When talking to numerous software teams during my daily work, especially in the area of traditional CMS- and/or E-Commerce services, I regularly notice that many smaller providers have not yet fully understood what working according to agile principles really means.
Often “programming without a concept” is what people think is agile. Which, of course, doesn’t even begin to explain the concept. Alternatively, there are artifacts known by such terms as daily, retrospectives, etc. in the various approaches to Agile. However, the meetings usually involve completely different activities and processes.
I am therefore convinced that such “quasi-agile” projects have exactly the same potential for drama as conventionally organized waterfall projects. And I’ve seen more than a few of them go wrong.
In my opinion, one can only really benefit from the advantages of agile development if the approach is implemented consistently. From experience, I can say that an agile project is only really successful when the customer provides a capable Product Owner who accompanies the development in iterations together with the team and can also really make decisions.
In addition to the hierarchy within the company, the product owner must also have the necessary detailed expertise so that decisions can also be made on a technical level.
And for larger projects he (or she) should be available exclusively for the project. It’s not an easy combination to find.
In my opinion, a comprehensive understanding of the processes is of vital importance in order to be able to carry out agile projects with new customers. Very few customers have this depth of knowledge.
Therefore, there is nothing more obvious than to impart exactly this knowledge to the customer. AOE offers a two-day course for new customers, if required, to familiarize themselves with the basics and subsequent details of the agile development process. Managers from outside the project are especially welcome, as they have to have to be familiar with these processes as decision makers or influencers of decisions.
These courses are usually provided free of charge for the customer. When I told this to a colleague of a software company a few months ago, he said that it was harsh that the provider would even have to bear the additional expenses. However, this money is in fact very well invested – after all, it significantly reduces effort and annoyances in the project later on.
When I was recently allowed to talk about Agile companies and using Agile methodologies in day-to-day work, someone said during the Q&A that there are still find numerous customers who don’t know Agile frameworks and in particular had never gone through a design-thinking process. I think that’s a good point. That is indeed difficult.
In such situations, I find it fatal to communicate that one works only according to Agile guidelines and principles. In a manner of speaking, this excludes the customer.
In my opinion, it is much better to give the customer the choice between the traditional approach and new, Agile methodologies. In my experience, if you take a little time to explain the advantages and disadvantages, many customers are very keen to try Agile. they then they approach the process more consciously – which in turn increases the chances of the project’s success.
