Should Scrum be "Optional" for some teams

Question

So there are 8/10 scrum teams in different locations in my company. there are 4/5 Scrum masters facilitating these teams.

One team in particular wishes to have no scrum master & ideally be left alone to "Do their own thing".

What are your thoughts?

• Is this a good thing?
• Should a scrum team be allowed to "Opt Out" of Scrum
• will this introduce a risk of Silo'd working
• Will it introduce a contagion that could jeopardise Scrum adoption in the company?

If you think its a bad idea ... how do you win them back?

• Carrot & Stick?
  • With an Iron Fist?
  • Or start again on encouraging Agile adoption?

Thanks in advance

Answer 1

One one hand SCRUM means that the teams are self-organizing and thus should largely be free to decide how they implement scrum.

One the other hand they are a team working on a project which is managed by someone else. The scope, priorities and time line expectations will always come from outside the team.

The best approach highly depends on what aspects of scrum they oppose and why they do so. People generally don't complain about having to use scrum/waterfall/v-model/whatever. They complain because of pathologies in the way their particular process is implemented. If they are merely opposed to the SM then this might be an indication that their SM is not treating them as he should (perhaps an ex PM clinging to his former authority?) Maybe the PO or the stakeholders don't honor the team's autonomy? There's probably some kind of interpersonal issue giving scrum a sour note. Speak to them, preferrably individually and learn why they are unhappy. Not with scrum - in general.

As a general answer I'd say that the use of scrum in it's most barebone structure (The existance of PO and SM roles, planning/scheduling through backlog items and short implementation cycles) is probably something you can present as prerequisite for continued employment.

Can they work in a fashion that allows the rest of the company operate under scrum?

Can they deliver value and quality on par with the other teams?

If so then they've arguably proven the validity of their scrum implementation. If not then they've demonstrated that changes(tm) need to be made. Until either conclusion can be drawn, scrum owes them that impediments are removed, be they technical or sociological.

Answer 2

TL:DR

• The team must be able to account for the value of the work they produce
• The team must be able to account for the effectiveness of the way they work
• The team must show readiness by demonstrating they can effectively inspect and adapt even when working alongside the other Scrum teams
• Ultimately, this is a business decision

---

Too often individuals or teams make their choice of ways of working based on personal preferences rather than what produces the highest value product balanced with a sustainable development pace.

IMHO, whether or not they are trusted to do their own thing comes down to an assessment of the readiness of the developers and business professionals to inspect and adapt the product they produce and the way they work together. Key to this is if they have an objective way to determine the value of their work and their ways of working. Without these diagnostics in place, I would be very hesitant to trust them just do their own thing; the effects of their experiment would be difficult to measure for success or failure.

Having said all that, this is ultimately a business decision. If the individuals wanting this new arrangement can be afforded latitude to work in a new way i.e. if the business is insulated from their potential failure then it may be the right decision for other reasons. Essentially, if the business is well enough off to sanction the experiment the team is wanting to run it may be a good idea to let them try. They and others may end up learning something very valuable.

Answer 3

I'm not an initiate of the Scrum religion, but it seems to me that Scrum should be a tool to help the company achieve business objectives. If your company's strategic business objectives include scrum, then the answer that every employee should work to support the corporate objectives or find a job where they can do so. In the more general case, if the business objectives don't include scrum, the answer is a bit more complicated. If the team can reliably produce on schedule, on budget, on quality, then don't fix the non-problem.

That said, I'd have a quick word with those employees and discuss the fact that they work on a project, and projects are by definition time limited. If they want to have a career in the company, if they want to have opportunities to get promoted, to grow, then they're going to eventually move to a scrum environment. if 90% of the company is scrum, then the future is pretty much inevitable and it is career suicide to pursue the past. The first moment that the team fails to deliver on time/on quality/on schedule, the pressure to fix what is now a problem will rise. The first time that they need surge support from another team, that surge support will come in the form of someone who expects to be part of a self-organizing team.

I'd also want to listen to why they reject scrum. I think there is an interesting irony in a team rejecting scrum in favor of organizing their own work. What is it about scrum that they cannot accept? Is it merely learning something new? (if so, I reverse my statement above - if the team doesn't want to learn, then get rid of them. There is no place in a modern company for an employee who doesn't want to learn) Is it that they reject the religious zealotry that accompanies scrum (anything but scrum is scrumbut!)? Is it that they don't mind scrum, but they dislike the way scrum is practiced and evangelized in the company? There are ample opportunities for compromise in that case.

Answer 4

Short answer: Using Scrum should be optional. Use what ever feels the best for the team.

BUT!

You have to make sure that the team is evolving. That is best done by a Scrum Master/Agile Coach. So start by asking if they would be ok with having a SM facilitate their team development. The SM will say if they feel that the team is good enough to be left on their own. Even if they are (which I HIGHLY doubt) they probably need an occasional check up on how they're doing and if they need some coaching.

Answer 5

Leaving a team to "Do Their Own Thing"

This is actually the best place to start this conversation. Software isn't developed for its own sake. It is also rarely developed in a vacuum. Therefor, a team must operate in a way to provides value to the customer frequently and also in a way where they can collaborate well with other teams and the rest of the organization. Teams should always be improving how they work and looking for better ways to create value in the organization.

Does it have to be Scrum?

No, absolutely not. In fact, sometimes Scrum is the wrong choice. Support centers are probably the easiest case to see. They are more about the flow of work and approaches like Kanban are better suited. However, even in other approaches, the focus is still on value delivery and constant improvement.

Do you need a Scrum Master or other type of team coach?

The simplest way to look at this is sports teams. Can a baseball team function without a coach? Sure. They'll be missing an important perspective and may have trouble making improvements that other teams would find easy with a coach, but they'll play the game.

Software teams are exactly the same. No Scrum Master or team coach will still get you working software. A part time coach will get you some improvement. But a full time Scrum Master or coach should pay for themselves in improvement many times over.

Getting Team Buy-in

A better way to ask this question is: Why should the team care? Why don't they now? If they aren't producing working software and no one calls them out on it, then why should they change. If the organization doesn't celebrate improvement, then why should they put the effort in? Alternately, if they are constantly improving and they are delivering value, maybe they've already solved the problem and the rest of the organization has something to learn from them.