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:

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