Regretful practices of Scrum (Part 1)

Scrum is a framework where you can develop/manage your projects. In a typical framework, you can add, remove, modify different components to make is proper workable for you. So you can modify scrum concepts and can make is properly workable for you. There is nothing called "pure scrum". You need to find out a balance point between your needs and scrum which will be the best solution to accomplished/successfully drive your projects.

As an example, scrum don't have pair programming concept, XP has this one. But for the quality of code or for the training of Jr. Developers you can introduce pair programming model into your scrum-oriented organization. There must have an adjustable point on which you can drive your software projects.

So, how can I say "Violation of Scrum"? Does scrum really violates? Well, my answer is "obviously NO". But, sometimes peoples start doing valueless practices. From my little experience I tried to find out some pin points that should not apply in a scrum-oriented organization.

Micro-management: Micro-management is a habit of prior Waterfall-oriented managers. They like to come into the person and talk to the person level. Obviously there were teams. But team was less valued. In a scrum team, I have seen micro-management makes the environment misery. The team lead even didn't know what is going with the individual team members!!! Well, you can tell that they were not using scrum……. Exactly! But they were following pure scrum even there have certified ScrumMaster, Scrum Practitioners. Yes obviously everybody should be responsible but it should be at the team level. Team will decide who is performing well, who is not. Team lead will contact to the management as he is only the contact point with the management/PO.

Effectiveness of ScrumMaster: What is the role of a scrum master? As we know scrum master is the facilitator of a scrum team. S/he will be responsible for removing the impediments so that the team can perform well. Sometimes people tried to find out the effectiveness of a scrum master from their extra point of interest. They want to calculate using various matrix including Velocity, Quality in Production, Injection Rate, Health of Backlog, Ability to hold x% maintenance, Story completion rate etc. On the flip side, most, if not all, of these measures are not limited to the Scrum Master, but also the team. Some people think that the measurement can be

- Average time taken to resolve impediments

- Number of retrospective items auctioned

- Adherence to scrum guidelines

- Various scrum adoption survey results filled by the team

I think that this is again a situation of trying to measure the unmeasureable. I could start asking questions such as who measures that? When does the start time of resolving an impediment occur? When does the end time of resolving an impediment occur? And so on, but I'll go along with the spirit of the thing. It seems to me that the only ralistic way to measure such behavioral aspects is to ascertain the satisfaction level of the people whose activities are affected by the ScrumMasters' behavior. If people feel that the SM is resolving impediments promptly, and in a manner that is helpful, then they will indicate a high level of satisfaction.

Asking PO for the non business related issues: Suppose that the team needs programming training, or that the floors need cleaning. Are these things to be put into the Product Backlog and prioritized by the PO? Well, it may seem funny and you may ask me to use my common senseJ. Well, an interesting answer from Joseph Little is

"The Product Backlog has *all* the work the Team must do to complete the Product. If they really should have training, then in it goes. (If someone else will clean the floor, then that does not go in the PB.) Final decision-maker: The PO is only the final decision-maker. It was always true that for some things, that one real person often will not have all the info or expertise. The PO is supposed to understand that and get advice. And the Team is supposed to understand that and offer advice. STILL...ultimately it is a "business decision" where to invest the money (that pays for the Team). And that has to be balanced against all the other competing claims for that money." So asking PO about the priority of cleaning the floor is just a waste of time, as someone else the team will clean the floor.

Extending Sprint length frequently: Here's a scenario: It's late in the third week of a four-week sprint. It has been plugging along, making good progress against the user stories (new features and enhancements to a web product), and now the team focused on testing in the QA environment, and logging defects. A lot of defects! After a couple of days of testing, it is up over 100 -- more than we can probably fix before sprint's end.
What's the best thing to do at that point in terms of the Scrum process? Options that can think of include:
- extending the sprint to complete testing and fix all the critical bugs, then deploy
- completing the sprint without any deployment, rolling the bug fixes over to the next sprint, and continuing
- focusing our efforts on fixing a subset of the stories in order to deploy them, then roll the remaining stories over to the next sprint.

Well many people at the end try to extend the length of sprint. Extending the sprint creates a precedent that can be used again. Sprints should have fixed length. Completing the sprint without deployment is more like not completing the sprint. Let the team fail and help them have a healthy debate on the retrospective.