Disciplined Agile

I’m happy to announce that Introduction to Disciplined Agile Delivery 2nd Edition: A Small Agile Team’s Journey from Scrum to Disciplined DevOps is now available.  The 111 page book sells for $9.99 US for the paperback edition and $3.99 US for the Kindle edition.  The book is currently available on Amazon.com in the US and will soon be available on Amazon in other countries as per Amazon’s usual deployment strategy.

This book provides a quick overview of how agile software development works from beginning-to-end.  It describes Disciplined Agile Delivery (DAD), the first of four levels of the Disciplined Agile (DA) process decision framework, and works through a case study describing a typical agile team’s experiences adopting a DA approach.  The book describes how the team develops the first release of a mission-critical application while working in a legacy enterprise environment.  It describes their experiences from beginning-to-end, starting with their initial team initiation efforts through construction and finally to deploying the solution into production.  It also describes how the team stays together for future releases, overviewing their process improvement efforts from their Scrum-based beginnings through to a lean continuous delivery approach that fits in with their organization’s evolving DevOps strategy.

What’s Different in This Edition

In the 2.5 years since the first edition was released DAD, and to a greater extent the DA toolkit in general, has evolved. Here are the major changes:

• Chapter 3 was completely rewritten to reflect the changes to DAD, in particular to addition of the Continuous Delivery: Agile lifecycle as well as the evolution of several process goals.
• Chapter 12 was rewritten to describe how the team, and more importantly the organization they work within, evolve into a Disciplined DevOps strategy. In the first edition we just took the team to the Continuous Delivery: Lean point, but in this edition we take them right into DevOps.
• Appendix A was rewritten to reflect the latest release of the DA toolkit. When the first edition was released the 2.1 version of the toolkit was overviewed in the Appendix. Since then the toolkit has been expanded to address four levels – DAD, Disciplined DevOps, Disciplined Agile IT, and now Disciplined Agile Enterprise (DAE) – instead of the original three. With the addition of DAE the DA toolkit provides true insight for how to begin supporting business agility within your organization.
• General updates were made throughout the book, including the update of several diagrams to reflect the evolution of DAD, expanding on a few ideas that readers said they wanted to hear more about, and fixing a few outstanding grammar errors.
• The book is using a slightly larger format, 6 inches by 9 inches, to match An Executive’s Guide to Disciplined Agile format. Similarly we also updated the cover to be consistent with that book.

Quality requirements, also known as non-functional requirements (NFRs), quality of service (QoS) or technical requirements, address issues such as reliability, availability, security, privacy, and many other quality issues.  The following diagram, which overviews architectural views and concerns, provides a great source of quality requirement types (the list of concerns).  Good sources for quality requirements include your enterprise architects and operations staff, although any stakeholder is a potential source for them.

Figure 1. Architectural views and concerns.

Why Are Quality Requirements Important?

Stakeholders will describe quality requirements at any time, but it’s particularly important to focus on them during your initial scoping efforts during Inception as you can see in the goal diagram below for Explore Initial Scope.  Considering quality requirements early in the lifecycle is important because:

1. Quality requirements drive important architecture decisions. When you are identifying your architecture strategy you will often find that it is the NFRs that will be the primary drivers of your architecture.
2. Quality requirements will drive some aspects of your test strategy. Because they tend to be cross-cutting, and because they tend to drive important aspects of your architecture, they tend to drive important aspects of your test strategy.  For example, security requirements will drive the need to support security testing, performance requirements will drive the need for stress and load testing, and so on. These testing needs in turn may drive aspects of your test environments and your testing tool choices.
3. Quality requirements will drive acceptance criteria for functional requirements (such as stories).  Quality requirements are typically system-wide thus they apply to many, and sometimes all of your functional requirements.  Part of ensuring that your solution is potentially consumable each iteration is ensuring that it fulfills its overall quality goals, including applicable quality requirements.  This is particularly true with life-critical and mission-critical solutions.

Capturing Quality Requirements

Figure 2 depicts the goal diagram for Explore Scope.  As you can see, there are several strategies for exploring and potentially capturing quality requirements.

