Requiring executive sponsorship
In the previous chapter, Origins of Agile and Lightweight Methodologies, I mentioned that a successful enterprise implementation of Scrum requires the support of a CEO or, at a product level, a senior-level executive who can assign a Product Owner to the development effort. As we get further into this chapter, we'll explore why that's the case. I don't want to imply that it's not possible to employ Scrum concepts within a small development team as a standalone effort. However, the team members' efforts will be frustrated without the executives buying in and having a basic understanding of Scrum concepts.
The successful implementation of Scrum requires making changes to traditional software development philosophies, culture, organizational structures, and infrastructure. Any project team that attempts to leverage Scrum concepts quickly runs into a host of organizational problems related to those four areas of concern. The Scrum Team needs an executive sponsor to clear the way for them to operate successfully. Later in this chapter, we will learn that a Scrum Master clears impediments for the development team in their day-to-day activities. However, the executives must also clear impediments at the organizational level.
At a philosophical level, Scrum refutes the misconceptions of the traditional model that customers desire capabilities for a product and that the work required to produce it is known from the start. Instead, requirements must be teased out over time as customers and end-users have a chance to use prototypes and incremental releases of new functionality. Likewise, the developers have better success when they can focus on high-value and high priority tasks, and iteratively implement new product features and functions in shorter intervals and more frequent releases.
The traditional (that is, Waterfall) model follows a project-based approach to development. Project management practices break development into distinct life cycle phases that are pre-planned and highly controlled. But if a product's requirements can't be defined at the start of a project, which they seldom are, then the project team is already off to a bad start. They will build features that may not be truly valuable, and they will have too much work in progress (WIP) to build and test the product efficiently. You will learn the importance of removing all forms of waste, of which WIP is a type, in the next chapter on concepts and practices.
Organizational cultures develop over time as a set of behavioral norms influenced by corporate policies and procedures, executive expectations, social influences, and just familiarity with the way the organization conducts its business. Unfortunately, this established culture leads to complacency and resistance to change that may hinder the competitiveness of the organization.
Just as cultures are built over time, changing the culture also takes time. Change is scary for many people. Therefore, organizational change is a difficult task, even when the organization's success or the livelihood of its people depends on it.
The use of traditional waterfall-based software development practices goes back to the mid-1950s. For many organizations, those practices are ingrained not only in corporate policies and practices but in the very culture of the company. Simply put, attempts to change the project-oriented approach to development cause stress up and down the organization.
The proper implementation of Scrum requires a very different set of roles, responsibilities, and practices than those defined in a project-oriented development approach. Also, at an enterprise level, there are layers of middle management positions that are not required, nor desired, when implementing Scrum. Those folks will not be supportive of change unless senior management helps them understand the importance of the necessary transformations and proactively find new roles and responsibilities for the affected individuals. They must trust that the organization's executives have their back, or they will work to undermine the transformation efforts.
Moreover, the practices of Scrum do away with a lot of overhead in terms of inefficient development processes, review and approval cycles, and overly burdensome documentation requirements. These items, too, are ingrained within the culture of an organization. They are ingrained because of the long-term behavior and beliefs of its people, informed by those policies and practices, and the social norms that evolved to support them. In short, it's hard for people to see why these activities are no longer necessary.
Less is more is a commonly used idiom that is ascribed initially to Robert Browning, in 1855, in his poem titled Andrea del Sarto. It is also applied to the minimalist architectural views of Ludwig Mies Van Der Rohe (1886-1969). However, the term has similarly found use in describing the minimalist concepts of Scrum. In the next subsection, you will learn why Scrum stays small, no matter the scale.
Implementing small teams
Scrum implements a small team approach to development. As a general rule of thumb, the Scrum Team should not have less than three people in it, nor more than nine people. Too few people and the team may not have all the skills and resources necessary to build the product. Too many people, on the other hand, and the communication among members and integrating work become too complicated.
The formula for team communications and integration links is x = n(n - 1) / 2, where x is the number of potential team member connections and interactions and n is the number of team members. So, a team consisting of three members has only three potential communication interfaces between its member. However, a team consisting of nine members has 36 communication interfaces between its members. Grow the team to 50 members, and the number of networked communications connections raises to 1,225. People simply cannot manage that many potential relationships and interactions.
So, Scrum does not scale by adding team members and infrastructure. It scales through replications of small teams by following the same basic rules, roles, events, and artifacts.
As your organization moves to implement a small team structure, it's essential to provide a work environment that is conducive to supporting small teams. Setting a suitable work environment is the subject of the next subsection.
Establishing a proper work environment
Scrum has additional infrastructure-related requirements in order to support the small teams. Each team needs to be co-located in a dedicated workspace with sufficient room to hold a table where they can work together with their computers. The room should have ample space so that whiteboards that display project data can be set up. Space for break-outs into smaller work teams for collaborative work sessions must also be provided. The room should include developer laptops and provide access to all the networks, computing systems, software, and other tools the team needs to design and develop the product.
The co-located work environments allow frequent face-to-face collaborations by team members, which better supports Scrum's empirical-based development processes. The team members should be able to meet and discuss important issues and topics without scheduling delays or communications impediments. In a co-located facility, the developers can participate in pair-programming techniques. Plus, the team members are free to move about and review the data that's posted on their whiteboards and flipcharts and use those same tools to work through the requirements and related architectural and design elements.