Agile Project Planning (APP) — Part 1: Requirements Engineering (RE) is going to be agile!
Working as a consultant, trainer and coacher in requirements engineering for more than 15 years, I have helped a lot of companies in their projects improving the requirements management process using different approaches. Since the agile development methods are becoming widely used, Agile Project Planning (APP) Curriculum were published, to help integrating requirements engineering into the agile approach.
In this blog series with 3 parts, I would like to present to you the highlights of this curriculum and the misunderstandings in RE one could have while following an agile approach.
And now let’s see the first one:
Plan- and document-based requirements engineering vs. agile requirements engineering?
Have you ever dealt with this question, which a lot of requirements engineers also might be facing? In my opinion, it is the wrong question. Because, if the agile approach is the solution in a certain context, requirements engineering must support this approach in the best possible way, but still, it remains requirements engineering.
In this blog series, I will show you the trends of the agile transformation in requirements engineering and some common misunderstandings regarding to the requirements in an agile environment. Let us get started with how we can find a way to integrate requirements engineering into agile approaches.
I think the distinction between traditional and agile requirements engineering is useful per se. To give an example, it can help to understand, that the ways of handling requirements in different contexts are different. But it is not a separation between different disciplines. Requirements Engineering is Requirements Engineering itself. It has always pursued the goal of creating a common understanding and a common view of the requirements among all those involved people in the project for a system to be developed. To achieve this goal, the requirements engineering must adapt to the context of the project and the chosen approach.
Why has an agile approach been chosen more and more often in the recent years? Or in other words:
If agile is the solution, what is the problem?
We are living in a VUCA- world nowadays.
Compared to previous decades, the extent and speed of changes is increasing. (volatility) Thanks to the Internet, users are more comprehensively, better, and faster informed than ever before, additionally they demand faster reactions from producers.
Forecasts and planning become more difficult with increasing uncertainty. Therefore, quick reaction to changes becomes more important. (uncertainty)
Why is uncertainty increasing in a field such as system development? This is because the systems we build to meet the demands of the market are becoming increasingly complex. The relationship between the cause and effect, between problem and solution is no longer linear and therefore the solution is no longer clearly predictable and plannable. We are more often confronted with unknown unknowns during the entire development process. The uncertainty is growing.
In addition, there is another aspect: we, who as organizations build these systems, are also complex systems. Consequently, we get constantly into a context, where complex systems are built by complex systems. (complexity)
The ambiguity in the terms of things we deal with is also increasing. (ambiguity)
Traditional planning and control instruments are no longer sufficient to develop products in such environments. The approach to development must inevitably change, because in a world of unknown unknowns we do not know all the questions we should ask at the outset. And so, we cannot know all the answers, and thus all the requirements in the beginning either. But we do know that it makes sense to come across the questions as quickly as possible, which we did not know we should have asked at the beginning. Sounds complex? It really is.
That is why we need an approach that allows us to learn quickly and adapt to the changing situations. This is where the agile approach has proven its strength.
Scrum as a common agile process model
Scrum is based on the theory of empirical process control, which is supported by three pillars: transparency, review and adaptation.
According to the Scrum Guide 2017:
Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
What does it mean?
With empirical process control, we neither define the exact scope of the system to be manufactured, nor define exactly the process of how this system is to be manufactured. Instead, we build small, deliverable parts of the system in short cycles. After that, we check what we have built and how we have built it. After revising both the system and the way we built it, we can adapt them based on what we have learned from the review. This feedback-oriented approach allows us to come across questions quickly that we were unaware in the beginning.
What can requirements engineering look like while supporting such agile approaches?
The Scrum Guide does not tell us much about this, which unfortunately leads to lots of misunderstandings and misinterpretations in practice.
In the 2nd part of the blog series, you will find the most typical misunderstandings regarding the requirements in an agile environment.
And try to learn more about Agile Product Planning in my curriculum:
https://www.hood-group.com/agile/training/agile-produktplanung-curriculum/
Uwe Valentini,
Coach, Consultant, Trainer at HOOD Group
