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:

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