As a team of embedded software engineers during a refinement session we once faced the review comment ‘This doesn’t make sensor’ when something actually didn’t make sense. It became obvious that the auto completion from the text processing program also seemed to have learned in what environment we are working – we build control units for boilers for central heating. This does not always give us only ‘happy moments’, as our architect once phrased it. But often enough we burst into laughter, since we do take our work seriously, but not ourselves.
A high velocity is not the key to happiness
Since our customer is represented inside our team by our product owner (PO), we did our best to gain his confidence in our way of working. Interestingly enough, our PO seems to not care too much about our velocity expressed in how many user stories of a certain complexity we can finish, but more about our attitude and that we show a sense of urgency. After we developers and testers understood this, we shifted our focus from mainly picking low-hanging fruit to tackling bigger challenges. Meanwhile we immediately would communicate problems and throwbacks in a clear way. This enables our PO to set up a realistic planning and to establish the relationship with the customer.
The customer more and more understands that we are not hiding bad news but give our best to minimize potential project risks. He can then, on the other hand, also take measures to deal with an eventual delay in delivery or with a limited scope for the functionalities which will be added to the product in the next phase.
In every sprint we set up a direct meeting with the customer and we make sure that we have a working version of the product so that we can demonstrate the finished user stories and deliver a stable in-between release.
Being agile means to cut down tasks in user stories as little as possible and not to worry too much about the future, since you have reserved time to react on unforeseen problems. You can build a trustful relationship with the customer by sharing problems and possible risks and by communicating delays immediately.
Author: Josephine Wittkowski
Consultant ALTEN Technology (Technical Software)