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
How to become indispensable
All social groups seek the company of people who help them reach their goals. For example a network-gaming oriented group will generally be composed of people with profiles compatible with the purpose of the group: gamers. On the other hand, people with generally incompatible profiles are rejected. This becomes a problem when someone still wants to join with an inconsistent group. The only solution for that individual is to adapt and align their goals with those of the group, or find another group compatible with their current profile.
In the case of a social group, this process is more or less unconscious. In a company, it's the same thing, but with the aggravating circumstance that you generally cannot choose. If you are not aligned with corporate goals, you will eventually pay the price. On the other hand, if you understand that the closer you get to the corporate goals, and show that you will help achieve them, you will become indispensable.
This type of person was recently named the Linchpin in the latest book by Seth Godin (which has the same name). Here is his description:
There used to be two teams in every workplace: management and labor. Now there's a third team, the linchpins. These people figure out what to do when there's no rule book. They delight and challenge their customers and peers. They love their work, pour their best selves into it, and turn each day into a kind of art.
Linchpins are the essential building blocks of great organizations. They may not be famous but they're indispensable. And in today's world, they get the best jobs and the most freedom.
This book is really worth every penny, and if you like this article, I strongly suggest you to buy it as it is full of similar content.
In this article I will tell you about a simple and effective way to become indispensable: make sure you do not create new problems, and on the other hand, that you solve a lot. Become a problem solver.
The trick in organizations is to identify what is "creating a problem" and what is "solving a problem". For example it is not necessarily creating or resolving bugs. It's evident that if you create many bugs, you're creating problems, even though when you solve them, you are solving problems. I will focus on another kind of behavior that can be considered, generally unconsciously, the same as the act of creating problems. Some problems that you are not directly responsible for will still be associated with you just because you report them. Or worse, you don't report them. Here are examples of behavior that will be seen by your management as problems that you create (or bring) while this is not necessarily the case:
- You complain to your hierarchy about your work environment.
- You indicate that your application has serious performance issues.
- You report that the components suite that you purchased is not suitable for your needs.
All these examples are your problems until you talk to your manager. They become the problem of the manager from the moment you bring them to him. Even if you are not directly responsible for these worries, you'll be automatically associated with them. The average manager has no time to deal with new problems and he will try to avoid anything related to them.
The first tip is to manage them yourself as much as possible and thus to take responsibility. You have everything to gain with this attitude. Because in this case, you do not create the problem, you are really solving them! Very few people have the ability to take responsibility for such decisions. But we can develop that talent by doing. When you face a problem, ask yourself the question "can I myself, or with the help of my colleagues solve this problem?"
Unfortunately in many cases this is not so easy. You will simply not be able to adopt that attitude for organizational reasons, such as hierarchical approval processes. If you can't be the decision maker, you must pass it to the management. Faced by what seems to be a great constraint, there is a very simple technique that is used by the indispensables and almost always overlooked by others: report the problem and your recommended solutions.
Too many people limit themselves to reporting the problem and then are inevitably associated with it. When reporting the possible solutions you are associated with them and then credited for what you've become: a person who solves problems. Someone absolutely essential to keep in the organization in contrast to those who create the problems and who it would be better to get rid of. The more you act this way, the bigger your circle of influence grows. Your opinion will have more and more value. While you are improving your company, you'll also improve your own working conditions.
Just like the basic concept, the technique is extremely simple to remember. When you encounter a problem that affects you or your company, do the following:
- Identify possible solutions to the problem.
- If you think you can solve the problem directly, without the advice or approval of a tier, do it without hesitation.
- You cannot (yet) make the final decision? Then report the problem with the solutions obtained in step 1.
Examples repeating the above examples:
- You complain to your hierarchy about your work environment: if the problem can be solved with a purchase, specify the references of the desired material as well as all associated costs. Don't forget to explain how you are affected and how it impacts the company.
- You indicate that your application has serious performance issues: don't excuse yourself, they don't care. Recommend potential architecture changes instead or at least an external expert that could come up with more advice.
- You report that the components suite that you purchased is not suitable for your needs: propose a few alternatives that you have tested and always give your personal opinion (what you would pick if you were the boss).
Additional tips to write an effective problem/solution report:
- Be convincing by using an appropriate response structure (see this article).
- Write your email so your boss just has to write the word yes or no in his reply.
- If you have many problems to report together with your solutions, send them in one mail only, even if it's more logical to have separate threads in case of discussions. The average boss will generally try to avoid discussions.
- Focus on the problem and the solution and only that. Avoid talking about people when possible.
Becoming indispensable to someone is a lot about solving his problems and having the same goals. Companies are seeking problem solvers. Become one of them.
6 advantages to using third party libraries over developing your own
You should always consider using existing software components instead of developing your own; even if you think that the latter would be much better. Here are 6 reasons why working with third party projects (open source or commercial) is usually a better choice:
- Domain expertise: Authors are usually experts in the domain covered by the library. This will ensure that you will get the most appropriate implementation. A good example is SharpMap. The main committers are experts in geospacial software.
- Stability: These libraries have the big advantage of being used by other people as well as you, and in many cases, hundreds if not many thousands of developers worldwide. Most of the early problems have already been encountered by others and fixed by authors. If they don't fix them, it's a good opportunity for you to contribute and give back to the community!
- Knowledge: You will learn from others’ code and design. Many popular libraries are written by top notch developers and are usually great examples of good coding practices and design. You will learn by just using them.
- Finance: You save tons of money. The equivalent of hundreds if not thousands of man days of work for free or, at the very worst, the cost of one man day for commercial libraries.
- Support: Paid libraries usually come with free support from top class developers that you can contact 24h a day. Many developers of free libraries also provide that level of support. Exposing your team to these developers will be beneficial for them.
- New features: They will appear automatically, without effort, in your product. If you are using the reporting engine from vendor X, and vendor X releases the new feature Y, you will be able to provide the new Y feature to your customer at no cost, with very low effort. You can consider the authors of your libraries as other teams working for you, for free or for very little money!
So, assuming that you are not an expert in the domain, don't have thousands of users, have lots to learn from others, don't have tons of money, will probably need support and resources are stretched, don't reinvent the wheel. Unless you plan on learning more about the wheel.
Do you think NASA would have been able to send men to the moon if they tried to build the components of their rocket themselves?