Introduction
Agile methods are best known for their application in software development, more precisely in "software-only" environments. Less frequently, but also more and more often, they are also used in hybrid product development environments, i.e. where hardware and software together “create” the product. A very prominent example of this is the German carmaker BMW.
Without implementing real agile "product thinking", agile approaches are also often used for the pure implementation of an otherwise classically planned project. Then it is referred to as so-called "agile project management" and focuses exclusively on the division of work and processing in fixed periodic periods, called "sprint" (borrowed from the agile framework SCRUM). This misappropriation is very popular and often arises simply from a misunderstanding and inadequate training in this field. It could still be useful in some cases, but unfortunately its use also leads to the passing on of dangerous half-knowledge, which has also led to damage to the reputation of e.g. SCRUM from time to time.
Where, and in what way, this misappropriation can make sense and what it looks like in detail, I would like to take a closer look at here in the context of digitalization or digital transformation in the context of Industry 4.0.
What's missing?
The reduction of agile product thinking to the pure implementation work of a classically planned project means completely omitting essential parts of the agile mindset. Rather, one has to speak of picking out a few elements instead of a reduction. I would just like to talk about the missing parts, which would be a more than useful addition to arrive at a more flexible project management that has great advantages over classic methods, and that could be used effectively in many areas of application, far beyond software development projects:
Both, the familiarization with the contents of the project, and the implementation are carried out by a team put together for this purpose on a permanent basis, henceforth called the "implementation team".
The implementation team is responsible for the introduction to the project and the resulting division of the project into small work packages together with the client.
A work package is so small that it can be completed in a few days.
A work package is a "partial product" that already has added value in itself, i.e. can already be used by the client.
During implementation, the aim is always to complete a single work package before starting the next one.
The most important work packages will be implemented first.
These additions address the main reasons responsible for project failure:
It doesn't build what the client wanted, or what is built doesn't solve the problems it was supposed to solve.
Only at the end of the implementation of the overall project can it be judged whether what has been built also meets the expectations of the client.
These reasons are mitigated or completely erased by the above additions, since the people who are entrusted with the implementation have to know the requirements without indirection. You need to understand the overall context and be able to clarify open points through direct questions. In this way, they also have the opportunity to submit their own implementation proposals, which could produce a more targeted and profitable solution. If the most important components are developed first and brought into a usable condition, the customer can try them out at an early stage and his most important problem is solved first.
Why does it fail?
When planning a project, it is often not certain whether it will actually be carried out. The planning only serves to submit an offer, i.e. an estimate of the effort and thus the price for implementation. At this stage, due to the uncertainty of whether or not implementation will take place, no implementation team is selected or newly formed and therefore cannot be involved.
An implementation team often includes people who are not used to dealing directly with a client. They are not trained for it and they do not have the understanding to see it as part of their work. Especially if it is an external client, aka customer. The project manager is therefore reluctant to let his own employees get in direct contact with the customer.
Last, but not least, there is often a lack of recognition that bringing the client together with the implementation team massively minimizes the greatest project risk: Those who learn first-hand in dialogue what is needed do not have to guess and can clarify questions of understanding directly.
In which areas of application can this method be used? Only in software development?
The explained procedure can be used in the implementation of many different types of projects. It is particularly suitable for projects related to digital transformation, i.e. the revision, rethinking and digital set-up of processes in companies. This use case is so exciting because, in my experience,
the company's own IT department is responsible for the implementation, but either has no experience with agility or does not think of using it for the implementation of non-software development tasks,
the client is usually the management of company itself, i.e. it is actually very easily "accessible" and available for arrangements, queries and, if necessary, workshops and
the user of the devised solution is also in-house and can therefore very quickly and easily use and evaluate the first implementation results directly.
In other words, an optimal environment for use is given. Furthermore, the risk of failure is very high in the case of digital transformation, because strangely enough, the user, namely one's own employees, is often not involved at all, although this is/would be the key to success. See also my other post "Taking the employees by the hand".
Here are just a few examples of projects in the context of digital transformation that would benefit from the approach described:
Switching office communication from telephone and fax to email or collaboration tools such as Microsoft Teams or Slack.
Switch on-premise operation of Exchange and file servers to the use of cloud services.
Replace the paper documentation of process steps with the use of an WMS, MES or ERP system.
Consolidate data from different, independently existing IT systems into a single collaborative data platform such as Grafana using an MQTT broker.
Automate previously manual interactions with IT systems.
etc. etc. etc.