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:

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