Scaling Scrum Across Modern Enterprises

Implement Scrum and Lean-Agile techniques across complex products, portfolios, and programs in large organizations

Cecil Rupp

• Publisher: Packt Publishing
• Year: 2020
• ISBN:
  9781839210303
• Edition: 1
• Topic: Computer Science
• Subtopic: Entreprise Applications
• Index: Computer Science

Establish business agility in your organization by applying industry-proven scaling strategies from popular Scrum frameworks such as Scrum of Scrums (SoS), Scrum@Scale, Nexus, Large-Scale Scrum (LeSS), Disciplined Agile, and SAFe

Key Features

• Learn how to be Agile at scale by implementing best practices
• Understand how Lean-Agile practices are incorporated in Disciplined Agile and the Scaled Agile Framework (SAFe)
• Customize Scrum and Lean-Agile practices to support portfolio and large product development needs

Book Description

Scaled Scrum and Lean-Agile practices provide essential strategies to address large and complex product development challenges not addressed in traditional Scrum. This Scrum/ Lean-Agile handbook provides a comprehensive review and analysis of industry-proven scaling strategies that enable business agility on an enterprise scale. Free of marketing hype or vendor bias, this book helps you decide which practices best fit your situation.

You'll start with an introduction to Scrum as a lightweight software development framework and then explore common approaches to scaling it for more complex development scenarios. The book will then guide you through systems theory, lean development, and the application of holistic thinking to more complex software and system development activities. Throughout, you'll learn how to support multiple teams working in collaboration to develop large and complex products and explore how to manage cross-team integration, dependency, and synchronization issues. Later, you'll learn how to improve enterprise operational efficiency across value creation and value delivery activities, before discovering how to align product portfolio investments with corporate strategies.

By the end of this Scrum book, you and your product teams will be able to get the most value out of Agile at scale, even in complex cyber-physical system development environments.

What you will learn

• Understand the limitations of traditional Scrum practices
• Explore the roles and responsibilities in a scaled Scrum and Lean-Agile development environment
• Tailor your Scrum approach to support portfolio and large product development needs
• Apply systems thinking to evaluate the impacts of changes in the interdependent parts of a larger development and delivery system
• Scale Scrum practices at both the program and portfolio levels of management
• Understand how DevOps, test automation, and CI/CD capabilities help in scaling Scrum practices

Who this book is for

Executives, product owners, Scrum masters, development team members, and other stakeholders who need to learn how to scale Agile to support large, complex projects and large enterprise portfolios and programs will find this book useful. A basic understanding of the values and principles of Agile and the Scrum-based framework for Agile development practices is required before you get started with this Agile Scrum book.

Section 1: Scaling Lightweight Scrum into a Heavyweight Contender

This section serves as an introduction to Scrum as a lightweight software development framework along with common approaches to scale Scrum for more complex development scenarios.

This section comprises the following chapters:

• Chapter 1, Origins of Agile and Lightweight Methodologies
• Chapter 2, Scrum Beyond Basics
• Chapter 3, The Scrum Approach
• Chapter 4, Systems Thinking
• Chapter 5, Lean Thinking
• Chapter 6, Lean Practices in Software Development

Chapter 1: TheOrigins of Agile and Lightweight Methodologies

This chapter briefly touches on why agile concepts, values, and principles evolved to address issues with traditional plan-driven and linear sequential software development models. Driven by software engineers, the goal of agile is to eliminate the complexities, inefficiencies, and inflexibility of the traditional software development models.

This chapter explains where the traditional waterfall approach often fails due to its emphasis on detailed planning and the execution of deterministic life cycle development processes. Not everything about the traditional software development model is bad, especially with its historical emphasis on developing and applying mature business analysis and engineering practices. In this chapter, you will learn how the values and principles of agile help address the many problems associated with the traditional software development model while understanding the importance of maintaining rigor in developing your business and engineering practices.

While this is a book about scaling Scrum on an enterprise scale, we need to first understand Scrum's agile underpinnings, and why Scrum needs to be scaled.

In this chapter, we will cover the following topics:

• Lightweight software development methodologies
• Core agile implementation concepts
• The values and principles of agile
• Why engineers largely led this movement

With those objectives in mind, this chapter provides an introduction to the lightweight methodologies that preceded the development and promotion of "agile" concepts, values, and principles. Those early efforts addressed the limitations of the traditional development model and also helped refine the concepts that ultimately defined what it means to be agile. In this chapter, you will also learn why engineers largely led the initial movements to implement agile-based practices.

Understanding what's wrong with the traditional model

Since you are reading a book on mastering Scrum, I might assume you already know something about agile practices and how they evolved to address the issues of the traditional software development model, also known as the waterfall approach. Still, it's never safe to assume. So, I'm going to start this book with this section to provide a quick overview of the traditional software development model, why and how it developed, and its shortcomings.

Modern computing became a reality in the early 1940s through the 1950s with the introduction of the first general-purpose electronic computers. The introduction to modern computing is particularly relevant to our discussions on the evolution of software development practices, as the high costs, skills, and complexity of software development drove early software and Systems Development Life Cycle (SDLC) practices.

In the earliest days of computing, computers filled an entire room, were extremely expensive, often served only one purpose or business function, and took a team of highly skilled engineers to run and maintain. Each installation and the related software programming activities were highly unique, time-consuming, schedule-bound, complex, and expensive. In other words, early computing efforts had all the characteristics of project-based work – and development activities were managed accordingly.

It's only natural that executive decision-makers and paying customers want to manage their risks in such an environment, and the discipline of project management provided a model for managing unique and complex work in an uncertain development environment under approved constraints. Project constraints consist of the approved scope of work, budgets, schedules, resources, and quality. Specifically, project management implements detailed project planning, documentation, scheduling, and risk management techniques to guide and control complex development projects within the constraints approved by the executives or paying customers. In software development, such practices came to be known as the so-called waterfall model.

