General

When Not To Use Scrum?

Without a doubt, Scrum is my preferred vehicle in the world of software development journey. However, there are situations where Scrum may not produce the best possible results.

In order to get best out of Scrum, you must understand and continue expanding your understanding about the situations when something other than Scrum might produce better results.

In the moment of choice, you need to choose the right thing for the organization you’re serving. That’s what remarkable Scrum advocates do.

Here are some of the situations where Something else but Scrum could be a good choice:

  1. Either top-management does not believe in Scrum and does not want to believe in Scrum.
  2. Using Scrum does not make sense for the 3-5 years of organizations goals. Scrum implementation has an initial high cost which is not practical for a business to bear.
  3. When the “schedule” of the work is more or less fixed, driven by competition and cost of changing it is very high versus cost of losing sustainable pace.
  4. Performance appraisals are based on individual “heroic” contributions rather than team contributions.
  5. Teams are made of people who are level 1 or level to according to Maslow’s need theory.
  6. People don’t always respect other team members especially when they have difference of opinions.
  7. Business needs their people to work on multiple projects at the same time.
  8. People work for long, stretched hours because of business needs or individual skill issues. They spend most of their time in the office with inferior output. They crib about it and consider organization the culprit.
  9. People want to work in their comfort zone and like to be micro managed or they have been micro managed for long and they have got habituated to it. (It can change for sure but the cost of changing that mind-set may be too high).
  10. It does not make business sense to focus on “less” given the domain, competition, market conditions and/or business purposes.
  11. Having a fancy job-title matters to the key people and cost of making such people uncomfortable is way high than the possible benefits Scrum may provide.
  12. Product Owner role is assumed amongst many team members – Engineers often talk about “what” is the right thing to do more rather than “how” to get it done. Organization thinks it is okay.
  13. Some people think Scrum is a methodology, some think it is a project management framework, some think that they are doing scrum when they are doing daily scrum meetings or creating product backlog.
  14. Any of what is mentioned in this enlightening, Scrum-crazy post is true.

I can go on and on but key is to understand that Scrum can be successful only when the top management sees value in it, it is aligned with organization’s purpose the organization can afford to sacrifice short-term benefits offered by other systems in favor of the greater good that Scrum may provide.

It is important to understand that Scrum is not a single point answer to everything. It’s a vehicle, not the destination.

The Most Important Trait of an Effective ScrumMaster

When it comes about being an effective ScrumMaster, I often give an example of orchestra. I conclude by saying, “If even one team member is out of sync, the produced software feature might be out-of-order. That’s an impediment the ScrumMaster must remove.”

(If you want to read about the orchestra example, please have a look at my ScrumAlliance Article and read point #6.)

A couple of days ago, I got an interesting counter argument on my above mention.

The argument was: The ScrumMaster herself may not have required skills to bring the team member back in sync so she needs to empower the team and otherwise it may take more time etc.

My point of view: ScrumMaster does not have required technical skills? So What?

The Most Important Trait of an Effective ScrumMaster

Sure, the ScrumMaster may not have all the required skills to solve the problem but the most important trait of an effective ScrumMaster is to lead without a title and cause the right change.

ScrumMaster would have many impediments to deal with. Not enough technical skills…not enough authority…no access to needed resources. ScrumMaster would have tons of constraints.

Nonetheless, the ScrumMaster needs to presume the responsibility of the situation and influence respective persons to make things happen.

For example, consider this impediment: Because of a system failure, payroll will be processed 4 days later and hence salaries would be delayed by 4 days. A key team member has house loan installment to pay. Since the key team member is stressed fearing what will happen if he would miss the installment date, he’s not able to concentrate. Now in this situation, ScrumMaster has almost no expertise or authority to resolve the problem with Payroll department.

Regardless, the ScrumMaster may choose to communicate with respective persons and figure out the alternative ways by which the key team member’s loan installment issue can be resolved. Whenever anything is going wrong with the team members – either directly related with work or otherwise – ScrumMaster has to take the right actions and help the team member to focus on the work the team member has committed.

Obviously there could be more than one way to solve this problem but the bottom line remains the same – The ScrumMaster has to facilitate the team, remove the impediments and help the team focus to carry out the work they have committed.

That’s what effective ScrumMasters choose to do. They do it by presuming the responsibility and causing the right actions. Their ways may vary, though.