Braz Brandt, Author at Agile Velocity

Blog

The MMF: Minimum Marketable Feature

By: Braz Brandt | Nov 22, 2017 | Agile Technical Practices, Article, Product Owner

Welcome to the final installment of our MVP, PSI, MMF Alphabet series. For this article, we’re digging into MMF (Minimum Marketable Feature).

The MMF

Something I try to help new Product Owners with is understanding the distinction between Potentially Shippable and “We actually want to ship this”.

There’s a tension that exists between the desire to deliver quickly and learn even more quickly, and the need for a company and a product to put its best foot forward and release something of significant and usable value. If we follow the thread of our word processor (the one we discussed in Part One and Part Two of this series) and creating the ability to automatically save documents as we write, we can start to understand this tension.

A word processor with the ability to automatically save the document I’m working on is a nice, differentiating feature. By itself, though, it doesn’t define a word processor. Our word processor needs spellcheck, and formatting options, and some file management capabilities so that authors can work on more than one document. Releasing our text editor with auto-save, but without the other features that our customers called useful in their interviews (you did some market research and user interviews, right?) leaves us with an interesting technical proof-of-concept, but without a word processor most people would purchase.

As a Product Owner, it’s too often taken as a given that you understand how to break your product backlog into small, deliverable chunks of value—what we can argue is a Minimum Viable Product. When I’m helping Product Owners who’re struggling with this concept, I like to focus on two things—the idea of “Viable”, and then the idea of “Minimum”.

Minimum Marketable FEATURE

When we’re looking at delivering value to our customers, one of the critical questions we have to ask is, “What would they buy?” In other words, if we released this product with this collection of features, would our customers pay for it?

To me, when I’m helping Product Owners, it’s some variation of that core question that helps me define what we mean by MMF. We can release small experiments and proofs-of-concept to a core group of trusted testers and early adopters, but our customers demand more.

Through the process of user interviews, writing personas, and segmenting your potential customers, you’ll quickly start to recognize that there are certain expectations your users demand. If you start to ask them interesting questions about what they would actually want—using things like “Buy a Feature” to create some prioritization conversations with your customers, stakeholders, and team for example—you can start to winnow down your giant Product Backlog into some interesting collections of features.

When we’re talking about our word processor and working with our focus groups, one theme starts to appear—there’s a market for a lower-priced alternative to some of the bigger names in the word processing space, where a smaller set of features with two key differentiators could actually solve some customer needs.

We look at our Product Backlog, and we decide that we’re going to target a great, focused writing product with auto-save and use Markdown to support our text formatting. Further, we’re going to focus on delivering our product on iOS first, since there aren’t many great word processors on iOS today.

(Yes, I know that’s not true as I write this blog post on my iPad Pro somewhere over North or South Carolina. Play along with me, okay?)

We’ve just defined our Minimum Marketable Feature—it’s not a complete word processor that will unseat the market leaders, but it’s marketable to a key portion of our users: it solves specific problems our early adopter mobile customers have, and creates a product we can release and start to sell to our customers.

MINIMUM Marketable Feature

When we start talking to our customers, the second tension we have is the idea of releasing the Minimum we can to provide something of value.

Henry Ford has an often-quoted line that, while over-used, is still incredibly relevant:

“If I had asked people what they wanted, they would have said faster horses.”

The question of whether Henry Ford actually said that aside (he probably didn’t) is the idea that our customers frequently don’t know what they actually want. A variation of “faster horses” I frequently see is what I call, “Oooh! That too!”

When we present our customers with a list of potential features, there’s a tendency for their eyes to quickly outgrow your team’s ability to deliver; each new possibility is exciting and “definitely” something they would want. As a Product Owner, it can be exhilarating to have all your ideas validated as not just interesting, but as something your customers would “definitely” buy!

One of the things I most enjoy about feature prioritization games like Buy a Feature is that they force difficult budgeting conversations—with customers, with stakeholders, with our team. There’s a real magic to creating a budget with our customers—“You only have $100 to spend”—and forcing conversations about value and priority.

However, even with that prioritization, we as Product Owners still need to ask, “Do you REALLY need that?” One way to ask is to offer different budgets to our customers in Buy a Feature—would they still rank those features that way if they only had $50? How about $25?

