Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Guidelines for Common sense ☺

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp
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, and 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 will have the 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, the 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 the implementation of functionality, best use of design patterns, clean code practices, etc. So, there is no consistency between the 2 reviews.
  3. When you say that reviews should “add value”, what does it mean to you vis-à-vis me?
  4. When you give 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 a waste! So, how soon review feedback should be received, needs to be defined.
So, in absence of any guidelines, there can be chaos, a 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 a “human thing”, then, having or not having guidelines, either way there is a problem ☺
The intent of any “guidelines” is just to show us a “way”, to define some structure. They are not supposed to be rigid or “cast in stone”. The intent of reviews is to seek “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 a certain person, even though not defined in guidelines, to get a valuable review done, then it would have been a much more enriching “reflection” on what we learned from last 10 days and how we avoided some waste, right? The 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”? ☺
Written by SPC Sachin Dhaygude
Subscribe for Email Updates:

Categories:

Tags:

Games and Exercises
RTE Role
Professional Scrum Product Owner
Value Streams
An Appreciative Retrospective
Scrum Primer
Engineering Practices
NIT
Jira
RSA
Managing Projects
Agile Basics
Iterative Incremental Development
Agile Techniques
Story Slicing
Jira Plans
Limiting Work in Progress
QA
Kanban Kickstart Example
Presentation
Nexus and SAFe
Scrum Guide
Lean-Agile Budgeting
Scrum Master
ART Success
GanttBan
Agile Community
Agile Project Management
Kanban Basics
Professional Scrum Master
Perfection Game
Managing Risk on Agile Projects
Lean and Agile Techniques
Principles of Lean-Agile Leadership
BDD
PI Objectives
Continuous Delivery
Elastic Leadership
Agile Outsourcing
Lean-Agile Software Development
The Kanban Method
Nexus Integration Team
Agile Product Development
Introduction to Test Driven Development
Coaching Agile Teams
LPM
chatgpt
agileisrael
Daily Scrum
RTE
PI Planning
Scrum.org
Implementation of Lean and Agile
Agile Assembly Architecture
Development Value Streams
Lean Risk Management
Kanban 101
Lean Software Development
Certified SAFe
Spotify
Acceptance Test-Driven Development
Portfolio for Jira
POPM
Systems Thinking
What Is Kanban
Professional Scrum with Kanban
Certification
Lean Agile
Kanban
Agile Marketing
Agile Israel
Program Increment
Scrum With Kanban
Sprint Planning
Agile Program
Continuous Improvement
AI
Test Driven Development
DevOps
Rapid RTC
WIP
Jira Cloud
Agile Development
EOS®
Jira admin
Agile Exercises
Release Train Engineer
AgileSparks
Planning
Agile Project
Nexus and Kanban
Lean Agile Leadership
Manage Budget Creation
SPC
Video
Scrum and XP
Pomodoro Technique
Quality Assurance
Operational Value Stream
Legacy Enterprise
Agility
lean agile change management
Effective Agile Retrospectives
System Integration Environments
SAFe Release Planning
Code
Slides
Software Development
Artificial Intelligence
Accelerate Value Delivery At Scale
Agile Release Planning
Software Development Estimation
Releases Using Lean
Implementing SAFe
TDD
Agile in the Enterprise
LAB
SA
Risk Management in Kanban
Agile Mindset
Agile Product Ownership
Lean and Agile Principles and Practices
Agile Games
Agile India
Large Scale Scrum
Covid19
Continuous Planning
System Team
Nexus
Agile and DevOps Journey
Scrum Values
Agile Games and Exercises
A Kanban System for Software Engineering
Sprint Iteration
Kaizen Workshop
Business Agility
Agile
Amdocs
Risk-aware Product Development
Introduction to ATDD
ARTs
Lean Budgeting
Legacy Code
Nexus vs SAFe
Scrum
Lean Agile Basics
Built-In Quality
System Archetypes
predictability
SAFe
Lean Startup
Change Management
Product Ownership
Process Improvement
Lean Agile Organization
speed @ scale
ATDD
User stories
Atlassian
Enterprise DevOps
Agile Release Management
Scrum Master Role
Atlaassian
ATDD vs. BDD
Achieve Business Agility
Continuous Deployment
Applying Agile Methodology
Webinar
speed at scale
LeSS
Tools
Agile Risk Management
Agile Contracts Best Practices
IT Operations
Agile for Embedded Systems
Agile Israel Events
Entrepreneurial Operating System®
Advanced Roadmaps
ALM Tools
Agile Testing Practices
Lean Agile Management
Kaizen
ROI
Tips
Risk Management on Agile Projects
The Agile Coach
Continuous Integration
Frameworks
Self-organization
AI Artificial Intelligence
Kanban Game
SAFe DevOps
Reading List
ScrumMaster Tales
Scaled Agile Framework
Agile Delivery
Product Management
Hybrid Work
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart