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:

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