The Developer Survival Guide Practical advice to manage difficult situations as a software developer

Why the sprint review is important to developers

The sprint review meeting is crucial for you, the developer, because this is the time you will be able to both give a lot of visibility to what you are doing and also get the feedback necessary to better align your work on the real needs of customer and or users. Yet too often, this meeting does not achieve these objectives because it has been badly prepared.

Show what you have done

I would like to draw your attention to two of the main problems that may be encountered.

Firstly, showing the result of work that has no user interface, and then secondly making sure you show something that works.

For the first point, the difficulty intensifies when you are dealing with people who have never been programmers. They often do not realize that a developer can sometimes work for weeks for minimal changes to the user interface. In other words, they can hear what you have to tell them, but they cannot see it. The solution developers choose far too often is just not talk about it.  If you can’t demonstrate it – don’t show it.

This attitude is typical of personalities we technicians have.  It is undesirable because you cannot then get the views of your user on the progress.  Their understanding and view is much more important than yours.  You are first and foremost in their service, and not the reverse. Developers who comprehend this have a very significant advantage over others.

The best way to show something that will not be obvious in the user interface is to use a presentation slide that describes the change. Because every time you develop software it is supposed to add value, you must find a way to highlight it. Some examples:

• For performance improvements, clearly indicate the gain in a metric understood by the user.
• If you have completed some intensive code refactoring, you should be able to demonstrate the usefulness of the work by using metrics highlighting the reduction of complexity, testability, or other value that will in the long term give significant savings in maintaining the code.
• For the functions for which it is impossible to show something, such as support for a new source of information in a communication tool, do not settle for spending a few moments going through an a list of work done. Describe the challenges you encountered - this should give them the context that they lack.

In any case you should avoid sounding as if you are just justifying the time you have spent on the work.  The idea here is to evidence that you have progressed and that you are in control of the situation.

One last thing about the demonstration: Make sure you do the following things:

• draft a scenario that you will repeat to your users.  You must not just randomly chat about the project
• This scenario should cover most of the needs expressed by the client. This makes sure you are not interrupted by constant questions during the demonstration. In addition, this will allow you to ensure good feedback (we will cover this again below).
• Run the demonstration several times on the machine that will be used during sprint review. This should eliminate most problems.
• Rehearse it once or twice under the same conditions as the meeting. That is to say physically in the room with the same equipment.

Collect feedback

Great developers excel in this task. They know that developers who give the most satisfaction to their users or customers are those who understand and realize the things that bring their customers the most value. This type of profile is very rare and it is again very difficult for a technician to fully grasp this concept.

Everyone knows that the users are usually more comfortable when describing their problems than with finding solutions. There must be a real interaction between the technician who will eventually devise the solution and the person who has the problem. For this interaction to be productive, the programmer should be able to ask the right questions and discuss areas for improvement - and this is especially true during sprint reviews.

Many developers fear this time because they are likely to be criticized. This particularly affects perfectionists. Here are some tips to manage any negative reviews:

• Be aware that criticism of your work is primarily criticism of the latter – the work, and it would be inappropriate to assume that the customer is actually criticizing you.
• Remember that criticism relates mainly to the person who has made it and how they have interpreted the situation.

Having considered the two points above, we must consider every criticism as an opportunity for improvement.

Of course, all this also applies to positive feedback and I will write an article soon that will cover this in detail.

To summarize:

• You can show your progress and all your activities
• Feedback is an opportunity for you to excel in your profession