The goal isn’t to whittle away features until we’re left with a skeleton of a product; instead, the goal is to understand what the definition of the smallest set of features to solve a customer problem. Using our word processor example, if we shipped a version without support for Markdown formatting, but it still auto saved our documents, would you use it, or is there something you would use instead?

Until we have a product in our customers’ hands that they can use, we can’t learn what actually works. However, the more features we put into our MMF, the longer we have to wait—and the more we have to spend, and the bigger the opportunity for our competitors—to learn from our customers.

Defining a Minimum Marketable Feature is something that, when done well, looks like a dance between stakeholders, customers, and our team’s ability to deliver. No wonder being a Product Owner is hard!

Wrapping It Up

Product development asks a lot of Product Owners, and things like the Scrum Guide are frustratingly silent on the work that a good Product Owner has to do to build, maintain, and prioritize right-sized work for their teams. The Agile community doesn’t make it any easier, with a swarm of acronyms and at times self-contradictory ideas about how to build product increments.

I hope this helps clear up some of the confusion and, if nothing else, equip you with some ideas on how to feed your team experiments to validate assumptions and hypotheses, use that knowledge to define pieces of value to potentially ship, and a way to combine those pieces into releasable, marketable features to delight your customers.

Don’t forget to check out Part 1 and Part 2 of this series here:

Part One: MVP

Part Two: PSI

Blog

The PSI: Potentially Shippable Increment

By: Braz Brandt | Nov 15, 2017 | Agile Technical Practices, Article, Product Owner

For the second installment of our MVP, MMF, PSI Alphabet Soup series, we’re going to tackle the PSI (Potentially Shippable Increment) also known as PSPI (Potentially Shippable Product Increment).

The PSI

Where I try to start with Product Owners when I’m coaching them is the idea of the PSI (Potentially Shippable Increment). At the end of every iteration, our Scrum team should have completed work on one or more Potentially Shippable Increments (of Customer Value, but we’ll get to that in a second) that their Product Owner can make a decision around—can I ship this to my customers?

What this means in practice is that, as a Product Owner, I end up focusing on small little features—things that I can take for granted as a given, as “table stakes” when building a product in my market. If my team is working on building the Next Great Word Processor (because actually updating WordPerfect™ from the grave would be more costly than starting over) then it’s easy to assume that everyone understands what you mean when you say that your customers want to “Save their Document.”

There are a surprising number of assumptions that go into “Save” though; the program I’m using to write this blog post, for example, doesn’t even have a Save command. Instead, everything is automatically saved—to iCloud using CloudSync, naturally—when I stop typing for a few moments. As a Product Owner, I don’t have to know about iCloud or CloudSync, but I do have to define those things that I would otherwise take for granted.

After our Product Owner defines our features at a high level, the critically important work of actually talking to her team takes place, and during that conversation, she realizes that providing her customers with the security of a document that’s always saved is an actual market differentiator when compared to other word processing programs.

So, our Product Owner rolls up her sleeves and talks to her team, and we write a User Story:

“As an author, I want to have my word processor automatically save my document while I work, so that I can work on writing without being concerned about losing my data.”

She’ll iterate with her team on some acceptance criteria (“Documents need to be saved when disconnected from the Internet”) and handle some edge cases that can turn into User Stories on their own (“Roll back to a previous version, because I actually didn’t want those most recent changes saved”). As they iterate, they’ll winnow down a feature into something our team can deliver in one Iteration—a Potentially Shippable Increment.

“Great! We got that User Story to Done-Done! What do our customers think?”

“Well, we haven’t released it yet…”

For the final installment of the series, we’ll discuss the MMF (Minimum Marketable Feature) and how it helps draw the distinction between PSI and actually shipping your product.

Blog

MVP, MMF, PSI, WTF? Part One: Understanding the MVP

By: Braz Brandt | Nov 08, 2017 | Agile Technical Practices, Article, Product Owner

When I’m working with new Product Owners, I frequently find that we get caught up in a sea of TLA’s (Three Letter Acronyms) when it comes time to actually start turning their Backlog of ideas into releasable increments of value.

The idea of breaking work down – breaking down our Large, Planned Out product releases into smaller increments of value is where many new Product Owners struggle. How do we take this Product Roadmap and turn it into something my Scrum teams can actually deliver on a short, regular cadence? How can I turn this huge list of Very Important Features (VIFs) into an iterative set of opportunities to learn, to deliver value, and to actually put something in the hands of our customers? In other words….

