Buy the Book
by Al Shalloway, Guy Beaver, and James R Trott
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 goals that teams working together without this vision cannot achieve.
This book is about driving software development efforts to maximize realized 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.
Here are links to download chapters (PDFs) of the book.
Table of Contents
To 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 Projects
Most 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 Software Development.
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 Lean 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.
3. Lean Project Management
Most 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 Going Beyond Scrum.
This chapter discusses how one should approach learning a new methodology and how we can extend our knowledge of the methodology. We start with Scrum as a base because it’s currently the most popular team methodology in Agile. While Scrum is very effective at the team level, it needs to be expanded to work well throughout an Agile Enterprise. This chapter discusses several of the misunderstandings and limitations of Scrum and how to get beyond them.
3-2 Iteration 0: Preparing for the First Iteration.
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 Lean-Agile Release Planning.
3-4 Visual Controls and Information Radiators 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-5 The Role of Quality Assurance in Lean-Agile Software Development.
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 View
Having 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 Becoming an Agile Enterprise.
As there is no one set of practices that work with all companies, there is also more than one way to spread Lean-Agile throughout an Enterprise. In this chapter we discuss a few case studies of where to start and how to propagate Lean and Agile throughout an organization.
4.2 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-3 The Product Coordination Team.
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 Software Architecture and Design’s Role in Lean-Agile Software Development.
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. Looking Back, Looking Forward
This chapter presents a summation of the entire book. It represents a synopsis of all that has been presented.
5-1 Seeing Lean.
This chapter summarizes the ideas of this book, where we have been and where Lean and Agile fit in the context of software development. Lean may have its origins in manufacturing, but the approaches taken in this book have shown how it can apply powerfully to Software Product Development.