Over a million developers have joined DZone.

Understanding Scrum

DZone's Guide to

Understanding Scrum

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

Even though Scrum has touched souls of most of the software developers across the globe, it still seems to be understood as set of practices.  There are many yet to catch up with the principles behind the Scrum.   In the recent blog, Ken Schwaber  reviews the typical mistakes done by most of the Agilists and specifically large organizations. 


Here is the summary of  key points from his blog post with my 2 cents added in between.  Ken’s comments are in Italics.

1. Our tendency and tooling from waterfall and predictive processes is to view people as assignable, parsed, optimized resources. This works great if you are running a factory line and people are doing simple work. It really sucks if you are trying to do creative, complex work where there are many competing ideas and solutions emerge from interactions.

Even now I have seen many people using the word “resources”  to mean mostly the “developers and testers”.  Even worst, they are also called many times as “heads” or “bodies”.   This is not only demeaning and disrespecting the people around us, but also shows the lack of seriousness about the knowledge workers.

2. People don’t have measurable capacities when they are performing intellectual, creative work. Things move back and forth between different parts of the brain and some of the best ideas come at 2:00am in bed

This is a radical thought process isn’t it ?   All of us work from 9 to 7 PM shift, and we have to think and complete our work in this duration. It is easy for every one around us to be predictive and work in the same time zone. In reality,  this is not possible.  However, the stress, which reduces creativity can be minimized by removing many of the enforcement on the employees at work.

3. Last, but I’m sure I’ve missed others, is the idea of “assigned” work. This is a common smell of a development team that is not self-managing. Who “assigns” work if a development team is self-organizing? Development teams select work, figure out how to do it, and go do it. Assignments are a dysfunction.

Most of the issues like “assigning the tasks”,  “Architects doing the estimation on behalf of every one”,  “Project Manager approving leaves”  are the vestiges from the Waterfall era.  It is always better to coach and train the people in the top before it affects the bottom.  As the phrase goes “Fish always rots from the head down”.

You can read the entire article here.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}