What is Fitness for Purpose

By Matt Philip

Lately, I’ve talked a lot about fitness for purpose and fitness criteria. Fitness for purpose is an evaluation of how well a product or service fulfills a customer’s desires based on the organization’s goals or reason for existence. It is the ability of an organization or team to fulfill its mission. This notion derives from the manufacturing industry that purportedly assesses a product against its stated purpose. The purpose may be that as determined by the manufacturer or, according to marketing departments, a purpose determined by the needs of customers.

David Anderson one of the most foremost authorities on Lean and Kanban, emphasizes that fitness is always defined externally:  it is customers and other stakeholders such as governments or regulatory authorities that define what fitness means.

Fitness criteria are then metrics that enable us to evaluate whether our product, service or service delivery is “fit for purpose” in the eyes of a customer from a given market segment. As Anderson notes, fitness criteria metrics are effectively the Key Performance Indicators (KPIs) for each market segment, and as such are direct metrics.

Anderson also states that every business or every unit of a business should know and understand its purpose. For example, what exactly are they in business to do? Hint: It isn’t simply to make money. If all they wanted to focus on was making money, they’d be investors and not business owners. They would spend their time managing investment portfolios and not leading a small tribe of believers who want to make something or serve someone.

So why does the firm or business unit exist? If we know that we can start to explore what represents “fitness for purpose.”

For me, fitness is something that, like user stories, can be understood at varying levels of granularity. Organizations have fitness for their purpose — “are we fit to pursue this line of business?” — and teams (in particular, small software-delivery teams) also have fitness for their purpose — “are we fit to deliver this work in the way the customer expects?”

Therefore, the first step in improving is understanding what makes the service you provide fit for its purpose. Fitness for purpose is simply an evaluation of how well an organization or team delivers what it is in the business of (its purpose). Modern knowledge-worker organizations like Asynchrony Labs often focus on concerns like product development or technical practices, sometimes overlooking service-delivery excellence. But service delivery is a major reason why customers choose a firm. That’s why it’s important to attempt to understand and define each project team’s purpose and fitness for that purpose, at the project kickoff in a conversation with our customer representatives.

Two Components of Fitness

Fitness for purpose has two components: a product component and a service-delivery component. That is, the customer for your delivery team considers the product that you are building (the what) — and did you build the right thing? In addition, in what way did you deliver it (the how), and how reliable were you when you said you’d deliver it? How long did it take you to deliver it? We have useful feedback mechanisms for learning about the fitness of the products we build (e.g., demos/showcases, usage analytics), but how do we learn about the fitness of our service delivery? That’s the service-delivery review feedback loop, which I will write about later.

Fitness Criteria

Fitness criteria are metrics which enable us to evaluate whether our service delivery is “fit for purpose” in the eyes of a customer from a given market segment. These are usually related to, but not limited to, delivery time (end-to-end duration), predictability and, for certain domains, safety or regulatory concerns. When we explore and establish expectation levels for each criterion, we discover fitness-criteria thresholds. They represent the “good enough” or the point where performance is satisfactory. For example, our customer might expect us to deliver user stories within some reasonable time frame, so we could say that for user stories, our delivery-time expectation is 85% of the time we complete them and will be within 10 days. And we might have a different expectation for urgent changes, like production bug fixes.

Fitness criteria categories are often common; nearly everyone cares about delivery time and predictability, but not so much for the actual thresholds for them. While some are shared by many customers, the difference in what people want and expect allow us to define market segments and understand different business risks. Fitness criteria should be our Key Performance Indicators (KPIs), and teams should use those thresholds to drive improvements and evolutionary change.

Who Defines Fitness?

As opposed to team-health metrics, like happiness or pair switches, fitness and fitness criteria are always defined externally: Customers and other stakeholders define what fitness means. That means you cannot ask the delivery team to define its fitness. They cannot know because they are not the ones buying their service or product. We should be asking customers the following: “What would make you choose this service? What would make you come back again? What would encourage you to recommend it to others?”

These are a team’s fitness criteria and these are the criteria by which a good software development shop should be measuring the effectiveness of its teams’ service delivery. Then they’ll be improving toward the goal and the greater fitness for the customer’s purpose, both as an organization and as individual delivery teams. By integrating fitness-for-purpose thinking into everything we do, we will create an evolutionary capability that will help us sense changes in market needs and wants and what those different market segments value. As a result, software professionals can continue to thrive and survive in the midst of overall growth and rising market complexity.

Key Differences Between Fitness Metrics and Health Metrics:

Case in Point

Let’s use food as an example. Consider this: Is a restaurant in the product or service-delivery business? That’s a trick question. The answer is “both.” As a customer, you care about the meal (product) but you also care about the way you have it provided (service delivery). And those needs always vary depending on what you want. If you want cheap and fast, like a burger and fries at a fast food restaurant, you may have a lower expectation for the product, but a higher one for delivery speed. Conversely, if you’re out for fine dining, you expect the food to be of a higher quality and are willing to tolerate a longer delivery time.

However, you do have some thresholds of service even for four-star restaurants; for example, if you have a reservation, you expect to be seated within minutes of your arrival. And, you expect a server to take your order in a timely way. If you don’t have a reservation, the maître d’ or hostess will perhaps quote you an expected wait time; if it’s unacceptable, you’ll go elsewhere. If it’s acceptable but they don’t seat you in that time, you are dissatisfied. The service delivery was not fit for its purpose, which is to say the reason why you chose to eat there in the first place.

A Software-Delivery Example

The restaurant experience is actually not too dissimilar from software delivery. The customer expects software (product) but also expects it on certain terms or within certain thresholds (service delivery). A team works hard to deliver the right features and demonstrates them at some frequency; at the demo, the team likely will explicitly ask “is this what you wanted?” What’s often missing is the “are these the terms on which you wanted it?”

Whether in the demo or a separate meeting, we need to also review service delivery. This is where we look at whether our service meets expectations: Did we deliver enough? Reliably enough? Respond to urgent needs quickly enough? The good news is that we can quantitatively manage the answers to these questions.

Using delivery times, we can assess whether the throughput is within a tolerance. One team used a probabilistic forecast and found that their throughput was not likely to help them reach their deadline in time. Conversely, another realized that they were delivering too fast and could stand to reallocate people to other efforts. Also, for instance, when we set up delivery-time expectations (some people call these SLAs), like delivering standard-urgency work at a 10-day, 85% target, we can then make decisions based on data rather than feelings or intuition (which have their place in some decisions but not others). These expectations needn’t be perfect or “right” to begin; set them and begin reviewing them to see if they are satisfactory.

With that in mind, and before wrapping up, let me leave you with a few key takeaways and summary points from this topic:

• The first step in improving is understanding what makes the service you provide fit for its purpose.
• Fitness is always defined externally, typically by the customer
• Fitness for purpose has two components: a product component and a service-delivery component
• Fitness criteria are metrics that enable us to evaluate whether our service delivery and/or product is fit for purpose
• Of the two major categories of metrics, fitness criteria are primary, whereas health or improvement metrics are derivative
• Examples of service delivery fitness criteria are delivery time, throughput and predictability

In the end, let us understand that having an explicit review of fitness criteria, especially for service-delivery fitness, is a vital feedback loop for improving. Rather than having the customer walk away dissatisfied for some unknown reason, we can proactively ask and manage those expectations and improve upon them. Often, these are the unstated criteria that ultimately define the relationship and create (or erode) trust; discover them and quantitatively manage them.