“What’s our MVP?”

“Is that our MMF?”

“Can we release this PSI as an MVP, or do we need more stories done before we have an MMF?”

Also….what???

What do these TLA’s mean? How are they different from each other? How are they related? Why should I care?

Starting with MVP (Minimum Viable Product), this three-part series will help beginner agilists understand what these TLA’s mean. How are they different from each other? How are they related? Why should I care? It will also help remind those who have been working Agile for a while why these concepts are the linchpins of agility.

For people just starting to learn about Scrum, they can turn to the Scrum Guide… and learn quickly that the Scrum Guide is silent on the how of turning a product into a collection of small, releasable increments of value.

The lack of info around this important subject can be really frustrating to new Product Owners. Hopefully, the rest of this article will clarify MVP’s, and there’s always Certified Scrum Product Owner classes to check out for more information. For now, let’s dive into the Minimum Viable Product.

[If your teams are struggling to get an MVP finished, it could be a sign you’re not predictable yet. Download the 8 Common Pitfalls of An Agile Transformation to help identify key areas in need of focus.]

The MVP

You’ve done your research, you’ve walked customer focus groups through a few rounds of Buy a Feature, and you’ve made some decisions around what your next release might look like. In fact, you’ve engaged your marketing team and you’re iterating through ideas about how to make a big splash – ads in trade magazines, promoted Tweets, Facebook posts…

But, there are still some nagging questions you have around some of the features you’re working on. You’ve thought about them, you’ve analyzed them, but there’s this voice in your head that keeps asking, “But how do you KNOW?”

That’s where the MVP comes into play—not Steph Curry, but the (perhaps wrongly named) Minimum Viable Product.

The Lean Startup Conundrum

In his book “The Lean Startup”, Eric Reis confusingly re-defines the term “Minimum Viable Product”, which he explains in an interview in 2015. In short:

“Some caveats right off the bat. MVP, despite the name, is not about creating minimal products. […] Second, the definition’s use of the words maximum and minimum means it is decidedly not formulaic.”

So, if the world of Product Ownership and the Agile community has redefined Minimum Viable Product to be neither about creating the minimum or products, then what is it?

All About the Learning

That nagging voice in the back of your head, wondering if there’s a way out of the Analysis Paralysis trap you’re in, trying to figure out a way to actually know the answers to some of your questions, instead of analyzing yourself into a deeper sense of false security? That’s where the Minimum Viable Product comes into play.

Where a PSI (Potentially Shippable Increment) is about creating the opportunity to potentially ship something of value, and the MMF (Minimum Marketable Feature) is about combining those pieces of value into a collection of features that solve customer problems, the MVP is about doing the minimum amount of work your team can in order to close a validated learning loop.

In the Lean Startup methodology of product discovery, one of the most important habits to get into is the habit of validating hypotheses and creating experiments. In more traditionally risk-averse organizations, the belief that risk must be analyzed out of your product before launch leads to long lead times and, frustratingly, data-based assumptions about customer desires and wants. If we’re really good at statistical analysis, and if we have really good data about a statistically significant portion of our customers, we can do a pretty good job of formulating an educated guess about what our customers want.

But, at the end of the day, that’s still a guess.

When we’re creating MVPs, we’re intentionally building just enough functionality to ask the right questions of our customers – would you buy this product? Do these icons make sense? Does this workflow frustrate you, or does it help you find your next favorite restaurant?

At this point, we’re looking at paper prototypes, website wireframes, UI mock-ups; we’re walking across the street to the mall to show our designs to the closest people we can, just to validate quickly that we’re on the right track.

The magic in creating a good MVP isn’t in the tools or techniques, though; it’s in the discipline, when you want to analyze data from a website heat-map to figure out which color scheme works best, to instead grab some markers and paper, sketch a couple of low-fidelity solutions, and ask someone, “Which of these do you like better?”

Next, we tackle The PSI (Potentially Shippable Increment).

If your teams are struggling to get an MVP finished, it could be a sign you’re not predictable yet. Download the 8 Common Pitfalls of An Agile Transformation to help identify key areas in need of focus.

Blog

Agile in Highly Regulated Environments