Figure 2. The goal diagram for Explore Scope (click to enlarge).

Let’s explore the three strategies, which can be combined, for capturing quality requirements:

1. Technical stories.  A technical story is a documentation strategy where the quality requirement  is captured as a separate entity that is meant to be addressed in a single iteration.  Technical stories are in effect the quality requirement equivalent of a user story. For example “The system will be unavailable to end users no more than 30 seconds a week” and “Only the employee, their direct manager, and manager-level human resource people have access to salary information about said employee” are both examples of technical stories.
2. Acceptance criteria for individual functional requirements.  Part of the strategy of ensuring that a work item is done at the end of an iteration is to verify that it meets all of its acceptance criteria.  Many of these acceptance criterions will reflect quality requirements specific to an individual usage requirement, such as “Salary information read-only accessible by the employee,”, “Salary information read-only accessible by their direct manager”, “Salary information read/write accessible by HR managers”, and “Salary information is not accessible to anyone without specific access rights”.  So in effect quality requirements are implemented because they become part of your “done” criteria.
3. Explicit list.  Capture quality requirements separately from your work item list in a separate artifact.  This provides you with a reminder for the issues to consider when formulating acceptance criteria for your functional requirements.  In the Unified Process this artifact was called a supplementary specification.

Of course a fourth option would be to not capture quality requirements at all.  In theory this would work in very simple situations but it clearly runs a significant risk of the team building a solution that doesn’t meet the operational needs of the stakeholders.  This is often a symptom of a teams only working with a small subset of their stakeholder types (e.g. only working with end users but not operations staff, senior managers, and so on).

Related Resources

• Strategies for Implementing Quality Requirements
• Strategies for Verifying Quality Requirements
• Develop Test Strategy
• Identify Architecture Strategy

Building on the ideas captured by the Disciplined Agile Principles and the Disciplined Agile Manifesto, there are several agile/lean philosophies that are critical to success in Product Management.  These philosophies are:

1. Be customer driven.  The needs of customers, and more importantly the potential desires of customers that they are not even be aware of, should drive your Product Management decisions.  The implication is that Product Managers must work closely with existing customers, and furthermore must invest time to identify and understand potential customers so as to grow the market for their product.
2. Address the full value stream.  An important part of being customer driven is to understand that it is the full customer experience with your organization, not just the “products”, that must be addressed.  You need to understand the full value stream(s) that your product(s) are part from beginning to end from the customer’s point of view – Product Management is about solutions and not just software.
3. Take an experimental approach. People often don’t know what they want, will struggle to describe what they want, often won’t tell you want they want, and will change their minds anyway.  The point is that you need to go beyond asking people for their requirements if you want to identify what to offer your customers.  Modern thinking is to take an experimental approach via creation of minimal viable products (MVPs) to get something in front of potential customers to determine what they actually want – you do this through observing the features of your MVP that they use, how they use them, and the features that they don’t use.  This strategy was popularized by Eric Ries via his Lean Startup work and is captured in DAD’s Exploratory lifecycle.
4. Release incrementally and often.  Releasing smaller increments more often enables you to reduce the feedback cycle with your customers, which in turn enables you to learn quickly and thus react to customer needs faster.
5. Embrace change.  Customer needs and desires change, often rapidly.  New competitors enter the market with different or improved offerings.  New technologies and platforms are introduced and then evolved.  To be trite, the only constant is change.  Successful product managers not only accept this but they embrace it.  The implication is to adopt flexible, light-weight strategies.
6. Plan strategically and react tactically.  Products should be planned strategically in the long term yet implemented tactically in the short term.  The common agile strategy is to take a what is known as a rolling wave planning approach where detailed planning occurs for what should be delivered in near team incremental releases but for future releases the planning is high-level and less detailed the further in the future something is.

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. The issue is that it’s common for people to say MVP when they are actually talking about is a minimum business increment (MBI), a minimum marketable feature (MMF), or a minimum marketable release (MMR). Having said that, I prefer the terms MVP and MBI, two different concepts, and rarely use terms like MMF or MMR other than to point people to the first two terms.  Having said that, I'll still cover all four concepts in detail here.