The discipline of project management is as old as the Egyptian pyramids, dating back to roughly 2500 BC, and probably older than that. Project management evolved to manage work associated with building large, complex, risky, and expensive things. If you are the person financing such endeavors, you have a strong desire to control the scope of work to deliver what you want, in the time you want it, at a cost you can afford, and with certain expectations about the quality of the deliverables. Hence the genesis behind managing work under specific and approved project constraints.

Project management looks at work from the perspective of protecting the customer's investments in risky, expensive, and complex projects. In effect, customers accept a layer of management overhead with the goal of helping to ensure on-time and on-budget deliveries.

In a modern yet classical context, projects have the following characteristics:

• An authorized scope of work – no more, no less.
• Are temporary ventures with a specific start and an end date.
• May use borrowed (for example, from functional departments) or contracted resources over the project's life cycle.
• Have specific deliverable items (for example, products, services, or expected outcomes).
• The deliverables and the type of work are relatively unique.
• The uniqueness implies that some important information is not available at the start of the project, potentially impacting the project in some way when discovered.
• The uniqueness of the product and the work also implies that there is some level of risk in achieving the objectives on time, on budget, and with the allotted resources.
• The uniqueness of the deliverables implies the customers probably don't have a complete understanding of what they want or need – as it turns out, this is especially true when it comes to building software applications and systems.

In the traditional project management paradigm, the objective is to manage work within pre-determined constraints. The constraints are the scope of work, budgets, schedules, resources allotted to the effort, deliverables, and quality. The goal of project management is to successfully deliver satisfactory products within the constraints approved by the paying customer. The philosophy behind project management is that the combination of rigorous planning, engineering, and coordinated life cycle development processes provides the best approach to managing uncertainty and risk.

The project management philosophy works well when building things that are difficult to change once construction begins. Imagine that the pharaohs decided they needed tunnels and rooms within their pyramids after construction. I suspect it would have been possible, but the effort, resources, time, and costs would have been extraordinarily higher than if they planned and designed on those requirements before starting construction. The same concept is true when building ships, high-rise buildings, energy and telecom utilities, roads, and other large, complex, and expensive physical products. The cost of change is extraordinarily higher after construction starts.

Early computer scientists and IT managers faced many of the same constraints and issues those other industries faced. In other words, the characteristics of managing software development projects mirrored those faced in other industries that build large, complex, unique, and expensive things. It, therefore, seemed logical that software development projects also required rigorous planning, architectural design, and engineering, and coordinated life cycle development processes.

All software products and IT-based systems have a life cycle. The traditional model conceptually breaks up a product's life cycle into a series of phases, with each phase encompassing a type of related work. Phase descriptions expose work through a series of decompositions, consisting of the following:

• Processes provide a step-by-step set of instructions describing work within the phase. Phases typically have multiple processes, each describing a different type of work or approach to work.
• Activities (a.k.a. summary tasks) are artificial placeholders used to aggregate information about the completion of work in the underlying tasks. In other words, activities help roll up both the original estimates and the final measures of costs, time, and resources spent on the underlying work tasks.
• Tasks are the lowest practical level of describing work where a deliverable outcome is definable. Project managers often use the 8-80 rule to limit task durations to a range between 8 hours and 80 hours.

Product life cycle processes follow a common pattern of work activities. Products are conceived; requirements or needs are defined; architectures and designs are established; the products are constructed and tested. Then, they are delivered, supported, maintained, and perhaps enhanced until, one day, the decision is made to retire the products.

In the traditional plan-driven and linear-sequential software development model, the life cycle processes are laid out to show work and information flowing from one phase of work to another, as shown in the following figure:

Figure 1.1 – Traditional plan-driven, linear-sequential "waterfall" software development model

The figure implies this approach to development is a straightforward process from beginning to end. Still, even in the traditional model, this is not entirely true. There tends to be some overlap of work among the phases. The traditional waterfall model is more of a conceptual framework than a mandated work structure.

But the biggest point I want to make here is that the more a team frontend-loads requirements, the more protracted the overall work becomes. The added work in process (WIP) adds complexity, extends the development life cycle, and limits customer input. Moreover, adding WIP delays testing that would otherwise help find and determine the cause, and quickly resolve problems at the point they arise. In short, it is that frontend-loading of work that creates all the problems in the traditional model.

There is strong evidence to support that adding size to a project under the traditional waterfall-based development model is highly correlated with project failures, while agile-based projects outperformed traditionall...

Table of contents

• Scaling Scrum Across Modern Enterprises
• Why subscribe?
• Preface
• Section 1: Scaling Lightweight Scrum into a Heavyweight Contender
• Chapter 1: TheOrigins of Agile and Lightweight Methodologies
• Chapter 2: Scrum Beyond Basics
• Chapter 3: The Scrum Approach
• Chapter 4: Systems Thinking
• Chapter 5: Lean Thinking
• Chapter 6: Lean Practices in Software Development
• Section 2: Comparative Review of Industry Scaled Agile Approaches
• Chapter 7: Scrum of Scrums
• Chapter 8: Scrum@Scale
• Chapter 9: The Nexus Framework
• Chapter 10: Large-Scale Scrum (LeSS)
• Chapter 11: Disciplined Agile
• Chapter 12: Essential Scaled Agile Framework® (SAFe®)
• Chapter 13: Full Scaled Agile Framework® (SAFe®)
• Section 3: Implementation Strategies
• Chapter 14: Contrasting Scrum/Lean-Agile Scaling Approaches
• Assessments
• Other Books You May Enjoy