There is no such thing as a scrum development team....

Yeah, I know that's a heck of a clickbait title, but it's also the thesis of this blog post.

According to the Scrum Guide (2016):

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;

• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,

• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Five rules. Absolutes stated clearly. For two of them "there are no exceptions to this rule."

Just for fun, look through all five statements. Tell me how many scrum teams you know of personally for which all five of these are absolutely true.

Self-organizing: 

No one is allowed to tell the team to refactor or not to refactor, to test or not to test, whether they can mob or pair, whether they have individual assignments or not. Nobody can force them to pair or mob or TDD if they don't choose to. They control their own means and methods. Scrum doesn't tell them how (which has been a historic criticism of scrum, compared to XP which requires strong practices).

Most common failure modes:

• Management, or the management tool, requires that work is assigned to individuals
• PO or SM or "development lead" or "tech lead" (see 'no titles') often tell the team that they can't refactor, test, mob, pair
• The HR system requires that work is tracked to individuals (else how can annual reviews be conducted? How do you separate overperformers from underperformers?)

Cross-functional:

Every skill needed to produce the code is on the team, and no work is done by people not on the team ("Only members of the Development Team create the Increment.")

Failure modes:

• Separate test teams
• Separate ops teams
• Separate PO organization
• Separate component teams
• Separate UX team or specialist
• Architects review work by all teams before it can be released
• DBAs are not on the team, but have to be involved with all data changes

No Titles: NO EXCEPTIONS.

Other than scrum master and product owner, there are no titles other than developer.

Failure modes:

• Sr/Junior separation (career path involves title and compensation)
• Lead developers
• Delivery Lead
• Test Lead
• Tester/Developer/UX/DB subteams have titles (see "no subteams").

No Sub Teams: NO EXCEPTIONS

There is one team, "regardless of particular domains that need to be addressed."

Failure modes:

• See the teams called out in "cross-functional" above, especially component teams.
• There is often a separate devops group for deploying and managing the application.
• The requirements come from a separate subteam which is not incorporated into the team, but is an external entity (a separate team) who decides what should be built.

Teams Are Atomic:

"Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole."

In other words, work and accountability are pooled and the team is one atomic unit. The world outside the team does not deal with the team as individuals or ask the team to operate as a team of associated individuals. Instead "the team" is assigned work, and "the team" completes it, or "the team" is held responsible for it. The team does not throw members under the bus to avoid blame.

Failure Modes:

• Assignment of work to individuals by manager, PO, or SM.
• Disallowing pairing/mobbing (see first rule)
• Requiring specific technical practices
• Comparing individuals within the same team
• Tracking work to individuals
• Individuals reporting status at standup
• Individuals "waiting on each other" reported to managers
• Managers asking individuals how "their work" is going
• External agents (managers usually) citing and rewarding individual contribution
• Force-ranking team members

Does It Matter? 

There are 5 absolutely-worded qualities here, and "development teams have the following characteristics" so clearly if those five are missing, then by definition it's not a scrum team. 

Of course, the scrum guide (2016 and prior) says: 

Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Either these are things that together cannot be done (in which case scrum is a sham) or else these things are not being done (in which case the organization responsible for teaching and transitioning is failing miserably).  

Is there a another option? 

• Possibly scrum doesn't really mean it in which scrum really is a sham. 
• Perhaps people don't know how,  in which case the scrum organization is a failure (despite the monies collected, the number of organizations "adopting,"  and the number of persons certified). In this case, I suggest the certification money is being wasted.
• Perhaps some people can do these, but most corporations cannot. Okay, then, say that scrum can't work in corporations. Then why are we seeing corporate "adoptions" listed as successes, and so many organizations accepting the money to "install" (ew) or "transition" companies in which scrum cannot work? 

So, scrum is an evil money-making scheme with no goal other than lining the pockets of trainers and coaches? 

No. At least one more possibility exists that isn't mentioned in the Does It Matter section. 

Perhaps we are looking at transition, and seeing state. 

This sound reasonable to me. I don't think all scrum coaches and trainers are scam artists. I know a lot of them and they're pretty decent people trying to make a difference in a complicated and chaotic world.

There aren't many corporate scrum teams yet.  

The five qualities of a scrum team listed above are completely out of bounds for traditional organizations where the management teams work in a very industrial-age way, and the HR systems are more appropriate to mechanical workers than to knowledge workers. The system as described requires more permission, trust, and safety than they know how to give (so far). Their world has not yet climbed the Satir Change Curve, and so we're seeing them all in "chaos" and not in "new status quo."

It is hard -- potentially impossible --  to reach the described state of grace using scrum alone. 

I think that the thing missing, and necessary for corporate teams is that set of values known as Modern Agile. The organization must reorient to focus on safety, alignment with the success of others, continuous learning, and continuous delivery.

These are similar to the values we find in XP, and maybe one of the reasons that "hyper-productive scrum teams" are teams that actually use XP practices.

I think that this goes past practices, though. It goes to a mindset of permission, trust, and safety that most large organizations find extremely uncomfortable.

Some even suggest that those values cannot work in a large company, or that the people who propose the values don't really mean it.  With regard to scrum, they assume the parts that involve human relationship are entirely optional and replaceable with "known good" command and control techniques. This is false. The values are crucial and irreplaceable. 

Without going to the Modern Agile values, I don't know that organizations will be able to ever have real scrum teams. 

By focusing on Modern Agile values, though, I think any organization can easily surpass the level to which expertly-led scrum can take them. We'll see.