There are several reasons why there is significant confusion in the marketplace:

• These are closely related concepts with very similar names.
• Various authors over the years have used these terms in different ways, thereby muddying the waters.
• Terms naturally evolve over time, and will blur into each other, via natural usage.  

To clear things up, we address the following topics:

1. Defining the terminology
2. Answering common questions
3. An example
4. Summary

1. Defining the Terminology

Figure 1 below overviews how the following terms relate to one another:

• Product. I'm using this term loosely to mean a product, a service, a combination of the two, or a new "big feature" of an existing product. I personally prefer the term offering, but product is the popular term.
• Minimum Viable Product (MVP). An MVP is an investment in learning, an experiment where your goal is to explore what a potential customer wants.  To run this experiment you'll create a version of a product via the least effort possible so as to be used for validated learning about your potential customers. MVPs are experiments to explore a hypothesis about what your customers really want. They aren't to the “real” running version of your end product because they aren't at the level of quality or scale that you would produce for the end product.  Having said that, I have seen MVPs evolve into a real product, or more accurately a real MBI, but more often than not they evolve into something more along the lines of a prototype (which is fine because they're an investment in learning and were never meant to be the real thing). A team typically runs the experiment with a subset of your potential customers to test a new idea, to collect data about it, and thereby discover customers are actually interested in.  Note that the term MVP was coined by Frank Robinson at SyncDev in 2001 and popularized by Eric Ries in his book Lean Startup in 2011.
• Minimum business increment (MBI). An MBI is the smallest piece of value that can be realized by a customer (internal or external) that is consistent with the strategy of your organization.  An MBI adds value for your customers and leads to valuable feedback to the product team that the right functionality is being built and is being built in the right way.  An MBI is a solution that contains all of the pieces that are required for value realization by customers. An MBI, when it is done right, is both an MMF and an MMR. Note that the term MBI was coined by Al Shalloway.
• Minimum Marketable Feature (MMF). An MMF is the smallest piece of functionality that can be delivered that has value to its customers, and thereby value to your organization.  An MMF is a part of an MMR.  The term MMF was first proposed by Denne and Cleland-Huang.
• Minimum Marketable Release (MMR).  Successful products are deployed incrementally into the marketplace over time, each “major” deployment being referred to as a release.  An MMR is the release of a product that has the smallest possible feature set that addresses the current new needs of your customers.  MMRs are used to reduce the time-to-market between releases by reducing the coherent feature set of each release to the smallest increment that offers new value to customers. An MMR is one or more MBIs (ideally it is one).

Figure 1. The relationship between MVP, MBI, MMR, and MMF.

2. Answering Common Questions

We often get asked several common questions around this topic:

• What are the key take-away points?
• Is it minimum or minimal?
• Why differentiate between MBI and MMR?
• Don't we just need the concepts of MVP and MBI?

What are the Key Take-Away Points?

The key take-away points of this article are:

• An MVP is an investment in learning.
• An MBI is an investment in value.
• Don't worry so much about the other terms

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:

• Minimum. The refers to the least quantity or lowest possible amount.
• Minimal.  This refers to barely adequate or sufficient (similar to the agile concept of just barely good enough (JBGE)).  Minimal is an adjective derived from the word minimum.

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 should be at the point where 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.

3. An Example

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 run a series of experiments 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):

