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:

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