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:

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