Fight daily meeting drudgery!
I have noticed over the years in daily stand up meetings that there seems to be two common forms of answer to the standard Scrum questions:
- What did you do yesterday?
- What are you doing today?
- Are you blocked by anything?
The first type is the concise answer which is in my mind the ideal answer, one that provides the necessary information in the minimum amount of time without any excess fluff.
The other type is the rambling answer that attempts to contextualise itself but really just drowns in excess information. I have even witnessed people using the questions as a chance to rant at their (effectively) captive audience or as a chance to start discussion. Discussion is a good thing but not during a daily stand-up with the whole team listening into to a few individuals discuss something, that gets old fast. Have your discussion after the meeting to spare those that are not required.
These two different styles of answers can make or break the scrum experience for the participants: too many ramblers in a stand-up meeting can make the daily meetings feel like a sentence instead of a chance to find out what everyone else is doing. The purpose of these daily stand-up meetings is to: update the rest of your team on your state: what you did yesterday, what you are working on today and any work blocking issues you are experiencing.
The goal is team wide visibility into the state of development and the corner stone of it is quick efficient short daily meetings. So keep those answers as concise as possible, this will require thought on your part to compose your answers before its your turn but your co-workers will appreciate it!
You Aren’t Gonna Need It!
A very common trap to fall into while implementing a new system or feature is to add functionality to ‘future proof’ your code for a use case that you imagine in may be required in the future. The future for the purposes of this post is any time that is not in your current development iteration.
This may seem harmless but consider that the future use cases you are imagining are not something you fully understand yet: as most of us will admit we are pretty bad at anticipating the future. So how can we hope to implement future functionality successfully? The most likely outcome is that whatever you implement now not be sufficient when you actually try to use it in the future. This will mean more time will have to be invested in the future to refactor or replace the functionality with what is actually required.
Unless you also plan to implement a full set of tests for this new functionality then you are adding extra code to your program that will not be correct and will not stay correct. This can also lead to really weird run time behavior if the flow of program execution goes into your new ‘future proof’ functionality unexpectedly: which can be very hard to debug. Adding functionality for future use without corresponding tests also means that as the rest of your program evolves the future functionality does not evolve with it, this means by the time you actually try to use it that it is most likely hopelessly out of sync with the rest of the code base.
The future functionality is also expanding the size of the source code of your program which leads to unnecessary code bloat. In some compiled languages (e.g. C++) code bloat will lead to increased memory usage and decreased program performance which is highly undesirable.
Another thing to consider from a business stand point is that you are spending time and money implementing future functionality when you are not being paid for it. This is a strong indication to me that implementing future functionality makes little business sense. As it means spending money now paying developers to implement functionality that you can’t sell right now.
There is a handy acronym for this: it is YAGNI which stands for ‘You Aren’t Gonna Need It’. The essence of this concept is to only implement the functionality you need right now and to implement in as simple and robust a fashion as possible. As simple robust code (preferable with acompaning unit tests) is code that can be easily refactored in the future to meet future needs and that is cost effcient!











