- Scaling Scrum Across Modern Enterprises
- Cecil Rupp;Manjit Singh
- 643字
- 2021-04-09 23:10:04
Applying systems thinking to large, complex, and integrated products
I've noted in previous sections that the original developers of Scrum, Jeff Sutherland and Ken Schwaber, both intended it to scale beyond the small product or single project. Interestingly, both Sutherland and Schwaber have extended the basic Scrum concepts to include new guidance on methods to scale Scrum across large products and at an enterprise level.
For example, Jeff Sutherland founded his new company Scrum@Scale for this purpose, and Ken Schwaber introduced his Nexus framework at Scrum.org for scaling Scrum.
We'll discuss both of these Scrum scaling approaches, along with several others, in Section Two of this book. But before we get to those chapters, we need to understand how systems thinking aids in the analysis required to deal with the increasing complexity of scaling Scrum, Lean, and Agile practices on an enterprise scale.
Putting the focus on products, not projects
In this section, you'll learn how to use systems thinking to analyze the complexities of deploying and maintaining multiple teams working on developing a single, large, and complex product. Before we begin, let's start by taking a quick look at how large projects were managed under the traditional project-based development model. This comparison helps set the as-is baseline that most organizations start from before we move on to Scrum.
Traditionally, using program-management concepts, the oversight of large and complex product-development efforts fell to the program manager and their program-management office (PMO). Under the traditional systems-development life cycle (SDLC) model, the program manager and PMO staff break up the overall work effort across multiple project teams, and the integration of work is managed via an integrated master schedule (IMS).
There is no fast rule on how to divide development work activities. The work assigned to each project team may be broken down by systems, applications, modules, types of related functionality, skills, or other criteria. Each project team defines the activities and tasks necessary to produce and deliver their assigned deliverables and then sends their planned schedules and updates back to the PMO for inclusion within the IMS. In other words, the IMS includes all identified deliverables and related activities and tasks supporting the authorized scope of work and spanning all participating project teams.
By definition, all programs and projects have constraints on budgets, time, scope of work, deliverables, resources, and quality. These constraints form the boundaries for what's in and what's out of a project.
Moreover, project-management philosophies hinge on the principles that all project-based work is unique and, therefore, at least some of the details are identified or fine-tuned throughout the project. The project's constraints help the executives monitor progress against the budgets and schedules that justified the investments, and help prevent unapproved scope creep from setting in.
The traditional project-management model does not look at the long-term life cycle requirements of developing, maintaining, and enhancing a product. New programs and projects must be approved, typically on an annual budget cycle, to address new product requirements or enhancements that were not identified in the previous program or project specifications. Consequently, project-based development philosophies are not inherently responsive enough to address evolving market opportunities or changes in customer or end user needs.
Scrum eliminates project-oriented practices and instead puts the focus on products. Moreover, continued development and support activities are sustained across the life of the product. Ideally, each new budget cycle simply determines the amount of funding required to sustain the development and support team activities for each product over the next fiscal planning period, until the product reaches its end of life.
Let's move on and look at some of the elements and relationships involved in transforming the development activities from a program or project-oriented development activity to a product-oriented development activity. As with the Sprint Planning CLD modeling activity, we'll start by identifying the elements and relationships involved in this transformation.
- MySQL數據庫進階實戰
- 數據庫基礎教程(SQL Server平臺)
- Python絕技:運用Python成為頂級數據工程師
- 從零開始學Hadoop大數據分析(視頻教學版)
- Python數據挖掘:入門、進階與實用案例分析
- Python數據分析入門:從數據獲取到可視化
- SQL Server入門經典
- 使用GitOps實現Kubernetes的持續部署:模式、流程及工具
- Mastering Machine Learning with R(Second Edition)
- 軟件成本度量國家標準實施指南:理論、方法與實踐
- 網站數據庫技術
- 數據庫應用系統開發實例
- The Natural Language Processing Workshop
- 標簽類目體系:面向業務的數據資產設計方法論
- Arquillian Testing Guide