The value streams layer encompasses the capabilities required to provide value streams to your customers. A value stream begins, ends, and hopefully continues with a customer. A value stream is the set of actions that take place to add value for customers from the initial request through realization of value by the customers. The value streams layer is one of the four layers of the Disciplined Agile (DA) tool kit, overviewed in Figure 1. These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE). This blog focuses on the value streams layer.
Figure 2 depicts the DA FLEX lifecycle, overviewing the high-level workflow for a value stream. As you can see, a value stream begins with the initial concept, moves through various stages for one or more development teams, and on through final delivery into business operations.
Let's explore the components of Disciplined Agile's value stream layer. The hexes in Figure 2 and Figure 3 represent process blades, sometimes called process areas. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner. Process blades also describe functional roles specific to that domain as well as extensions to the DA mindset specific to that domain.
You can see in Figure 3 that some process blades, such as Product Management and Program Management, are specific to this layer. Other process blades, such as Strategy and Marketing, are shared between the value streams layer and the disciplined agile enterprise (DAE) layer. This is an indication that you may choose to implement those process blades at both the enterprise level as well as the level of a single value stream - do what is right for your situation.
Expanding upon the Disciplined DevOps layer, the value stream layer adds the following blades:
Business operations focuses on the activities required to provide services to customers and to support your products. The implementation of business operations will vary by value stream, in a bank retail account services is implemented in a very different manner than brokerage services for example. Business operations includes help desk and support services (integrated in with IT support where appropriate) as well as any technical sales support activities such as training, product installation, and product customization. As you can imagine close collaboration with both your Sales and Marketing efforts is required to successfully Delight Customers.
The continuous improvement process blade describes how people within your organization can share their improvement learnings with one another in a systematic way. There are many strategies for doing so, including centers of excellence (CoEs), communities of practice (CoPs) which are also known as guilds, techniques for exploring existing ways of working (WoW), identifying new WoW, and sharing techniques.
Governance is the leadership, organizational structures, and strategies to enable you to sustain and extend your organization’s ability to produce meaningful value for your customers. Lean governance promotes strategies such as motivating people to do the right thing, enabling them to do so (often via automation), communicating organizational objectives, and preferring visibility over reporting.
The goal of marketing is to ensure successful interactions between your organization and the outside world. Disciplined Agile marketing applies data and analytics to continuously source promising opportunities or solutions to problems in real time, deploying tests quickly, evaluating the results, and rapidly iterating. It also means taking a validated learning approach, being customer focused, working in a collaborative and flexible manner, and working in an evolutionary (iterative and incremental) manner. Your marketing efforts will represent your organization and your offerings, both products and services, to the outside world and conversely will represent external stakeholders, and potential stakeholders, to the rest of the organization. In conjunction with product management, Marketing will be actively involved with long-term visioning for your organization’s offerings. Marketing is sometimes called brand management
Portfolio management addresses how an your organization goes about identifying, prioritizing, organizing, and governing their various endeavors. Disciplined Agile portfolio management seeks to do this in a lightweight and streamlined manner that maximizes the creation of business value in a long-term sustainable manner. Potential endeavors include solution delivery initiatives/projects, stable product development teams, business experiments (along the lines of a lean startup strategy), and the operation of existing solutions.
Product management is the art of taking strategic objectives and turning them into tactical activities. Disciplined agile product management is performed in a collaborative and evolutionary manner that reflects the context of your organization. Disciplined agile product management includes the acts of:
A program is a large team composed of two or more sub-teams (also called squads). The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goals of the overall endeavor. Program management encompasses financial activities, vendor management, coordination of people/staffiing concerns, coordination of the evolution of the solution, and coordination of requirements management issues across the sub-teams within the program.
Research & development
Research & development (R&D) encompasses the innovative activities undertaken by your organization to identify potential new offerings (services or products), or to identify potential improvements to existing offerings. R&D constitutes the first stage of development of a potential new offering. R&D activities are an important part of both product management and solution development to help explore potential ideas and strategies.
The aim of your sales efforts is to, you guessed it, sell your organization’s offerings (both products and services) to customers. Your sales people, if any, will work very closely with your marketing team to ensure they are focused on selling offerings that reflect your organizations’ overall strategy. They will also work closely with product management to ensure that what they’re selling is available or can be built in a timely manner. Organizationally Sales is often combined with marketing or may even be matrixed into business operations.
Strategy is what you do now, and what you intend to do in the future. The focus of the strategy process blade is to identify, evolve, and then drive the execution of your organization’s vision. Your vision is driven by the perceived needs of your customers and influenced by the environment in which you operate.
A common question that we get is what is the difference between Product Owners (POs) and Product Managers? From a Disciplined Agile (DA) perspective, it’s a matter of strategy vs. tactics:
We Need to Collaborate
As you can see in the following diagram, the role of Product Manager is different, yet overlapping, with that of a Product Owner (PO). The PO will spend the majority of their time on tactical activities, including working with the team to communicate stakeholder needs to them and working with stakeholders to elicit and prioritize their needs. The Product Manager, on the other hand, spends most of their time on more strategic issues, collaborating closely with customers (and potential customers) to identify their potential needs.
There is clearly overlap between strategic, long-term thinking and tactical, short-term implementation. Product Owners are responsible for the Product Backlog in Scrum, what Disciplined Agile DAD (DAD) teams might refer to as a Work Item List or in the case of teams who have adopted one of the lean lifecycles a Work Item Pool, and some of the items in the backlog/list/pool might be several months away from being implemented (if ever). In Figure 1, these are items that fall into the yellow or red timing areas, or even the grey area. Product Managers, being responsible for strategic thinking, will be focused on high-level outcomes or themes for the product. They may even be focused on more concrete, yet still high level, epics or features. So we see overlap in the Product Manager’s high-level strategic focus and the Product Owner’s tactical focus, indicating the need for collaboration between the two roles so that the tactical decisions reflect the overall strategy, and the overall strategy is informed by the realities faced on the ground by the delivery team.
Please note that the timing of “short term” and “long term” will vary by product. In the case of Figure 1 the long-term planning horizon is around the three month point (where the diagram shifts from yellow to red). That’s just an example, from one team. We’ve worked with some teams where the long-term planning horizon was anything more than a month. We’ve also worked with other teams where the long-term planning horizon was closer to a year (they’ve since shortened that considerably).
Shouldn’t Product Owners Also Address Strategic Issues?
Here are a few thoughts to help answer this question:
Being a Product Manager is an interesting and exciting role. We hope that this blog has been valuable for you.
The term minimum viable product (MVP) has achieved buzzword status in recent times and I’m now hearing people throwing around the term MVP almost on a daily basis. Sometimes they’re using it correctly but many times they aren’t. Frankly it’s driving me nuts.
The issue is that it’s common for people to say MVP when they are actually talking about a a minimum business increment (MBI), a minimum marketable feature (MMF), a minimum marketable release (MMR). There are several reasons why there is significant confusion in the marketplace:
To clear things up, we address the following topics:
Figure 1 below overviews how the following terms relate to one another:
Figure 1. The relationship between MVP, MBI, MMR, and MMF.
It is important that the term “marketable” doesn’t mean marketing in the sense of a product, but rather, making people aware of the value of what is being released. This can be as it related to a product or service and applies whether it is external or internal. In other words “something that is useful to the customer (internal or external) that can be demonstrated to be of value.
We often get asked several common questions around this topic:
Is it Minimum or Minimal?
Given that I’m being picky about terminology, I realized that there isn’t agreement as to whether we should use the term MINIMUM viable product or MINIMAL viable product (and similarly for MBI, MMR, and MMF). Once again, the words are very close:
As you can see, very nuanced. For better or worse, the industry has settled on the term minimum so that's what we're sticking with.
Why Differentiate Between MBI and MMR?
We wish we didn't have to. Ideally an MMR is a single MBI - your team wants to do just enough work to develop the minimum functionality that provides your customers with value and release it as quickly as you can. That's an MBI. Practically though you're sometimes forced to release more than a single MBI in a release. Perhaps you've decided to have a regular quarterly release cadence. Perhaps your customers prefer large releases (this still occurs in practice, although is becoming less common as your customers become more savvy with regards to incremental releases). These challenges can all be addressed in time, and they should be, but you may not be there yet.
Don't We Just Need The Concepts of MVP and MBI?
That's correct. When you've streamlined your way of working (WoW) you will find that an MBI is an MMF that you release to your customers, so it is also an MMR. The concepts of MMF and MMR are stepping stones towards what you are really aiming for, MBIs. But you might not be there yet, and you may be working with people who are more familiar with older terminology such as MMF and MMR - as a result we recognize in DA that these older terms exist but we avoid them where we can.
Now let’s work through an example of the development of a fictional product using the concept of MVPs and MBIs. One day while shopping in the local mall my phone ran out of power. This proved to be a problem for me because I had a conference call that I had to be on, forcing me to cut my shopping trip short to go home and take the call there. This experience made me realize that there’s a potentially untapped market need as I would have been very willing to pay to charge my phone while at the mall. Note: I am fully aware that products such as Safecharge and Brightbox exist, but let’s pretend they don’t for the sake of this example.
Just because I’m willing to pay for this doesn’t mean that others will. To determine whether this could be a profitable endeavour I decide to follow Disciplined Agile’s Exploratory Lifecycle (see Figure 2), which is based on Lean Startup’s hypothesis-driven approach. My plan is to iteratively build a series of MVPs to explore this product idea.
Figure 2. The Exploratory Lifecycle.
Over a several week period I work through a series of minimum viable products (MVPs):
This series of experiments led me to identify a collection of minimal marketable features (MMFs) that this product should offer:
Over the next two months we built a minimum business increment (MBI). The MBI was a large box which had 16 cubby holes for small devices such as phones. We the each box from folded sheet metal with clear, thick plastic doors so that people can see their devices. For security and payment processing we built a device that used a small touch screen (it was actually a large smart phone) as an input device attached to a card swipe for capturing both credit and debit card payments. Over several weeks we built five of them, placing three boxes in the mall where we had run our initial experiments and two boxes in another smaller mall on the other side of the city.
Then we continued to evolve the product via a series of MVPs. We ran some experiments in a public library where we discovered that library patrons wanted to charge large devices such as tablets and laptops as well as smaller devices. So we developed a new MBI, a “Library Charging Station” that had eight small device cubbies and six large device cubbies. We also hired a designer to develop a sleeker looking box when one mall management change told us that they loved the concept but wouldn’t allow our boxes into their more upscale locations until our boxes where more attractive.
Al Shalloway says it best: An MVP is an investment in learning, and an MBI is an investment in value.
Here's the key difference between the two: With an MVP you are in entrepreneurial mode and need to explore what your customers actually need. But this can only be done by a strongly cohesive and aligned team due to the uncertain, exploratory nature of the work. MBIs are for when you have a product or service and have a good idea for how to extend it. The biggest challenge is often coordinating the parts of your organization that is going to build, release, and support it.
My hope is that this article has helped to clear up some of this confusion.
5. Related Resources
A common challenge that we run into when working with organizations adopting Disciplined Agile strategies is helping them to identify and then coach people for the Product Owner (PO) role. This is often easier said than done due to the dearth of people with the required sill and mindset. In this blog we explore several strategies to address this challenge.
What Are You Looking for in a Product Owner?
Let’s begin with a review of the requirements for a good product owner:
Given the skill requirements it shouldn’t be surprising to anyone that there is a shortage of candidates for the PO role in most organizations. Let’s explore your options.
There are several potential sources of new product owners. The following table compares and contrasts these options. As you can see there is no ideal option available to you, and the reality is that you will likely need to obtain PO candidates from whatever source you can find.
An interesting strategy that we’ve found fruitful, albeit one that borders on ageism, is to look for potential candidates whom have been with your organization for a long time and who are getting close to retirement. These are experienced people who therefore are likely to have a good understanding of your organization and where it’s headed, they very likely have a good contacts throughout your organization, and they’re very likely looking for an interesting and stable position that will last until they’re ready to retire. Given that the investment required to create a Product Owner is rather steep so therefore you want someone willing to stay in the position for at least several years, and given that these are experienced people looking for a position that will last several years, it’s a very good alignment that you should consider taking advantage of.
Have a Clear Career Path
A critical success factor for attracting people to the role of PO is to have a clear and viable career path for them. If it isn’t obvious to people where they would go next after becoming a PO, or worse yet if becoming a PO is seen as a career dead end, then why would anyone choose to step into this role? One option for POs is to become product managers, if a product management function exists in your organization. Another career path is for POs to move into a senior business or IT leadership position. Being a PO gives people a deeper understanding of how IT fits into the larger organization and how it works in practice – key skills for anyone in senior management these days.