Value Driven… The Book’s Layout

Understanding the Book’s Layout

The structure of Value Driven Agile Transformation is designed to incrementally introduce the key concepts necessary to lead a meaningful agile transformation. The book is broadly divided into halves, each half containing two sections:

The first part of the book is designed to help you clearly understand your goals so you can compare them against your current reality. Understanding the gap between where you are and where you need to be is often half the battle. We’ll spend time talking about what it means to lead a value driven enterprise agile and explore the challenges you’ll face along the way. We’ll talk about the dynamics that drive your current organization and how to begin thinking about how you will lead change.

The second half of the book will focus more on how to get where you want to go and how to overcome specific challenges in a pragmatic and systematic way. After going through this material, you should have a clear idea how to determine what your organization finds valuable and how you can begin road mapping your agile transition. Your plan is going to change as you implement and learn, but you’ll understand why and be able to articulate the impact of the changes.

We have included for your reference an appendix that explains the tools we use to implement this approach as well as several section helping the reader understand the relationship between agile and various capability based approaches to enterprise process improvement. These sections are included so you can assess the similarities and differences between an enterprise agile transformation and more traditional approaches to process improvement.

Section 1: Understanding the Goal

Chapter 1: Defining Agile

Many folks lead with an intuitive sense that agile is going to solve their problems. If we just get that agile going, everything is going to be okay. Over the years agile has become an extremely overloaded word. Some days agile is nearly synonymous with specific agile methodologies and some days so abstract as to be meaningless. This chapter will establish a solid foundation for understanding agile in its broadest and most abstract context. We’ll also dive down deep enough to understand the specific values, principles, and practices that really make it hum. We’ll explain many of the common methodologies and practices and how they fit into the bigger picture of enterprise agile software development.

Chapter 2: Defining Transformation

Now that we have a common understanding of what agile is, and how we might begin to apply some of these concepts into our organization, we want to get really specific about what we are really looking to change. Are we interested in helping one or two teams adopt agile practices or are we talking about a company-wide change initiative? Are we looking to adopt a few practices (like test driven development and iteration planning) or are we looking to influence how people think about the nature of their work? Are we trying to instill values or just change the way people behave? This chapter will help you answer these questions as well as explore the various aspects of change management you’ll need to understand before you get started.

Chapter 3: Defining Value

The only reason to even think about introducing this kind of change is to get some sort of return on your investment. That return doesn’t have to be hard dollars, but if that is what your organization is looking for, you better understand that and make sure you deliver. If you’ve ever tried to have a conversation about value, the idea is pretty misunderstood and very context sensitive. This section will help you explore the many ways that your organization might create value. We’ll talk about the difference between things that might have intrinsic value and things that have actual market value. There is often a big gap between valuable work and value that the business is willing to pay for. We’ll discuss another five phase model to help you understand how various stakeholders in larger organizations might perceive value.

Chapter 4: Establish the Change Vision

The change associated with a value driven agile transformation lies at the intersection of value, transformation, and methods and practices. Understanding how your organization delivers value is the first step in the transformation process. By focusing on the areas of the business that create the most value, you are most likely to create positive outcomes and a return on your investment. Next you have to understand the scope of what you are changing and finally what principles, values, or practices you want to introduce to implement the change. This chapter will explore the tools you need to define this intersection. We’ll discuss the importance of top down vision and bottom-up incremental adoption. We’ll lay out the conversation framework, the modeling tools, and the adoption and scaling approach defined later in the book.

Section 2: Understanding Our Current Reality

Chapter 5: Understanding the Traditional Organization

At this point, you should have a better idea of where you are headed, and how you might want to get started. Before you begin though, there are some things you need to understand about your current organization. Chances are, it was pretty successful long before you came along. It might not want to change and you need to know what you are up against. This chapter explores the traditional software development organization as it exists in many companies today. This chapter will focus on understanding how your current organization operates and how it got where it is today. We need to know how it has been successful thus far and why it might be harder to be successful in the future. We want to fully understand what we are changing before we go and try to change it.

Chapter 6: Understanding the Agile Organization

Chapter 1 established a solid framework for understanding what agile is. Now we are going to take a look at why and how agile works. We want to understand teams and why they are so important as the building blocks of the agile enterprise. We want to know how to really make them really hum. We’ll discuss different approaches for managing agile teams and approaches that encourage us NOT to manages agile teams. This chapter will explore the differences between black box management and white box management and the importance of establishing stable inputs so the team can establish predictable outputs. We’ll talk organizational constraints and how they influence team behavior. Basically, everything you need to know about how and agile team works.

Chapter 7: Why Larger Agile Transformations Fail?
(or don’t live up to the promise)

Many large-scale agile transformations either fail or don’t live up to the promise. Many companies might claim to be agile, and many may have even adopted some agile practices, but they are not getting the business outcomes that they expected. This IS NOT what we want to have happen here. This chapter will help us understand some of the common failure modes we might see in a more traditional organization as they make the switch to agile. We’ll explain why some of these same root-causes work against us and the new changes we are trying to put in place. We’ll explore issues around local optimization, command and control management, organizational structure and alignment, and traditional/agile hybrid environments.

Chapter 8: Selling Change Up the Organization

If you think transforming your team is hard work, try convincing senior leaders to let you try is even harder. Convincing them to let you transform the enterprise is even harder yet. This chapter will explore why leaders might be okay with agile at the team level but are resistant to advocating agile across the larger enterprise. If we want to lead an agile transformation, we need to learn why the messaging around agile doesn’t always resonate with our senior leadership. It goes back to how different stakeholders measure value but the conversation goes deeper. As agile proponents, we need to learn how to bridge the gap and help our leadership create a safe environment for introducing change. This chapter is about helping you understand and communicate your value proposition to your leadership team.