1. Experiment #1: A power bar on a table.  I start with a very simple approach: I talk the mall manager into allowing me to put a table against a wall for a one week period to run an experiment. I plug a power bar into a nearby outlet and put it on the table.  On the wall I have a sign that indicates this is a phone charging station.  Throughout the week I stand by the table telling people about the service and tell them I’ll keep an eye on their phone if they want to go shopping while it charges (I quickly discovered that nobody is willing to actually do that, or at least they’re not willing to trust me, hmmm….). For anyone willing, I have them take a short survey asking them what they think about the service.
2. Experiment #2: I add several common power cords. On the first day several people indicated that they would use the service but unfortunately didn’t have their charging cable with them.  So at the end of the first day I bought several power cables from an electronics store in the mall. Sure enough, over the next few days I had more people willing to charge their phones at my table.  By the end of the week I had gathered a fair bit of data that showed there was general interest in the idea but that a major problem was the inability to safely leave a device to charge while they go off to shop.
3. Experiment #3: I move to a cafe. The following week I run a similar experiment in a cafe a few blocks away from where I live.  Interestingly, I have several people ask to borrow a power cable from me so that they could power their phone while sitting at their own table.  The cafe already has power sockets for people to charge devices and it’s fairly common for people to camp out in the cafe for several hours with a laptop or table plugged into the wall.  After several days it becomes clear to me that a cafe isn’t a good option for a charging station.
4. MVP #4: I add lockable cubby holes.  Over the next week I decide to build out a more sophisticated solution, a wood cabinet that has 16 cubby holes for charging devices.  Each cubbyhole has a specific type of charge cable, so if you want to change a phone you need to use a cubby with the right type of cable.  Each cubby has a door with a physical key lock.  I go back to the mall, in the same location as I’d been in previously, and instead of a survey I interview people to discover what they they think, how they would make it better, and what they’d be willing to pay for such a service.

This series of experiments led me to identify a collection of features that this product should offer:

1. Lockable cubby holes.  People will only leave their phones and other devices if they’re safe.  Each cubby hole needs to be locked in such a way that only the person who left their phone in the cubby can get access to it.  This could be an electronic locks where people can type in a private code or a physical key-based system.
2. Common phone power cords.  We need to be able to support charging a range of devices.  Each cubby should have several common power cord/cables as well as a normal power plug.
3. Easily accessible location that doesn’t offer charging alternatives.  Malls and restaurants are good options, but public areas that already support device charging (like cafes) are not.
4. Payment processing.  We want to support credit card and possibly blue-tooth payment strategies such as Apple Pay.  Payment options need to be investigated still.

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 a tablet) 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 chain told us that they loved the concept but wouldn’t allow our boxes into their more upscale locations until they were more attractive.

4. Summary

I'll say it again (a paraphrasing of Al Shalloway's advice):

• An MVP is an investment in learning.
• 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 discover what your customers actually want. MBIs are for when you have an existing product and have a good idea for how to extend it. 

My hope is that this article has helped to clear up some of this confusion.

5. Related Resources

• Minimum business increments (MBIs)
• The most compelling reasons for using MBIs
• The Exploratory (Lean Startup) Lifecycle
• The Release Management process blade
• The Product Management process blade
• Minimum vs. Minimal

I’m happy to announce that the Disciplined Agile Consortium (DAC) is now working with SEMAT. SEMAT, Software Engineering Method and Theory, is an international community of people, companies, and universities.  Led by Ivar Jacobson, SEMAT is working together to create a common ground, or kernel, for software engineering.  As you may know I am one of the original signatories who first indicated their support for the SEMAT effort and am currently a member of the SEMAT advisory board.

So why are we working with SEMAT?  We hope to gain several benefits:

1. Share DA concepts more widely.  We intend to work together to essentialize some of the key concepts that are unique within the Disciplined Agile (DA) toolkit.  This will help to get our leading-edge material into the hands of more people.
2. Leverage essentialized practices.  The SEMAT community has already captured, what they refer to as essentialization of, a wide variety of great practices such as TDD, continuous integration, coordination meetings, and so on.  Our approach in DA is to put such practices into context but not to go into detail describing them (instead we reference existing descriptions).  So, SEMAT provides DA with a great source of existing material to reference.
3. Collaborate with the SEMAT community.  There are many practitioners, trainers, and researchers within the SEMAT community and it’s always a great idea to work with smart people!
4. Enable our customers.  A big advantage with SEMAT is that they’ve published, and continue to publish, a lot of great process material.  This is exactly the type of material that organizations need to support the learning activities of their staff as well as their own process definition efforts.

Of course it is still early days and there is a lot to do.  Please stay tuned here for further updates!

Recommended Reading

• The Essence of Software Engineering: The SEMAT Kernel
• The SEMAT Home Page