As stated earlier, the Scrum Framework is a way of organizing a product development effort so that it can solve complex adaptive problems.
Products are developed by people. One of the keys to the success of a product is the Scrum Framework’s way of organizing people. This also proves to be one of the biggest barriers to the successful adoption of the Scrum Framework by many organizations, large and small.
Scrum organizes people in a structure that is very different from the “traditional” way in which relationships within an organization are defined. Scrum realigns authority, responsibility, and accountability in ways that are very effective, but that fly in the face of conventional wisdom.
Many organizations find these new relationships, authorities, and responsibilities hard to grasp. Traditional structures are based on a “military” model that dates back hundreds of years. The military model , with its different ranks, serves to concentrate decision making (and responsibility) at the top of the organizational pyramid. The higher up an individual is in the structure, the more authority and responsibility that person has. The higher up one is, the more decisions that individual is expected to make.
The Scrum Framework, on the other hand, rejects the hierarchical “military” model. It seeks to align accountability and responsibility with capability. Those people who should be held accountable for a certain result are the ones who are capable of bringing it about. If they are accountable for a result, they must be given the authority to decide for themselves how to accomplish that result.
Unlike the military model, the Scrum Framework tends to concentrate decision making and responsibility at the bottom of the structure. The upper levels of the organization identify goals. The front-line people do the work of achieving those goals and are given authority to organize themselves to get it done.
The rest of the Scrum Framework provides tools for people to use when they are organized along Scrum lines. The tools provide ways for people to understand their own progress and to create products effectively. The tools also provide ways for empowered people to work together as a team.
As is often the case, many organizations try to implement the tools in the Scrum Framework without departing from the military model of the organizational structure. When they try to implement Scrum in this way, they are usually bitterly disappointed. The tools of Scrum simply do not work in a “command and control” environment, and trying to make them work usually results in frustration and failure.
The tools of Scrum only work when they are used by people empowered to make their own decisions. For people in a “command and control” situation, the tools of Scrum are worse than useless.
Products, Not Projects
The fundamental organizational unit in the Scrum Framework is the Scrum Team. The team consists of a group of people who together create, maintain, and enhance a particular product. The Scrum team takes responsibility for the product and does its work without needing any help from outside the team. The team is initially formed when the product is first created. It remains in existence as long as the product does.
This is quite different from the traditional way of handling products. As indicated earlier, the waterfall model views product development as a series of projects that are undertaken independently. At the beginning of each project, a goal is defined. Budget money is then approved and resources are gathered. A work plan is drawn up and the developers do the technical work required to implement the project goal. At the end of this process, a specific enhancement has been added and the resources are released to be reallocated to other projects.
Scrum departs from the emphasis on “projects.” It does so because of its focus on delivering “products of the highest possible value.” Organizing work into projects puts the emphasis on achieving project goals. Organizing work around products puts the emphasis on the product and its value.
A Scrum team’s job is to engage in an ongoing process of improving the value of the product for which the team members are accountable. Although the individual members of the team can (and do) change over time, the team exists as long as the product exists. They make ongoing changes and improvements to the product until it no longer makes business sense to do so.
The original Scrum Framework was designed for products that could be created and maintained by a group of up to 11 people. This includes the vast majority of software applications other than major commercial ones. In the case of truly huge products, such as the Apache Web Server or Microsoft Word, the Scrum Framework has been extended with the Nexus exoskeleton. A definition and description of Nexus was written by Ken Schwaber in August 2015.1
Nexus defines a structure in which three to nine teams can work together to accept responsibility for developing and enhancing a product. The Nexus exoskeleton does not change Scrum’s emphasis on the product. It simply expands the resources that can take responsibility for the value of the product.
Cross-functionality
Every Scrum Team must exhibit two vital characteristics. The first of these is cross-functionality. For Scrum Teams to play their role effectively, they must be cross-functional. If a team is not cross-functional, it cannot function as a Scrum Team.
What does cross-functionality mean? It means that a team must have within it every skill set needed to create the product. It does not mean that each team member must possess multiple skills (although that is helpful). Cross-functionality means that each and every skill relevant to creating the product must be present within the Scrum Team’s set of developers.
This requirement is often difficult to fulfill when an organization attempts to adopt the Scrum Framework. Traditional teams are usually composed of people with the same skill set. There is a team of programmers, another team of QA people, another one for the database administrators (DBAs), another one for the user experience (UX) people, and so on. In the waterfall model, tasks are assigned to these teams by the PM. It is up to the PM to figure out which team needs to do each task, and to coordinate their work so that each piece fits into the combined result. Coordinating many separate tasks, each in its own “silo,” turns out to be quite difficult.
The Scrum Framework, however, strives to eliminate all of those silos. It puts together representatives from those specialties (programmers, QA people, DBAs, UX designers, and so on) into a single team. When the team has been constructed properly, it is able to create the product from start to finish, without any help from anyone outside the team.
Cross-functionality gives two important benefits. The first is that it eliminates delays resulting from dependencies. If, for instance, the programmers have reached a point where they need a DBA, they are dependent on the DBA to do their work before they can proceed. If the DBA is part of the same team as the programmers, the work can be done when the programmers need it. If the DBA is part of an external group, the programmers will have to put in a request and wait for the DBA team to get around to filling their need.
The second important benefit is that it makes it possible for the team to accept responsibility for creating the product. If the team has all the resources it needs to develop and deliver a product, then the team has no excuses for failing to do so. If they have to depend on an external DBA, for instance, they can point to the uncertainties about that DBA and that person’s priorities as a reason they cannot commit to delivering the necessary functionality. If the DBA is part of the team, the team has no such justification for failing to deliver.
This part of the Scrum Framework makes up part of a “grand bargain” between the organization and the Development Team. The organization gives the Development Team all the skilled resources needed for creating the product. In exchange, the Development Team accepts responsibility for creating the product with no external help.
Self-organization
The second vital characteristic of a Scrum Team is self-organization. To accept responsibility for creating a product, the team must be self-organizing. If a team is not self-organized, then it cannot be held accountable for its work product.
With the waterfall framework, there is a Project Manager (PM) who organizes the work of the developers, analyzes the work to be done, assigns various tasks to the various technicians, supervises the work, and deals with any day-to-day adjustments that must be made. The responsibility for making sure the product is created rests with the PM.
In a self-organizing team, there is no PM. The team manages itself. The developers analyze the work to be done. The developers divide up the tasks among themselves and monitor their own progress. The developers deal with day-to-day adjustments that must be made. In the end, the responsibility for delivering the product rests with the developers themselves.
One of the flaws in the waterfall framework is the fact that accountability rests solely with the PM. The PM makes all organizational decisions and assigns tasks to the various developers to perform. The developers have no responsibilities other than to do the work that has been assigned to them. The PM accepts almost all the responsibility, and the developers accept almost none of it.
The PM tells the developers, “Do what you are told” In return, each developer tells the PM, “Just tell me what you want me to do and I will do my best.”
What are the developers really saying when they tell the PM, “Just tell me what you want me to do”? They are saying they don’t have to take any responsibility about whether they are doing the right thing. They will do what the PM asks. If it is the wrong thing, then it is the PM’s fault, not theirs.
In addition, when they say, “I will do my best,” the developers are really saying, “I will give it a try, but I don’t guarantee I will get it done.” Once again, it was the PM’s decision to give them the task, so if it proves to be too much for them, it is the PM’s fault and not their own. And, by saying, “I will do my best,” the PM has no way to measure whether the developer is doing their best work. Promising to do their best does not really change anything.
With the waterfall framework, there is a misalignment between accountability and capability. PMs are accountable for everything but have no direct capability to deliver anything. They must rely on the goodwill of the developers to get the project done. The developers generally cooperate until something goes wrong. At that point, the blame game begins, with the developers pointing out they had no say in any of the important decisions.
As I said before, the Scrum Framework serves to align accountability with capability. The developers are the only people who are capable of doing the work needed to create and deliver the product. For this reason, the Scrum Framework requires them to have the authority to organize and manage themselves. There is no PM to take accountability away from them. The developers themselves must assign work, track progress, and make sure they deliver the product as promised.
Self-organization is the second part of that “grand bargain” I mentioned before. Having developers work in cross-functional, self-organizing teams is the only way they can accept responsibility for creating the product. Only if they are (1) given all the skills needed and (2) given permission to organize the work themselves, can they be held responsible for the result. They will have no excuses not to deliver the product if they control the entire development process themselves.
Summary
Scrum Teams must be cross-functional and must be self-organizing. Only when the developers on the Scrum Team can accept full responsibility for creating a product can they bring all their talents to bear on the problem. We all know that “two heads are better than one.” It turns out that three to nine talented people are much better at creating products when they solve problems together, rather than being told what do to.
A properly structured cross-functional team works best when it organizes itself. Managers only get in the way.