Section 3: Understanding What We Value

Chapter 9: Deciding What Your Organization Values

Now that we have a good idea of where we are going and why, and we are armed with knowledge about the challenges that stand before us, it is time to start thinking about how we want to move forward. This chapter will help us understand what your company values. Sometimes it is not just valuable software that your organization wants. We need to assess the cultural aspects of your organization. What kind of importance does your organization place on documentation, group decision-making, organizational politics, and governance? Are you operating in a regulated environment or not These are things we need to know about before we get started.

Chapter 10: Understanding How to Create Value

Believe it or not, not everyone is in business to sell software. Value isn’t always about getting features to market faster than our competition. If we are selling software, we need to understand our most important market opportunities and how we can best deliver products to market that people want to buy. If we aren’t selling software, we might be responsible for writing software that enables internal business processes. We might be in a mature market where maintenance and support is most important. Our goal could be less about building new features and more about keeping costs down and profit margins high. This section will outline a detailed approach for helping your organization understand how it creates value in its marketplace, whatever that marketplace might be. We will talk about tooling and approach for pragmatically identifying what your organization finds valuable.

Chapter 11: Understanding Your Improvement Opportunities

Using a similar approach to the one we used for understanding how your company defines value, we will explore what your organization needs to improve to get better delivering that value. Teams and organizations can’t get better at everything at the same time, the change would be too disruptive, too expensive, and introduce too much risk. We’ll explore the kinds of problems that your company might want to solve, how to understand them in the context of a broad set of goals and core capabilities, and how to choose which areas to invest to get maximum benefit.

Chapter 12: Identifying the Intersection

This chapter will introduce in detail an approach to organizational improvement called capability analysis. We’ll explore the mechanics, the tools, and the conversations required as well as. Here we will talk about gaining consensus around value and which capabilities we want to improve. Here we will introduce the five phase agile scaling model and take a step-by-step walk through the kinds of capabilities we might want to get better at delivering. The three facets of this section are going to be the five questions, 30+ core capabilities, and the four categories (Project Management, Product Management, Development, and Leadership). We’ll leave this chapter with a firm idea of where we want to spin up our first agile team.

Section 4: Creating the Value Driven Agile Enterprise

This section introduces a five-level agile adoption and scaling framework. At each level; we help identify cultural challenges your organization will face, how it defines value, and what you can improve to get better business outcomes. We’ll explore many common challenges your company is likely trying to solve, figure out which capabilities have to be addressed to see improvement , and identify what agile practices you and your company might put in place to get better in that area. We’ll explain the conversation context, the learning patterns, and the expected outcomes that will drive improved organizational performance.

Chapter 13: Team Level Agile Adoption

This section will explore the principles and practices many of us are familiar with from basic Scrum and XP. The difference here is that we will take a value driven approach to selecting which practices we want to put in place first. We’ll assess the capabilities of the organization and pragmatically decide what to start on first. This section will deal with introductory agile project management, discuss the role of a product owner and the roles and responsibilities of the other team members. We’ll introduce basic agile reporting, agile engineering, and agile teamwork and leadership concepts. This will in essence be a comprehensive survey of agile methods with an eye toward helping the reader understand why they might choose to put particular practices in place.

Chapter 14: Horizontal Agile Adoption

Horizontal agile adoption is about taking what we have learned at the team level and replicating that success to many teams across the organization. Our assumption at this point is that we have created our first agile team and used the capability baseline to determine where we need to improve next. We’ll end up at the end of this chapter with several distinct teams, loosely coupled, with a low number of dependencies between them. Here we will introduce the idea of a Scrum of Scrum for managing simple interdependencies between teams. We’ll take a look at common patterns of reporting across teams, handling shared code bases, building distributed engineering environments, estimating and tracking progress, and multiple product owners.

Chapter 15: Project Level Agile Adoption

This chapter begins to introduce the idea of having multiple teams work together to deliver larger, more complex projects, where we have to manage dependencies between teams. We are moving up one level in the organization hierarchy and there is a good chance the nature of our value discussion is going to change. We will apply capability analysis to figure out which projects need our attention and how to improve them. We’ll address how to deal with highly interdependent feature teams and possibly component teams on larger enterprise initiatives. We’ll introduce the idea of tracking value at the project level separate from value the team level. We’ll need to expand our agile toolkit and start extending basic concepts and introducing a few new ones.

Chapter 16: Program Level Agile Adoption

Program level adoption is focused on dealing with multiple projects, multiple stakeholders, competing priorities and competing agendas. It is about throttling work through the organization, defining smaller projects, and working on fewer things at one time. There is an emphasis in this section on balancing load across teams, a thorough discussion of the theory of constraints, and more Lean portfolio management. We’ll talk about how stories are to projects as projects are to portfolios and introduce the idea that projects need to follow the INVEST model too. If we make projects smaller, we can increase flow through the organization and start worrying more about getting projects finished rather than getting more projects started.

Chapter 17: Enterprise Agile Adoption

Enterprise agile adoption takes the value proposition up yet another level in the organization. Here we look at the entire value stream from concept to cash. We are managing the flow of value across the entire enterprise and all the value creating processes. We want to deal with upstream processes like project selection and approvals, business cases, and strategy. We also want to deal with downstream processes like maintenance and support. We want to balance the flow of value across the entire organization. This is the point in our transformation when we have truly created an agile enterprise, one that is prepared to deal with anything the market can throw at it.

Before We Get Started

Before you get started, keep in mind that agile adoption is not an event. It is a process of continuous improvement where the journey is almost as important as the outcome. By focusing on principles and the core problems you are trying to solve, and not the rote application of practices, we have a shot at creating a sustainable change framework; a learning organization. People do not change overnight and companies don’t either…