By: Braz Brandt | Sep 05, 2017 | Agile Transformation, Article, Kanban, Scrum

“Individuals and interactions over processes and tools;

“Working software over comprehensive documentation;

“Customer collaboration over contract negotiation;

“Responding to change over following a plan.”

For those of us in the Agile community, the Agile Manifesto is a wonderful expression of the True North of Agile software development – empowered teams, swarming to solve customer problems by collaborating closely with people who will actually use the things we’re creating.

But for many, especially those who deliver software in highly regulated environments, the Agile Manifesto can seem downright hostile. When dealing with audit requirements and compliance, the thought of Working software over comprehensive documentation can result in Agile processes being dismissed out of hand.

With the pace of change happening in the world, that would not only be a shame, but organizations working in highly regulated environments would miss the opportunity to get ahead of competitors by leveraging Agile processes and principles.

Regulations – Prescriptive vs. Descriptive

When working in a highly regulated environment like healthcare, financial services, or dealing with reporting and regulatory audits for the US Federal government – I find it incredibly important to use a quick mental filter to understand the types of regulation my teams are working with. Broadly, I’ve found that regulations and their associated reporting requirements roughly fall into one of two types: Descriptive rules and Prescriptive rules.

Descriptive, Using Scrum

Descriptive rules seek to provide a definition of a system or process as it is so that it can increase the repeatability of that system or process. I’ve found the most frequent examples of these Descriptive rules used in internal auditing processes and also emerge in quality processes such as the ISO 9001 Quality Management standards.

A key factor in adopting Agile in regulated environments where Descriptive rules are in play is to make sure you work closely with whatever auditors you have, internal or external, who understand your documented processes. When I’ve introduced Agile processes into ISO 9001-compliant organizations, I quickly began close collaborative conversations with our auditors to make sure they understood the interactive and incremental processes we were introducing. Once we identified the gaps and differences in the documented process, I worked with our auditors to make sure our new processes were properly documented. Descriptive rules are made to be changed to meet the work, not to prescribe solutions! (SPOILER ALERT: We’ll cover those in a second.)

Working with clients who primarily deal with these descriptive rules, I frequently look at the artifacts we can provide while using Scrum. The controls provided by a strict SDLC, especially around documentation, audit-ability, and traceability, can nearly always be met through well-written Acceptance Criteria and a light hierarchy of Epics to User Stories to Tasks. Further, most Agile software tools like JIRA, VersionOne, and Rally can provide for and automate the traceability documentation from Epic to production.

Prescriptive, Using Kanban

While Descriptive rules are designed to document a system as-is or as-it-should-be to provide a reference for a repeatable, quality system, Prescriptive rules are designed to create contracts and govern behavior. In organizations and teams ruled by Prescriptive rules, the sea-change in process and procedures introduced by Scrum can seem insurmountable.

As Agilists, it’s important to remember that while Scrum may have emerged as the most popular of the Agile frameworks – to the point where most people mentally equate “Agile” and “Scrum” – it’s far from the only Agile methodology or framework. When working with teams dealing with Prescriptive rules – such as those legally mandated by Federal agencies like the Food and Drug Administration or Securities and Exchange Commission – I nearly always fall back to Kanban.

Many of us conflate Kanban with the task board our Scrum teams use to make our daily work transparent. Kanban is a powerful Agile framework designed around documenting existing processes and applying rigorous focus toward maximizing flow. Using Kanban, we can find opportunities to incrementally improve our existing teams and processes.

By applying the principles behind Kanban, teams working under the constraints of Prescriptive rules can quickly adopt the principles of Agile.

Start with what you do now;
- understanding current processes, as actually practiced
- respecting existing roles, responsibilities and job titles
Agree to pursue improvement through evolutionary change;
Encourage acts of leadership at every level;
- from individual contributor to senior management

While this isn’t an article about applying the Kanban principles and practices to your work, the practices themselves require embracing the Agile principles we know and love while also respecting the reality of the environment your teams exist within. Kanban’s practice of Visualizing the Workflow aligns perfectly with Agile’s embrace of transparency and openness; Limiting Work-In-Progress (WIP) closely aligns with the principles of simplicity and frequent delivery; Improving Collaboratively directly maps to the principle of regular reflection and improvement.

