I can honestly not imagine how this project could be handled in a waterfall, i.e. non-agile way. In the beginning we suffered from a lack of good requirements and the architecture was still in development, but we were supposed to comply to continuous delivery and integration to enable the customers and suppliers to test the product as soon as possible and to set up the production chain early enough.
We regularly receive feedback on the documentation which at the same time serves as our requirements and which we write ourselves. Eventually we then need to plan changes in already released functionality to satisfy the needs for the various markets in which the heating boilers will be sold.
Another kind of unwelcome feedback is unexpected behavior of the released software – reported for example as issues found during extensive testing at the customer’s site and internally treated as bugs. Recently my team moved to a new procedure. Now bugs are classified and investigated on a high level first by a senior developer. Then he or she decides how urgent it is to react on the issue and how much impact it has for the rest of the functionality. Also reported issues are only put on our backlog any more when they are described in a clear way to enable us to reproduce the mal-behavior and to estimate the severity.
Otherwise it can take a long time (months) until a bug gets any attention. Then issues which have been solved already in a different context get too much attention while hidden monstrous sleepers could make our lives very hard and lead to stressful situations.
My team has a steady learning curve. Luckily we are not forced to stick to decisions which we made at the beginning of the project when it comes to internal processes. Other examples of refined processes are the definition of done of a user story for implementing a certain function, or the testing environment and the test coverage.
Author: Josephine Wittkowski
Consultant ALTEN Technology (Technical Software)