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:

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