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:

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