20% DISCOUNT ON ALL OUR COURSES 14 hours 50 minutes 22 seconds Use coupon code: BlackFriday on checkout

Guidelines for Common sense ☺

Guidelines for Common sense ☺

Written by SPC Sachin Dhaygude

Recently in retrospectives of one of the scrum teams, one team member had some strong opinions about guidelines that were defined for code reviews. Besides what to review and how to review, the guidelines also had some instructions on who should review which features / stories’ code. He strongly felt that the reviewers for his stories didn’t add much value, the code reviews waited longer for feedback, the reviewer didn’t seem to have much context, so didn’t add much value. He felt that his design reviewers or his colleagues working on the same story should have been the peer reviewers!
I am sure anyone all will have following questions –
  1. Who stopped him from going to his design reviewer and his colleagues, who he thought, were better reviewers?
  2. Guidelines are just “guide” “lines”, isn’t it? They are not expected to constrain us, right?
  3. Should I crib about the defined process in a retrospective or should I instead, showcase myself as an example, who follows the spirit and intent of the process?
  4. And then, am I really self-organized, when I like my freedom as a developer? ☺
Also, let’s see why first of all we needed the guidelines. When you have a team of 70-80 people working on the same release, in absence of any guidelines, following happens (past experience of all of us)
  1. Some people are frustrated since anybody and everybody comes to them for reviews. Some people, hardly get any reviews!
  2. Somebody reviews just the basic syntax etc. While somebody reviews implementation of functionality, best use of design patterns, clean code practices, etc. So, there is no consistency between 2 reviews.
  3. When you say that reviews should “add value”, what does it mean to you vis-à-vis me?
  4. When you give a feedback on such superficial reviews, some people claim that “well, I didn’t know that we expected all of this to be covered in reviews!”
  5. Reviews will wait, so timely check-ins don’t happen, and that’s waste! So, how soon a review feedback should be received, needs to be defined.
So, in absence of any guidelines, there can be chaos, lack of shared understanding, lack of consistency. However, guidelines are only intended to be just “guide” “lines” (मार्गदर्शक) and not rule books (“नियम”)!
However, with formal guidelines in place, some people somehow start thinking that “this is what I have to do”! And they almost stop thinking and follow the law! Although, that’s just “human thing”, but then, having or not having guidelines, either ways there is a problem ☺
Intent of any “guidelines” is just to show us a “way”, define some structure. They are not supposed to be rigid or “cast in stone”. Intent of reviews is seeking a “valuable” feedback from another pair of eyes. An individual need not get blindfolded by defined rituals. And nothing can replace individuals and their close interactions!
In the retrospective, if the same individual had said that he worked with certain person, even though not defined in guidelines, to get a valuable reviews done, then it would have been a much more enriching “reflection” on what we learnt from last 10 days and how we avoided some waste, right? Team also would have taken away some “positive energy” from it, rather than just a negative crib, right? ☺
As a whole team, let’s have another look at the very first line of an agile manifesto, which says that while processes and guidelines are important, we should always value individuals and their close interactions more!
It’s just common sense! And yet, can you write a “common sense” also as a “guideline”? ☺

No Comments

Give a comment

4 × 4 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Skip to content
%d bloggers like this: