Vukoje's blog about software development

Earliest Feedback and Sanity Checks

When two men in business always agree, one of them is unnecessary. ~William Wrigley Jr. 

This is another post dedicated to team communication. In previous posts I have already stated that communication is important and that two people are more likely to solve problems. Today I will talk about importance of early feedback, and regular developer sanity checks.


Earliest Feedback


In every agile development early customer feedback is very important. Today I will talk about even earlier feedback… I mean feedback from your team members. This is earliest feedback you can get and maybe most important, because often this is only technical feedback you can have.  If you are building some API or planning some architecture, than at that point other programmers are your customers as your API users.

The question is why is this feedback needed any way? Thes because variations, combination and potential code usage scenarios are uncountable. Ok, maybe they can be counted, but rest assure that when the time comes, you will not have them all in you head. One more thing we want to avoid with this is over-engineering.

So tell your ides to your teammates and ask them for opinion. If you do this, you will often hear the phrase "The problem with that is...". And there it is, one future gotcha you have just avoided.

In the past I was annoyed with this feedback that was constantly proving my "super" ideas wrong, but today I cherish them as a proven strength of positive critics. Always give, cherish and encourage positive critics in your team.

Another way to look at this early feedback is as early WTF?!. Instead of living some other developer  thinking many WTF!? while trying to understand your code, you cam tell your ides and wait to here WTF!?.


Sanity Checks


Programmers, as pure technicians, tend to lose focus to business value and end goal of software they are building. Once they dive deep in to code they can forget customer needs, deadlines, weak plans, planned designs… heck we will forget our friends and families. You can say that, from business perspective, developer have gone mad and this is why regular sanity checks are very important.

This is exactly why in Scrum you need Scrum Master whose main role will be “sanity checker” (team conscience) who will be checking developer sanity on daily scrum meetings. On these meetings every developer answers 3 questions:

  1. What have he done from last meeting?
  2. What will he be doing until next meeting?
  3. Does he have any problems with his work?

After everyone has answered these 3 questions, whole team should be informed about each other’s work but also it should be obvious if someone have gone insane. For example, developer could answer that he has not been doing what was planned and has started to build his own parsing tool in some experimental technology that will be supper cool.

After this madness is discovered, everything is easy. Scrum Master asks simple question: “Why?” and keeps repeating it until developer realizes his mistake. This is known as 5 Whys technique.

Do your team sanity checks and check yourself daily. Focused team, building minimum that customer required can do amazing things, so go and be amazing.

Presentation - Coding Standard and Code Review

Last night I have held presentation about Coding Standard and Code Review at Microsoft Serbia quarters in Belgrade. This was resumption of previous presentation on Code Refactoring. In amazing 3 hours I have managed to break every record (rule) regarding presentation length, so I want to thank all of you who came and survived. I know it was hard but I can only hope that it was useful.

For all of you who are interested in these subjects but couldn’t make it, I will be holding these two presentations in November at Sinergija.

You can download presentation here or browse it online here, and see photographs here.

Here are some useful links:

... And here are some funny links