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:

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