Criticizing SCRUM Constructively!
Constructive criticism by definition means the process in which valid and well-reasoned opinions are offered which are backed by rational thinking, usually involving both positive and negative comments, in a decision oriented manner to improve the process or outcome as a whole without any bias.
We all know the power of scrum and agile development; if it is implemented and executed with certain tweaks then it can do wonders for the product and team working on it. As far as I understand scrum; it can be divided into 6 steps explained below.
1 — Creation of Product Backlog by Product Owner
Product Backlog is created by product owner to list out all the new tasks/ stories and divide them into groups according to their priority level.
2 — Couple of Grooming Sessions
In grooming, task/ story details are discussed with the entire team and divided into sub-tasks. This step is very important because in this step entire team becomes familiar with the story requirement and expectation. Ideally story should be broken down into sub-tasks as small as possible. Product owner should try to be as specific as possible about the requirements.
3 — Assigning story points and locking sprint stories
This is the step where most of the errors occur. In this step entire team sits together and decides the story points based on it’s complexity and effort required to finish that story. Team has to decide and lock the stories which they will pick up in current sprint. Some teams overestimate (this is acceptable to some extent); while most of the teams underestimate (this is not acceptable at all)!
4 — Implementation planning of sprint
After selecting all the stories which have to be picked up in current sprint; it is important to plan and jot down the story deadline on a sprint calendar. It is very important to plan a sprint in such a way that everybody gets ample amount of time and a bit of buffer (for unexplainable set of time consuming events which may occur) for each and every story assigned to them.
5 — Daily scrum calls
After the sprint starts; it is very important to keep track of all the stories. Individual assignees should report entire team about daily targets and status of current story. Scrum master should act as a facilitator (rather than a dictator) making sure that sprint progresses smoothly.
6 — Retrospective meeting
After the end of the sprint; team again sits together and jots down all the positives and negatives of the concluded sprint. All the stories should be carefully reviewed in this meeting. There will be some areas where the team can improve upon; all these areas should be identified and an actionable plan should be carried out to avoid repeating same mistakes in next sprint.
On paper, above points gives a very solid and neat impression. But to be honest, implementing scrum can be quiet challenging sometimes.
Inspite of all the timely meetings and thorough plannings there are some concerns, inherent flaws and mistakes often committed which I would like to point out.
1 — Pressure to over-commit in sprint planning
An individual team member should not be pressurized directly or indirectly to over-commit. Everyone has his/her own limit. Scrum masters and product owners should adopt a balanced approach in which proper freedom should be given to team members to pick stories of their choice. Only that Developer should assess what he/she can accomplish in the upcoming Sprint. Undoubtedly, there should always be some kind of regulation or minimum points which he/she has to pick but no one should be forced to stretch. Whenever this thing happens; it will directly impact the mindset of team members. It will indirectly attractresentment, inefficiency and low quality work in long run.
2 — Working on interdependent stories
Sometimes different teams work on same set of modules. This results in utter chaos in most cases if there is an absence of proper documentation and planning. It has been observed frequently that in such cases defects/bugs are dodged from one team to another team and it creates ownership issues. Every team member will say that it’s not his/her bug and nobody will fix it. Ultimately the one who worked most recently will be unanimously chosen as scapegoat and he/she will have to fix that bug. Well, fixing bug is not a problem here and it will result in a better product eventually, but this unplanned work will affect the sprint performance of the scapegoat and his/her stories will spill or will eventually take a hit on quality aspects also. So, this situation should be avoided. In some extreme cases if it’s unavoidable then it’s better to spill a story then to push half-baked code to production.
3 — Unavoidable interruptions
Some teams work very closely with customers and production support teams, in such scenarios there can be unplanned interruptions in terms of client requests and production support issues. These issues are of high priority and can’t be dodged on to next sprint. Such teams should plan sprints defensively keeping in mind the average number of support requests they receive per day/ per week/ or per sprint (choose whatever metric you are comfortable with). All the issues/ requests should be properly examined and it’s priority should be cross checked with product owner. A proper demarcation should be made between issues and feature requests and should be dealt with accordingly.
4 — Degradation of quality
In scrum environment, there is high pressure of release cycles on each and every team. Everyone counts points (if not everyone; most of them ); this sometimes pushes teams to deploy unoptimized and potentially breakable code to production. This will result in production defects and bugs; which will again have to be tracked by some defect logging system and will have to be fixed on high priority. Nobody will realize that it will affect current sprint and this is a never ending cycle. Deadlines are very important; that’s why sprint planning should be precise and concise without compromising on quality and coding standards.
5 — Check-points over shadows innovative solution
The strongest concern I’d pose here on Scrum is that we sometimes become excessively focused on checking the boxes to say that we are done with something, rather than being focused on finding innovative solutions to the problems which we were handed.
PS : I am not an expert on SCRUM and AGILE development; I am just another guy who can code a bit and slowly evolving to be better at it. These are just my personal observations; most of them which I have faced over the course of my short professional career. But frankly, yes, I am quite critical of SCRUM and above are my justifications for the same.
Happy Coding ( and happy sprinting!)
Originally published at www.jaydeeptrivedi.in on March 3, 2016.