Scrum By Arguments

There was a time that everybody was raving about Scrum. Nowadays I see a lot of rants against Scrum. This seems to me fundamentally (pun intended) the wrong way to have a meaningful debate about Scrum. To Scrum or not to Scrum should not be the question. There is a lot of good and a lot of bad in Scrum. I set up this repo in order to gather some the PRO's and CONs of some of the rules of Scrum.

This is a starting point. Perhaps it will grow over time, perhaps not.

Scrum

PRO:

• It is nice to have a method from which to pick and choose ideas from.
• When setting up a team it can be a great method to start with.
• For the kinds of project done today it tends to be much better suited than the old ways.

CON:

• Some do not want to pick and choose, but just want to follow a prescribed method. This can result in bureaucracy, unnecessary ceremony and stress, clashing ego and conflict of interest.

Sprint Meetings:

PRO:

• Coming together will all members of the team regularly helps unify and synchronize. It might be a good time to discuss some things that are important.

CON:

• Everybody in the team needs to be present.
  • Nothing can be discussed in depth, since not all stakeholders have the same depth of understanding.
  • Of limited interest to everybody except those who are at the center of all things.
  • Hard to reschedule, because of intersection of agendas.
• Too rigidly held. Every two weeks might be too many or too little meetings. Again, hard to reschedule, because of intersections.

Sprints:

PRO:

• Working towards small goals provides on a short time schedule provides a lot more achievement than working large ones on a long time scale. Smaller achievements put together produce more feeling of success than one big achievement, a.k.a. the less-is-better effect.
• Working towards small goals makes it easier to manage that everybody is working towards the same goal then working towards large goals.
• Could be used to synchronize with a regular release schedule (if you want one).

CON:

• Changing the plan during the sprint is:
  • Typically not appreciated, because work has been spent planning ahead based on the old plan.
  • Hard, because consensus needs to be reached again, everybody updated, the backlog changed, stories updated, points assigned and further commitment recalculated.
  • Might, because of the above reasons, be avoided or postponed until the next sprint meeting, while it would have been better to change the direction immediately.
• Quality often falters at the end of the sprint to get something demoable and in order to fulfill the (artificial) commitment made at the beginning of the sprint.
• Stories about refactorings that are needed after pushing for a sprint are hardly ever planned and it is very hard to non-technical stakeholders understand why such 'stories' are needed.
  • Sometimes agreements are made that some percentage of the sprint may be used for purely technical stories. These percentages are usually arbitrary, either too much or too little, but almost never right.
• The term sprint is terrible as nobody wants to spend their life sprinting.
  • Even if the term is just a term it still carries a very wrong connotation.
  • Creating artificial deadlines (usually there are no customer demands that need to be met every two weeks) every two weeks is unnecessarily stressful. Programmers provably perform worse under stress.
  • Even when you know the deadline is artificial the deadline will influence those who want to be known as performers (a lot of people).
  • When a real deadline occurs people might be less inclined to fulfill it.

Points + Velocity:

PRO:

• When working with a reasonable stable team provides, when done properly, constantly improving time estimates.
• Sometimes by seeing somebody else's estimates it becomes clear that there is a big difference in what the other thinks the work entails.

CON:

• There are other more direct ways of unearthing what people think the work entails.
• A continuous stream of estimates is hardly ever needed. A lot of time is spent on estimating things that do not need estimation.
• Velocity is a measure that applies to a group of people. There is no way of re-determining the velocity when that group changes.
• Personal velocity can be a rather arbitrary stick with which to beat somebody. Scrum does not prescribe this, but it is done.
• Estimation will always be more of an art than a science. Discussions about estimates are often futile.
• Providing commitment on the basis of estimates leads to regular failure. Failures feel bad, even when it is a failure to meet an artificial deadline.

Roles:

PRO:

• It is nice to know who is responsible for what, so people are able to focus on their own responsibilities. That is fundamental to good team work.
• The role of product owner is really helpful, because it is so different from programming that it is usually best to assign this to someone who is well suited for this job.
• The role of scrum master is sometimes helpful, because people tend to forget or misinterpret the process, so that it is useful that there is someone who takes care everything is going as described.

CON:

• Roles are too rigid:
  • The roles are predefined. Roles that do no exist, but could be useful in a certain context can not be invented.
  • Roles are typically assigned to certain people. Some roles could sometimes better be shared responsibilities.
• A scrum master should ideally not have to do anything special. Ideally no translator between programmers and non-programmers is needed, no person needs to police whether the process is maintained, impediments and changes in the process are a shared responsibility and leadership is provided naturally by those who are more known to make better decisions.
• The term "master" is as bad as the term "sprint". One does not become a "master" in a few days training. The scrum master could be anybody in the team and does not need the title "master".