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:

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