By using Kanban to map out your process, and then collaboratively look for opportunities to reduce bottlenecks and increase flow while also making and keeping process policies transparent and explicit, you can leverage Kanban to bring agility to your team and still meet Prescriptive rules and regulations.

Conclusion

When done well, Agile practices provide the means to create engaged and empowered teams who understand and embrace the need for regulations – both prescriptive and descriptive – and the means for those teams to own and optimize how their work is done while still meeting audit-ability, traceability, and regulatory requirements.

For more on our approach to building lasting business agility, you can check out our Transformation Services page.

Blog

How to Overcome Three Myths of Agile With Real Practices

By: Braz Brandt | May 23, 2017 | Agile Transformation, Article

Myths teach us concepts through a narrative. For example, before we had scientific proof that the earth’s rotation caused our sunrises and sunsets, ancient civilizations believed the sun rose and fell because it was driven across the sky on a chariot. Myths help explain things we don’t understand, which is why it’s not surprising that Agile has a few urban legends of its own. However, once you really understand and practice the methodology, these Agile myths are quickly disproven.

(more…)

Blog

The News Cycle, Breakpoints, And Agile Coaching Opportunities

By: Braz Brandt | Feb 27, 2017 | Agile Coaching, Article

newspapers, agile coaching During the first session of the Professional Coaching Course with New Ventures West, we discussed the idea that we as people live within our own self-sealed and self-reinforcing narrative. Within that narrative, our interactions with the world around us are interpreted and, through that interpretation, used to reinforce the strength of our narrative. Similar to the current political news cycles, we select the interpretation of the world that fits our worldview which further provides more sources to convince us that our narrative is “correct”.

An opportunity for coaching, and thus learning, happens when someone has a break in their narrative because of a new piece of gained information or a new event that despite best efforts will not fit in the current narrative and pops the filter bubble.

The same is true when developing software and discussing Agile coaching.

When working with a program, we expect certain output. We start our program, interact with it, and the program returns data. As we understand the purpose of our program, we document the potential world of inputs and document the expected consequent outputs. In short, we build a narrative for our software and over time will gain expectations for how our software will react given new inputs.

Our next revision of the software will have new features and functionality designed to meet a need in the world. Based on our experience with our program, we expect and design that program to react in certain ways. We release it into the world, and then the unexpected happens – someone does something that veers from the expected norm and our program breaks.

Programmers document as best we can the new inputs and the new conditions surrounding this error in our program’s narrative. We may be unable to reproduce the error – “It works for me, it must be your problem” – and we revert back to our narrative. But, as more instances of the error appear in the wild we start to collect more and more data to help us find a solution.

There are two solutions.

A narrative-reinforcing solution would be to tell our customers that they’re using our program wrong. “It wasn’t designed to do that, so don’t do it that way.” We look at this bug report and say that there’s a workaround. Our narrative is fine; the problem is with the world. We close the bug and move back to our increasingly broken narrative.

If we are good at our craft, we will start to examine the problem and start to find the real solution to debug our software.

To help us, we insert “breakpoints” into our program – places where we can stop our program and examine what’s going on when we encounter an error. A breakpoint in our software provides us with a way to stop time and look at our inputs and outputs and better understand the error in the system. Once we understand the error, we can create new pathways in our software to handle the new information and provide correct, better, or even new outputs to our customers.

Similarly, when we encounter a break in the narrative of our lives, we have choices in how we deal with the new information we’ve found.

We can hold onto our existing narrative and proclaim that the problem is with others – “I’m not the problem, you are!” or “The world just has it out for me!” – and create the pathways toward avoidance. We can choose to reinforce our narrative in the short term and hope that more breaks in our narrative don’t appear.

We can also use these breaks in our narratives as an opportunity to debug the narrative of our lives. We can insert metaphorical breakpoints in our software, and examine what’s going on with our narrative that’s producing unexpected results.

Agile coaching is the framework we can use to insert the breakpoints in our lives, to provide us with the means to examine the data we have, and create a new, a different, or potentially a better narrative. As Agile coaches, we are the debugging software of our clients’ lives. We don’t create the new software, and we don’t create the conditions that our clients incorporate into their lives. Instead, we provide the lens of reflection and guided introspection to our clients and support them in the work of debugging their narratives.

For more on our approach to building lasting business agility, you can check out our Transformation Services page.