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:

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