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.
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.
- You can show your progress and all your activities
- Feedback is an opportunity for you to excel in your profession
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?
When I needed to do presentations of Scrum to executives and students, I started to look for existing ones. Most presentations I found were very good for detailed presentations or training. But what I was looking for was a presentation I could give in less than 15 minutes (or more if I wanted). Most of them also contained out dated content. For example, the latest changes in the Scrum framework were not present and what has been removed was still there.
I decided to start over and created a new presentation with the following objectives:
- Based on the official Scrum Guide: the structure is very similar and I attempted to extract only the essentials.
- Not more than 10 slides (without the front and back cover).
- The least text possible to extend the possibility for the presenter to say what is important to his organization without missing the core principles of Scrum.
- Having good visuals to make it attractive.
- A final invitation to read the official Scrum Guide for those who wanted more detailed information.
The result is a ten slide presentation that you can download then use as a powerpoint by clicking on the button below. Images are also available so you can use another presentation tool. It is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License (commercial usage & sharing allowed & encouraged). Feedback & suggestions welcome in the comments of this post.
Here are the slides:
Breaking the build is highly prejudicial to the productivity of a development team. Since it's pretty easy to avoid it by ensuring that the code compiles locally against the latest version and doing continuous integration, it is often taken as an act of rudeness. The person responsible for the act must therefore be punished.
Photo courtesy of seeb’s Photo Stream
The punishment often consists of making the guilty party wear a specific hat (we use a Sombrero) or any other very visible humiliating clothes, until they solve the problem themself. In addition to this, some teams may want to signal breaking builds with a specific sound played on speaker (we used a darth vader or homer simpson voice). Some teams get even more creative as you can see in this video.
I found the whole thing very funny and I always promoted it in every team I worked in to reinforce team spirit. That is until I met a couple of people who were really reluctant to join in and did not want to publicise their actions. Even when I broke the build on purpose to wear the hat, it did not change how they felt about it. One of them was from a different country where such humiliation could not be taken to this degree (as we can, I hope).
I think this kind of game is one of the many things we see online and we want to replicate without thinking, but it is not always a good idea. While it can be a very good team building feature, it can also contribute to making some team members very uncomfortable.
If you really want to do it as the manager/team leader, ask every one in the team individually. Asking in front of others will prevent you from getting honest feedback. In fact, it's usually better not to implement such a rule in your team unless it's really something everybody wants.
Here a "light" Agile Software Development checklist that I have used for many years to introduce Agile in organization. I usually introduce few items per week.
- A product Backlog, estimated and prioritized by a "Product Owner" is used
- A "Release Plan" exists and is known by the team
- A "Company Strategy" exists and is known by the team
- Features are divided into "User Stories"
- The "User Stories" are estimated by the whole team using "Planning Poker"
- The development work is divided into iterations or timeboxed "Sprints" or “Iterations”
- A "kanban" or "Information Radiator" is used
- The tasks are not assigned, the team organizes itself
- The "Velocity" of the team is known
- No outsider can interfere directly with the team during an iteration
- "Daily Meetings" take place and do not last more than 10 minutes
- A "Sprint Review" is organized and the output recorded
- A demonstration is held at the end of each iteration
- The problems are tracked and by the "Scrum Master" and/or management
- A "Burndown" graph is updated daily
- The "Code Reviews" are systematically organized
Development Tools & Rules
- A source controller is in place
- A continuous integration build server is used and testing (unit & guidelines) takes place at each commit
- The packaging of the product is fully automated
- A (simple) bug management tool is used
- Each bug is reproduced in a single test and then corrected
- 80% of the code is covered by automated testing
- A "Solution Log" in WIKI form is used
- The "Coding Guidelines" are defined and understood by all
- A maximum of 40 work hours per week!
Please note that any numbers above can be adjusted to your reality.