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:

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