Trends

AI – Where we are in the Hype Cycle and how it continues

While the artificial intelligence index shows that the increase of research articles and conferences in the field of AI continues, the media is slowly showing some fatigue in the face of the hype. So it’s time to take stock: What has been achieved? What is practically possible? And what is the way forward?

What has been achieved?

In the years 2018 and 2019 the previously developed methods for the application of neural networks (this is how I define AI here) were further refined and perfected. Whereas the focus was initially (2012-2016, Imagenet competition) on methods for image classification and processing and then on audio methods (2015-2017, launch of Alexa and other language assistants), major advances in text processing and generation were made in 2019 (NLP = natural language processing). Overall, the available technologies have been further improved and combined with a great deal of effort, especially from the major players (Google, Facebook, OpenAI, Microsoft).

What is practically possible?

The use of AI is still essentially limited to four areas of application:

Images: image recognition and segmentation
Audio: Conversion from speech to text and vice versa
NLP: word processing and generation
Labeled Data: Prediction of the label (e.g. price) from a set of features

This list is surprisingly short, measured by the attention AI receives in the media. The most impressive successes of AI, however, result from a combination of techniques such as speech assistants using a combination of audio, NLP and labeled data to convert the input into text, recognition of text intention with NLP and prediction of the speaker’s wish by using huge amounts of labeled data, meaning previous evaluations of similar utterances.

Decisive for the development of precisely these AI application fields were

the existence of large quantities of freely available benchmark data sets (data sets for machine learning) on which algorithms have been developed and compared
a large community of researchers who have jointly agreed on the benchmark data sets and compared their algorithms in public competitions (GLUE, Benchmarks AI, Machine Translation, etc.)
a free availability of the developed models, which serve as a starting point for the practical application (exemplary Tensorflow Hub)

Based on these prerequisites one can quickly assess how realistic some marketing fantasies are. For example, there are neither benchmark data sets nor a community of researchers for the often strikingly presented field of application of predictive maintenance, and accordingly there are no models.

What’s next?

On the one hand, it is foreseeable that the further development in the AI area will certainly continue initially in the above-mentioned fields of application and continue to develop in the peripheral areas. On the other hand, areas are emerging which, similar to the above-mentioned fields of application, will be driven forward at the expense of large public and private funds (e.g. OpenAI and Deepmind are being subsidised by Elon Musk and Google with billions of euros respectively). An example of large investments in this area is certainly autonomous driving, but also the area of IoT. In total, I see the following areas developing strongly in 2020-2022:

The combination of reinforcement learning with AI areas for faster learning of models
A further strengthening in the area of autonomous driving resulting from the application and combination of AI and reinforcement learning
Breakthroughs in the generalization of the knowledge gained from image processing to 3D (Geometric Deep Learning and Graph Networks)
A fusion of traditional methods from statistics with neural networks
IoT time series (see below)

I see a big change coming with the rise of IoT and the associated sensor technology and data. By their very nature, IoT data are time series that must be filtered, combined, smoothed and enriched for evaluation. Relatively little specific has been done to date for this purpose. It could be that from 2020 – 2022, this topic could hold some surprising twists and breakthroughs for us. German industry in particular, which has benefited rather little from the initial developments in the field of AI, should find a promising area of application here.

Agile physical product development?

My last blog post was about teams that only become really agile through experience. Today, the focus is on the challenges that agility brings to engineering.

Almost 20 years after the Agile Manifesto, agile software development has become widely accepted. It is no longer about whether, but only about best practices in detail and agile scalability. The success and ease of use of task boards, for example, have led to agile procedures also finding enthusiastic users outside software development where tasks are processed in a team.

This finally led to the increasingly intensively discussed question of whether physical products could also be developed more efficiently with an agile approach.

Why?

For many years, there have been established product development processes that have reached great maturity and support successful development. Why abandon them and take on the risks of a completely new approach?

The more unclear the requirements on the product are and the less known the technology to be used, the less suitable classical project management methods are, because they are very strongly forward-planning. It is precisely this tendency to start projects despite initially incomplete requirements that we are increasingly observing. Digitization and new technologies require new business models or new technological capabilities. This speaks for an agile approach, as it was invented to deal with ambiguity and not-yet-knowledge.

Is that even possible?

The decisive question here is: Are agile methods from software development at all suitable for mastering the challenges of “classical” product development? In contrast to software, physical products are developed with a much greater division of labour. The production of faulty components causes high consequential costs and the validation depends on physical prototypes. It is not possible to present a new, functioning and potentially deliverable stand every two weeks. Solutions for such problems require a creative further development of the known agile process models. A very simple example: The teams of different domains use different sprint durations. While the software team delivers every 2 weeks, the mechanics team delivers every 6 weeks. It is important to synchronize the sprints so that a common increment is achieved every 6 weeks.

The challenge

The challenge of introducing agile methods is therefore twofold: On the one hand, it is necessary to adapt the agile methods from software development to the conditions in product development. On the other hand – and this brings me back to my previous contribution – a lot of agile experience is needed to successfully make such adjustments. In order to resolve this contradiction, one should bring together the pioneers who dare to venture into new territory with experienced “agilicans” who master their craft in software development. Mutual learning and sharing of knowledge leads to a better mastery of product development under rapidly changing conditions.

Being agile or appearing agile?

When I first heard about agility years ago, I first had the impression that processes and rules should be thrown overboard in order to miraculously realize volatile requirements in the twinkling of an eye. I couldn’t imagine how this would work: agility sounded to me like an unattainable wish concert.

Initially, when our software development team started to work with Scrum – with me as the product Owner and guided by an experienced Scrum Master – I seriously dealt with the topic.

I learned that agility does not mean chaos, but quite the opposite was true:

Lesson 1: Discipline

Agile approach has rules. We learned them in the previous Scrum training, but most of all our Scrum Master advised us to strictly adhere to the Scrum rules instead of interpreting them in the way that seemed most appropriate to us. What I learned: Agility is not a laissez-faire, but requires a very disciplined approach that only works if it is lived consistently and not bent as needed.

Lesson 2: The Sense

Fixed roles and rituals are useful. We had learned them for Scrum, but real understanding grew gradually through coaching and the questions of the Scrum Master. For example, when in the process of a sprint it turned out that several of the agreed user stories would not be reached. Of course, all team members tried to do their own job in the best possible way. This would have meant that the individual user stories would only be completed to 70%. The Scrum Master, however, put up for discussion the idea of discarding one or two user stories for the sprint instead and helping to complete the others. What we learned: Results orientation and focusing on a common goal make teamwork more productive and team members more satisfied.

Lesson 3: Team Spirit

The more we internalised the meaning of the rules, roles and rituals, the more efficient the projects became. The team grew more and more together and not only a common focus on achieving the goal developed, but real cohesion. Where previously colleagues had expressed a lack of understanding for each other’s work or had blamed each other, everyone in the team now knew what the others were doing and why. They helped each other to the best of their ability and trusted each other more and more. And because sustainable learning works above all through positive emotions, this was the point at which we developed a real understanding of agility.

In the end it became clear to me that agility only comes about through the interaction of rules, people and motivation. Understanding the agile values behind the rules is crucial. Otherwise there is the danger – by picking out or bending individual rules to one’s own needs – of failing with the agile approach.

This does not mean that the agile frameworks must not be adapted or selectively applied. But you have to understand them first.