Background for the book While Scrum has caught on in the industry, many companies are finding scaling it to be problematic. At Net Objectives we consider understanding the principles of Lean Software Development to be essential in enabling scaling Agility to the Enterprise. While Scrum is effective at the team level, Enterprise Agility requires an Enterprise view. Trying to build an holistic view from pieces is not nearly as effective as driving from the Enterprise to begin with. Lean provides guidance in both "optimizing the whole" as well as "respecting people" to create a balance of effective teams working on Enterprise goalsl that teams working together without this vision cannot achieve. This book is about driving software development efforts to maximize realizsed business value. It requires: - Managing how product enhancements are initiated
- Giving guidance for product managers to work together to perform product portfolio management
- Managing dependencies between the software development organization and the other groups which it works with
- Managing dependencies across the software development organization
- Integrating development and QA roles to increase quality of software and eliminate waste
- Deciding on engineering practice standards across software development teams
To support these efforts requires a Scrum process with an Enterprise view instead of an overly team-centric view. Several of the above challenges are outside of the scope of Scrum. While Scrum does an excellent job at improving the productivity of the software development team, it lends little guidance beyond the team or the project the team is working on.This book also describes Net Objectives' extension to Scrum, called Scrum#, that enables it to scale to the Enterprise under the guidance of Lean. Scrum# extends Scrum by adding the enterprise view of Lean Thinking and the technical knowledge of Emergent Design. This gives Scrum practitioners the tools to use to extend Scrum from the team to the enterprise while giving guidance to the technical skills needed to accomplish iterative development Lean Software Development: Scaling Agile to the Enterprise- Preface
- Introduction
- Extending our View Beyond Projects
- Lean Project Management
- The Enterprise View
- Management's Role in Lean-Agile Development
- Structuring Teams in an Agile Organization
- The Product Integration Team - Going Beyond Scrum of Scrums
- The Role of Architecture in Agile Projects
- Summary
Lean Software Development: Scaling Agile to the Enterprise - Detailed Table of Contents0. Preface1. IntroductionTo understand how to improve Agile methods it is useful to understand their history, and therefore their bias. We must examine the belief system of Agility to understand what is good and what is bad. In order to change our beliefs we must first examine them. 2. Extending our View Beyond ProjectsMost Agile methods focus on the project. The most popular current Agile method , Scrum, is almost entirely focused on the team and the project they are working on. Enterprise Agility requires looking much earlier up the value stream than when the project starts. It also requires a deeper knowledge of product development than Scrum provides. 2-1 An Agile Developer’s Guide to Lean.
This chapter presents Lean Software Development from the perspective of an Agile Developer. Lean provides many insights that are essential to create an Enterprise view. It also provides insights into both understanding and improving Agile team methods.
2-2 The Business Case for Agility.
Team agility is a necessary step in our efforts. However, our real goal is Agility at the Enterprise Level. In this chapter we’ll learn that there are many reasons to become Agile – some from the business perspective, some from the team perspective. All coordinate together.
2-3 The Big Picture.
Extending Agile to the Enterprise requires seeing an enterprise view. Scaling agility by merely tying together teams working on individual projects creates the classic adage of not being able to see the forest for the trees. One must take an Enterprise perspective for Agility. This requires both expanding our view of the value stream from just the beginning and end of the project to the entire lifecycle of the products / services of the organization.
2-4 Portfolio Management.
Improving your product development process is only half the problem. Selecting the most important products to enhance is the other, even more important half. In this chapter we discuss how to select and size products for creation and enhancement.
2-5 Agile Resource Allocation.
A significant amount of the success of Agile teams is due to the success of how they are assigned to the work they are to do. Working on multiple projects has an adverse affect both on the efficiency of the teams and on the effectiveness of their management. In this chapter we discuss how a matrixed organizations cause severe problems to their teams and how a product orientation of our resources is essential. It is also demonstrated how stable teams can markedly improve estimation allowing for Agile Enterprise to have more accurate estimation methods than non-agile ones – even in the face of unclear scope.
3. Lean Project ManagementMost Agile teams focus on their own work and coordinate with others almost as an afterthought. The organization of an Enterprise’s teams must be created with the big picture in mind – including how they will work together. 3-1 The Limits and Misunderstandings of Scrum
Scrum was originally created as a framework for new product development. It unfortunately doesn’t provide enough underlying principles to be adopted effectively on its own when the scope of its use is beyond just a few teams working together. This chapter first discusses the large numbers of misinterpretations of Scrum that have developed because of this lack of explicit principles as well as several of the fallacies of Scrum itself. Lean principles are then discussed which can help the reader go beyond these challenges.
3-2 Sprint 0: Preparing for Your First Sprint.
While a common mandate of Agile methods is to produce value every iteration, this is neither wise nor possible when Enterprise Agility is being achieved. This chapter discusses what needs to be accomplished prior to actually building working code your first iteration.
3-3 Visual Controls for Enterprise Teams. The standard Sprint backlog works fine when one is working on small projects of limited complexity. However, when projects are large in both scope and size of the teams working on them, then the standard Sprint backlog fails in two areas. First, it does not provide enough management of how to prepare for the next sprint and second, it does not allow for the coordination of efforts between the teams. This chapter discusses a more robust Sprint backlog that is sufficient for both of these challenges.
3-4 The Role of Quality Assurance in Lean-Agile Software.
The role of testing should not be merely to improve the product by taking out defects. It should be to improve the process that is producing the product in the first place. This can prevent the defects from occurring in the first place. This also puts a different perspective on the role of testing in development – one that can greatly improve the efficiency of the teams.
4. The Enterprise ViewHaving expanded the view of what Agility is and describing how it works at the team level, we now describe how management and teams must work together to create true Enterprise Agility. 4.1 Management’s Role in Lean-Agile Development.
Agile methods mostly ignore the role of management. For small product enhancements in well-organized companies, this may not be too limiting. But when attempting to take the Enterprise itself Agile, management plays a significant role and to ignore it is to invite disaster. Lean, fortunately, supplies us with an effective paradigm for management – one that is essential to bring effective Agile development to the organization.
4.2 Structuring Teams in an Agile Organization.
Teams must be structured in such a way that they can effectively operate with each other. Agile teams are mandated with producing value as quickly as possible. On large projects, the way the software development organization is decomposed into teams can greatly impact this ability.
4-3 The Product Integration Team – Going Beyond Scrum of Scrums.
The classic Agile approach to coordinating teams is the Scrum-of-Scrums. Unfortunately, this has met with very limited success. This should not be surprising when one realizes that Scrum-of-Scrums works with teams that have different goals, needs and motivations. A way of coordinating teams must be created that has everyone on the same page. Combining individual teams and hoping for a cohesive organization is very much like combining individuals with different motivations and hoping for a cohesive team – it just doesn’t happen. This chapter describes Net Objectives’ Product Integration team that provides a viable alternative to Scrum-of-Scrums.
4-4 The Role of Architecture in Agile Projects.
Agility requires a new way of looking at the architecture for our application. We need to embrace the fact that our requirements, and the software along with it, are going to change during our project. Instead of trying to prevent change, we need to learn how to manage it. This chapter creates a new perspective on architecture – one that is more useful than the classic, static view of it. It also presents some insights into the software development process from a developer’s perspective, to enable her to deal with change. In particular, Shalloway’s Law is discussed as well as a question every developer should ask themselves when they are not certain about the design they are about to implement.
5. SummaryThis chapter presents a summation of the entire book. It represents a synopsis of all that has been presented.
Related Webinar SeriesRelated ResourcesRelated Courses at Net Objectives | 