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:

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