The Scrum Framework is often represented as being very complex, but in reality it is very simple. In many ways, this illusion of complexity is perpetuated by people who understand parts of the framework but not all of it. Things get complex when an organization tries to make Scrum work without embracing it in its entirety. With just one exception (which will be discussed in Appendix A), trying to implement only selective parts of Scrum simply does not work. Doing so makes things worse than they were before.

There are many organizations that try to modify Scrum to “fit the way things are done around here.” Those organizations tend to see Scrum as a “methodology” as opposed to being the framework that it is. A methodology is a way of doing things and a framework is a way of organizing things. Organizations who try to “do” Scrum without trying to organize things properly inevitably fail, sometimes with terrible results.

Two of Scrum’s components—the Scrum artifacts and the Scrum events—are relatively easy to implement. The idea of a Product Backlog is easy to grasp because it is simply a prioritized list of things for the developers to do. The Sprint Backlog is equally easy to understand. The five Scrum events are easy to comprehend and stage. Most “Scrum in name only” (SINO) organizations use some or all of these tools.

The one part of the Scrum Framework that is only rarely implemented is the most important one by far. Scrum is a framework that organizes things. Above all it organizes people. If an entity tries to use the Scrum artifacts and Scrum events in a traditional top-down organizational model, it simply will not work.

At its heart, the Scrum Framework describes a team of talented people that works together to create value. One team member is responsible for figuring out what kind of product the team should try to create. Another is responsible for making sure the team can work together as a team. The rest of the team figures out how to create that product, then does so. It is as simple as that.

When people are organized into this kind of “self-organizing, cross-functional” team, the Scrum artifacts and events make sense. These tools are specially designed to help self-organizing, cross-functional teams manage themselves and their work. Teams using these tools can and do achieve great things.

Cross-functionality means a team has the ability to create the product with no dependencies on outside resources. Eliminating the possibility of dependencies reduces “friction” so much that many improvements in throughput are common. Unfortunately, many SINO organizations try to overlay Scrum on top of existing team structures, which—most likely—are not cross-functional. The resulting dependency-related issues choke off the possibility of getting much done.

Self-organization means the team takes ownership of delivering results rather than performing tasks. It focuses on solving problems. Usually these smart people get very good at doing so and come up with new and innovative ways of addressing issues in the Product Backlog. Unfortunately, many SINO organizations continue to use centralized decision-making methods to “tell people what to do and how to do it.” As they say, “A mind is a terrible thing to waste.” Such top-down methods waste the creativity and intelligence of the people actually doing the work. The results are that tasks get completed but problems do not necessarily get solved.

Self-organizing, cross-functional teams seem to be a difficult pill for many organizations to swallow. Likewise, delegating authority to a single person to decide the future of a product is also a stretch.

The essential word here is trust. The Scrum Team has to work as a team on the basis of mutual respect and trust. The Scrum Team and its parent organization also have to work together on the basis of mutual respect and trust.

The parent organization should give its Scrum Teams the environment and support they need. The teams should be trusted to get the job done.

In return, the Scrum Teams must deliver the value the parent organization wants and needs.

This value must be measurable and must be measured. It must be compared to the costs of the team to calculate the return on the parent organization’s investment. Ultimately, the ROI of a team is the only real measure of its success.

Doesn’t that sound simple?