Category: Agile & DevOps

As a Product Manager in the software industry, you’re likely all too familiar with the unique challenges of managing technical products and working with engineering teams. But despite how often you collaborate with developers and architects to deliver solutions, some persistent product management myths and misconceptions continue to create roadblocks.

These myths impact your ability to build the right product, work efficiently, and communicate effectively. And when a VP or C-suite executive holds one of these common misbeliefs, it can seriously hinder your team’s progress and value delivery.

In this post, we’ll dig into three of the most stubborn myths technical product managers face, the realities you need to know, and how debunking these myths can help you be a better PM.

Myth #1: Non-functional requirements aren’t a priority

If you’ve spent any time in a scrum meeting, you’ve probably heard developers talk about “non-functional requirements” or NFRs. They use this term to refer to aspects of the product like:

• Usability
• Scalability
• Performance
• Security

These so-called NFRs describe how the product should behave and the quality standards it must meet. But because they don’t seem to map directly to capabilities or features, many engineers view them as lower priority.

Here’s the reality: the “non-functional” label is nonsense. There’s nothing more functional and requirement-like than defining how usable, fast, and secure your product needs to be.

Take performance as an example. If your product takes ten seconds to load a simple search result, that’s clearly not performing to an acceptable level. What good is the front-end UI if the back-end can’t deliver a timely experience?

So, as a PM, don’t accept the “non-functional” misnomer.

Focusing on key user journeys and setting measurable outcomes for these abilities is just as important as delivering specific features. Make sure you incorporate these vital product aspects into planning and prioritization just like any other requirement.

Myth #2: PMs don’t need to understand the technology

Another common and dangerous product management myth is that PMs can manage products successfully without digging into the technical details. As long as you capture requirements, prioritize the roadmap, and interface with customers, you’re doing your core job. Right?

Wrong. Here’s why this hands-off approach is a myth:

First, you need awareness of how the technology impacts the customer experience. If the architecture is slow and clunky behind-the-scenes, users will encounter lag and friction points that sour their perception of your product. You have to care about that entire iceberg, not just the tip.

Second, you’ll struggle to make informed trade-off decisions during planning if you don’t understand technical constraints and options. Prioritizing technical debt cleanup may not seem valuable through a non-technical lens, but your developers will know it enables future velocity.

Finally, you can’t effectively collaborate with engineers without some fluency in the technology. You need enough technical knowledge to have intelligent conversations, ask good questions, and call BS if someone tries dazzling you with inscrutable jargon.

So, while you don’t have to be a former developer, make sure you invest time to learn the tech stack, architecture, and infrastructure for the products you manage. Doing so helps you make better product decisions and partner with engineering more strategically.

Myth #3: Leadership Doesn’t Care About the Technical Details

The third product management myth relates to communication. Many PMs assume that engineering details are irrelevant to executives focused on business strategy and revenue.

Your job is to translate between these two worlds, but you may hesitate to bring up technical considerations at the leadership table. However, dismissing technical insights as too tactical can backfire:

Technology decisions have business implications that leadership needs to weigh in on. Migrating to microservices could support scale and velocity but requires upfront investment. Great PMs proactively surface these trade-offs.

The trick is to frame technical work so it connects clearly to business value. Help executives understand how improving performance and stability—while less glamorous than new features—translates to revenue by boosting customer satisfaction and lowering support costs.

In other words, get comfortable translating tech speak into business impact and cost/benefit trade-offs. Doing so ensures you get buy-in for important technical investments.

Get ahead by busting these myths

As a PM, you may feel like you’re translating between two different languages and cultures on a daily basis. But embracing the realities behind these common myths puts you in a position to bridge that gap effectively.

Remember that:

• Managing non-functional abilities is just as important as features
• You need to understand the technology, not just the requirements
• Leadership cares about tech decisions that influence business success

Debunking myths helps you make better product decisions, collaborate with engineers, and secure stakeholder support. The result is a product that delights customers by delivering stellar experiences throughout.

Some are confused by the terms “Product Owner” and “Product Manager” What are they, and why do we need them? Must we have both? The answers are directly related to the size and scope of your project, as well as the complexity of your domain.

If you have been working within or with a Scrum team, you are likely very familiar with the role of the Product Owner, who is the person ultimately responsible for the value delivered to the customer. The Product Owner role, which may be played by a variety of people within your organization, focuses on prioritizing the work for your Scrum team and ensuring that the expectations of customers and stakeholders are met consistently.

What is a Product Manager?

As more companies embark on the journey to adopt Scrum and Agile principles into their organizations, the role of the Product Owner has become less clear because of introducing scaling. Many organizations realize that a single Agile/Scrum team is insufficient in building a large, complex solution that the customers demand and expect. Hence, the practice of “scaling agile teams” has quickly become the norm in many organizations that demand sophisticated products and services. As a result, SAFe (Scaled Agile Framework) has quickly risen to become the most popular scaling method in the world.

Within the SAFe approach, the role of the Product Owner remains relatively similar to the original definition outlined by the Scrum Guide. However, the concept of an ART (Agile Release Train) introduces a new role—the Product Manager—which may be challenging to understand for project teams that are new to SAFe. The rise of SAFe, fueled by a need for multiple Agile teams to collaborate on a single solution, requires the Product Manager to provide strategic insights into the customers’ needs.

While most ARTs will likely have a small number of teams, each having a dedicated Product Owner, the Product Manager is an essential role that will ensure the individual teams work together in a synchronized manner towards fulfillment of the greater vision. The Product Manager will help the teams stay aligned in terms of priorities and value delivered to the end customer by focusing at the Release Train level.

Do you need BOTH Product Manager and Product Owner?

One question that I have encountered many times is, “If I can only hire a Product Manager or a team of Product Owners, but not both, which should I choose?”

While launching the team with a Product Manager and no Product Owners is not ideal, it could be managed as an incremental step towards a mature, effective train. Most new ARTs have a tendency to launch without all the roles filled. One strategy is to assemble Agile/Scrum teams that are most critical to the overall solution first, so that they can deliver value as quickly as possible. Even if you have the financial resources to staff up the entire train, more than likely, recruiting and assembling the teams to support the train will require an incremental approach.

So, do you absolutely NEED both roles in order to operate an ART successfully? Yes, especially if your ART comprises five or more teams. Without effective Product Owners to manage the details, the train is at risk of fragmentation. Having skilled Product Owners and Product Managers will provide a cohesive, organized approach that gives your train the best chance for success.

For help understanding and carrying out the roles of the Product Owner and Product Manager in a scaled Agile environment, reach out to our Agile product coaches.

The sprint is a container for Scrum events. It contains all the work a Scrum team will do to create an increment (which is formed when it meets the quality measures required for the product as defined by the team’s definition of done). The sprint is the heartbeat of Scrum. 

In her blog, 5 Powerful Things About the Sprint, Stephanie Ockerman covers how the sprint provides:

• Focus (where ideas are turned into value)
• Predictability (deliver a ‘done’ increment of work)
• Control (to inspect an increment and adapt)
• Freedom (for Scrum team to self-manage, collaborate, and experiment)

The first event of a sprint is sprint planning, which lays out the work to be performed for the sprint. The output of sprint planning is the sprint goal—a concise statement of what the team intends to accomplish during the sprint—and the product backlog items selected for the sprint, also known as the sprint backlog.

Why create a sprint backlog?

The Scrum Guide describes the sprint backlog as a plan by and for the developers. It is a highly visible, real-time picture of the work that the developers plan to accomplish during the sprint in order to achieve the sprint goal. 

The sprint backlog is solely owned by the developers, but the Scrum team collaborates over the work on it. For example, if the developers believe the work in the sprint backlog needs to change to better meet the sprint goal, developers would collaborate with the product Owner when making that decision. The sprint backlog is still owned by the developers.

The sprint backlog contains a commitment—the sprint goal—which provides the ‘why’ for the developers. It enhances transparency and focus against which the team can measure progress.  The sprint goal helps to answer questions like:

• Why is it worthwhile to run this sprint? 
• What assumptions/hypotheses do we want to test?
• What is it we are trying to achieve? 
• How does it get us closer to our product goal? 

How to create a sprint backlog

During sprint planning, developers collaborate with the Product Owner to craft the sprint backlog, which describes how they intend to deliver the increment. The sprint backlog is an actionable plan for delivery.

The developers decompose work (often expressed as user stories) into smaller items (often expressed as tasks). Tasks are small items of work that can be completed in a short timeframe (typically one or two days). 

Tasks are more precise, in detail and in scope, than user stories. When creating tasks, avoid vague statements such as ‘coding’ or ‘implementation’, thinking that you can just refer to the parent user story for the details. Instead, create meaningful descriptions of the tasks to make the scope of work very clear.

A blog by Victor Dantas offers a very good example of how to break a story down to a task level for a requirement for a web app: 

As a registered user, I want to log in with my username and password so that the system can authenticate me and I can trust it.

And with the following acceptance criteria:

“Given that I am a registered user and logged out… if I go to the login page and enter my username and password and click on Log in, then the data associated with my user should be accessible.“

By getting all the developers together in sprint planning to brainstorm on what is needed, you’re likely to hear things like:

• “We need a new UI element for Sign-up and Login”
• “We need to develop encryption functionality for the password”
• “We need to create a table in the database for user information”

Now, to do things in a more structured way, let’s ask the developers:

How can we break this down into executable, scope-bound tasks? Here, the team may agree on the following tasks for the user story:

• Define Sign-up/Login form style and develop new CSS class
• Develop HTML and Javascript Sign-Up/Login presentation layer code
• Develop Javascript sign up form validation code 

Now you can see how the sprint backlog gets formed and grows during sprint planning.  However, during sprint planning, you will not create the perfect plan. The sprint backlog is an adaptive plan by and for the developers. It is a highly visible, real-time picture of the work that the developers plan to accomplish during the sprint in order to achieve the sprint goal. 

Consequently, they will update the sprint backlog throughout the sprint as they learn more and, as such, they create, re-order, add more detail, and delete as needed. 

Sprint backlog misconceptions and anti-patterns

Developers cannot change the sprint backlog during the sprint as it is a commitment

The myth is that the sprint backlog is fixed during the sprint and that developers must implement all the work items in the sprint backlog because they have committed to deliver them. If not, the sprint is a failure. Changes to the sprint backlog are not allowed and no work can be added or removed from it, as this creates a lack of focus and there is a risk of ‘goal’ creep. 

That’s not the case. 

The sprint backlog should not be static

The sprint goal is an objective set by the Scrum team during sprint planning. The sprint goal describes what the Scrum team wants to achieve during the sprint (to test an idea, hypothesis or run a test) and how it intends to be closer to the product goal.

Remember, Scrum was created to ‘help people, teams and organizations generate value through adaptive solutions for complex problems. The Scrum team—more particularly the developers who craft the sprint backlog—cannot predict the future and create the perfect plan. Complex work is highly unpredictable, so they cannot set a detailed plan in stone during sprint planning. The developers should refine the work that needs to be done based on what they learn once work begins. 

For example, let’s assume the developers create a new feature and change several existing features during the sprint. All this needs testing, regression testing, and code refactoring, which they expected; they could not anticipate the effort and amount of work required. So, the developers will need to add work items to the sprint backlog. Nevertheless, they remain committed to the sprint goal.

The sprint backlog changes based on ‘inspect and adapt’

The sprint backlog supports empiricism—the idea that knowledge comes from experience and deciding based on what the team observes (The Scrum Guide 2020). The Daily Scrum gives developers an opportunity to inspect and adapt their progress to the sprint goal and make any adjustments to the sprint backlog. 

A metric developers can use in a Daily Scrum to help support empiricism and manage the sprint backlog is Work Item Age. Work Item Age looks at current active work (the amount of elapsed time between when a work item started and the current time). Work Item Age is a leading indicator related to unfinished work items. It is a great metric; it enables transparency to which work items are flowing well and which are stuck in the mud and not progressing as expected. Using Work Item Age in combination with cycle time can help developers to focus on those items of work which are at most risk of missing the teams’ service level expectation, and make the necessary adjustments.

The Product Owner controls the sprint backlog and therefore can pull work items in and out whenever they feel like?

If a Product Owner pulls and adds work items into the sprint backlog at will, and developers just shrug and continue working, the developers are no longer committed to the sprint goal and lack ownership of the sprint backlog that is rightfully theirs. They have just become a feature factory and no longer align with a sprint or product goal, or value creation.

Developers own the sprint backlog and must maintain accountability

The Scrum Guide states that developers are always accountable for:

• Creating a plan for the sprint—the sprint backlog
• Instilling quality by adhering to a definition of done
• Adapting their plan each day toward the sprint goal
• Holding each other accountable as professionals

The Product Owner owns the product backlog

The Product Owner is accountable for effective product backlog management, which includes:

• Developing and explicitly communicating the product goal
• Creating and clearly communicating product backlog items
• Ordering product backlog items
• Ensuring that the product backlog is transparent, visible, and understood

To learn more about the sprint backlog and other important aspects of Scrum, check out our popular FAQ, What is Agile and What is Scrum?

In a new business where a lot of things are unpredictable, a startup proof of concept can be an essential tool for validating product ideas. 

In order to make your concept thrive, you will need to calculate and define its viability and feasibility. You need insights on what you need to implement in terms of technology, finance, infrastructure, etc. to bring the idea to life. You also need to prove your concept is technically feasible and desirable to investors and other stakeholders.

That’s where you will need to develop a proof of concept (POC). Join us as we explore some of the ways to write a proof of concept and how creating it can help a startup validate its product and improve the overall chances for future investment and sustainability over time. 

What is a Proof of Concept

Before implementing any startup, there is a need for solid and undeniable proof of whether the idea will work or not. A POC or proof of principle fits in here. It helps you decide whether you can proceed with the hypothesis or not. 

Basically, a POC for a startup is a presentation of the proposed product and its potential viability. POCs describe the functionality of the product, including its general design or specific features, and how feasible they are.

A POC can prove that building the proposed solution, program, product, feature, or method is achievable. POCs further allow decision-makers, investors, and even users to explore the potential of the idea, giving them a glimpse of the bigger picture or the situation once the company launches the product.

Types of Startup Proofs of Concept

POC for a startup is a type of demonstration or prototype that shows how a new technology or business model can be implemented and tested. A POC can be either technical or business-based.

Technical POCs

Technical POCs are useful for testing new technologies, evaluating feasibility, and gauging the interest of potential customers. POC in technology can also help developers learn how to build something from scratch and identify any potential problems with their designs.

There are three main types of technical POCs:

• User Experience (UX) Proofs: UX proof is a simple demonstration that a product or service can be used by real people. This might involve testing out the design on dummy users or simulating user behavior in an analytical way.
• Product Proofs: A product proof is a more complex demonstration that the product or service can be developed and launched successfully. This might involve building a functional prototype, completing customer interviews, or conducting market research.
• Prototype Proofs: A prototype proof is the most complex type of proof of concept for a startup and requires the most time and investment to produce. It is typically an early version of the final product that has been simplified for testing purposes.

The developers at Cprime can help entrepreneurs who are looking to build a tech product to validate their idea and assess the technical requirements needed and define the tools and resources necessary to build the product.

Business POCs

Business POCs are especially important for testing new business models in the real world. They can help entrepreneurs determine whether their idea is viable, identify potential market niches and gain feedback from actual consumers. Furthermore, they can help entrepreneurs validate their assumptions about customer behavior and marketplace trends.

In many cases, both a Business and Technical POC may be needed. For example, to effectively test out a business model that revolves exclusively around a tech product. Imagine you want to launch the next Uber. You would want to put together a Business POC to establish that there’s room in the ride share market for a new contender, and that your concept is different enough to compete. But you’d also want to develop a Technical POC to ensure the app you’re envisioning is feasible.

Benefits of Validating Product Ideas With a Proof of Concept

While startups are all very different, 90% of them have one thing in common—they fail. One of the things startups can do to improve their chances of being in the 10% is to develop a POC. The benefits of a successful POC are long-lasting and can touch on every department within the startup, from product to sales.

To the untrained eye, a POC may feel like an extra step in the process, but developing one can help increase your odds of success. It can:

• Help you assess risks: Creating a startup proof of concept can help you and your team identify potential risks and issues before a product goes live. You can then decide whether to make changes to the product or go back to the drawing board.

• Get your team on the same page: Proofs of concept can help align your team and introduce them to your prospective product. For example, a POC can show your sales and marketing teams the unique selling points of your product and who your competition is. You can also use a POC to get feedback from employees who may not have been involved in developing your product.

• See if your idea can adapt and grow: A proof of concept can help you see how scalable your idea is. As an example, would it be easy to mass produce in the future? What would you do if you needed to add additional features for new markets?

• Get investors: Finally, a POC can be great to showcase to potential investors. Investors will want to see that you’ve done your research before they provide you with funding, and a POC is a great way to do this. 

How to Write a Proof of Concept

The goal of a startup proof of concept is to test the viability and feasibility of an idea. Once the startup POC has been completed, it can be used as part of the business plan in order to assess whether there’s potential for this idea to become a reality. If all goes well, then the next stage, which involves further development, can begin.

Basically, there are five essential stages of a startup proof of concept that teams can follow, from developing the idea to firming it up and presenting it to investors.

Stage 1: Conduct research and development

When you write a proof of concept, the first thing that comes into mind is Research and Development (R&D). The team needs to conduct extensive research around the history of similar work across the globe.

If there is none, the next step should be to analyze existing guides, PDFs, scholarly articles, or tutorials that would act as a key point of reference for the team.

If it is not available in the market, consider your idea to be a novel one that can mark you as a leading pioneer.

It may take time to build a POC. It may sometimes seem infeasible. But challenging the team’s technical abilities is the key here. Setting your own standards can lead to success when a business is still in the development phase.

Stage 2:  Specify the need for your idea

Once you are done with research around your idea, it is time to specify who needs it and why. Consider listing user personas your product will target and their pain points to understand their needs.

However, don’t just assume things. As you collect evidence at this stage, interview potential users and ask them questions regarding what they desire and need to solve the problem being addressed with your project. To make your proof of concept document look authentic, consider conducting in-depth interviews or online surveys.

Stage 3: Ideate the right solution

From the sample group’s answers, you can now start brainstorming with your team for the right solutions to customer pain points, keeping in mind that they should also be feasible and within the company’s capacity.

The team should then assess each brainstormed solution according to the likely costs, timeline, technologies needed, required operational capacities, competition, resources, and other factors.

Additionally, to firm up the proposal, you should discuss how your solution can support the fulfillment of the organization’s or stakeholders’ goals.

Stage 4: Create a prototype and test it

Once you have come up with a feasible idea, you should create a prototype based on the decided requirements, features, and solutions.

Your team must let the individuals in their sample group test the completed prototype so they can quickly determine whether the product truly addressed the pain points shared by the group.

Testing it with the same group enables you to document their feedback more easily, which is essential to the next step.

Stage 5: Gather and document feedback

During the prototype testing, you must gather and document the sample group’s feedback about their experience, their reactions, and any other valuable details, including what they think of the user interface.

The gathered feedback lets you initially verify the usability and feasibility of the solution. It also informs the team of any needed improvements to the proposed product and gives significant insight for other relevant actions moving forward.

Stage 6: Present POC for approval

With the concept tested and improved based on the feedback, you can now start the last proof of concept stage and prepare your presentation for the stakeholders.

You must present, among other things, the pain points that the product solves, features that address those problems, and technologies integrated to demonstrate the value of the idea.

You should elaborate on the product development and project management components, which you should also note in your project tracker.

These include clearly defined success criteria or project management metrics, evaluation measures, timelines, next project management plans, resources needed, and other aspects discussed earlier.

Once you’ve successfully presented the idea and persuaded the stakeholders to approve and invest, you can begin to implement it.

Wrap-up

Ultimately, startups looking to be a part of the successful minority need to do all they can to stand out and differentiate themselves from competitors—and that means proving their product has a market need and works on a large scale.

A POC helps startups see if a proposed idea is practical and attractive for the target market and achievable for the company. Through the business POC, you can explore the planned components and functionalities of the ideated product, along with the costs, resources, and capacities required to make it work.

In order to further increase the chance of success, startups should not question whether or not they should run a POC, but rather see how they can increase their capacity and create more POCs with more companies in more verticals in hopes of defying the odds.

The custom development experts at Cprime are well aware of the need for proof of concept. We also know how to create attractive prototypes to use for further user testing or attracting investors. Cprime developers can validate the product at the idea stage to see if it’s worth further developing and we can continue to collaborate to develop your product and launch it for success.

Ready to get started? Contact our experts to schedule a consultation.

To quickly summarize Part One of this two-part series, we are looking into the recently released Flow Metrics within the updated Scaled Agile Framework® (V6.0) which offers interesting insights into tracking and monitoring flow of work through your Agile Release Train. 

In Part One, we covered the first three of the six metrics:

• Flow Distribution
• Flow Velocity
• Flow Time 

Now, we will wrap up this series with the latter half of this collection of metrics, which will include 

• Flow Load
• Flow Efficiency
• Flow Predictability

As a refresher, many Agile concepts originated from the Toyota Manufacturing / Toyota Production System (TPS), considered to be the foundation for today’s Lean manufacturing processes. Hence, we will use this comparison to help illustrate how these metrics may map to building hardware and software solutions within an Agile Release Train.

The 6 Flow Metrics

Here’s another review of the six flow metrics that SAFe® recommends.

Continuing where we left off in Part One, we will now focus on Flow Load. 

Flow Load

If we look at the definition of this term, we realize that this seems to resemble another popular Lean-Agile concept: Work In Progress (or WIP). In a flow-based system, often referred to as a Kanban system, the WIP limit provides a throttling mechanism to minimize over-burdening the system (or the staff) by controlling the total amount of work that an individual (or a system) can perform‌ at once. 

Flow Load is essentially the same idea; by tracking the total number of work items in play, we can glean interesting insights into the health of the system. 

Using the automobile manufacturing example, the load can represent the total number of cars currently moving through the assembly line at a time, which may vary depending on the seasonality, time of the day, etc. More than likely, we are going to need to look at multiple metrics in order to make sense of the data. We will touch on that a bit later.

Flow Efficiency

The fifth metric is Flow Efficiency, which measures the amount of value-added work (or productive work) as a function of total time spent. 

Many trains struggle to track this metric because it is often difficult to distinguish good use of time versus poor use of time. For example, is “big room planning” or any other meetings that may be perceived as administrative work considered value-added work? That may be debatable. In order for this metric to have meaning in your organization, your team may need to clarify what is actually considered “value-added work”. 

Within the car manufacturing world, any idle time is non-value added work; for example, the time it requires for a technician to walk from the car to the tool bench to retrieve a tool is usually considered “travel time”, and is not value-added. Even if each trip only requires a few seconds, over ‌millions of cars, those seconds add up and will lead to lost overall productivity that can equate to significant lost revenue.

Flow Predictability

Lastly, we have Flow Predictability, which may seem familiar. The Predictability metric has been part of SAFe for several years, even if it was not specifically referred to as a “Flow” metric. 

The concept of predictability is often difficult to grasp because very few organizations are effective at tracking this metric. The ability to produce results consistently should be the goal of any Agile Release Train, and this metric will enable trains to monitor how they are doing over time.

Putting it all together

Now that we have a better understanding of each of the six flow metrics, what are we supposed to do with them? How do we know if the train is running optimally or is in serious trouble? 

In isolation, it is difficult to make a judgment on the state of the system by looking at any single metric at a point in time. We must have a reference point against which to compare in order to determine whether your train is taking on too many work items simultaneously, or not enough. This is where we need to pair the flow metrics to draw a useful and intelligent conclusion about how your train is operating.

For example, by looking at the relationship between velocity, load, and efficiency, we can put together a picture of what is going on with your train. Is the train running effectively, or is it heading for disaster? Even if you are tracking all six metrics rigorously, you will probably need to think about what “good” looks like for your specific context. To achieve this, consider the following:

1.     What does the customer truly care about?
2.     What can you do differently to move the needle on those things that are important to the customer?
3.     How can your teams use metrics to improve transparency and create a sense of purpose?

There are no right answers to these questions. You will need to think about these within your own context to decide which of the metrics make sense for you. It is possible to apply only a subset of the six metrics and still get value out of them. 

If you aren’t sure where to start, engage your train and encourage your teams to come up with their recommendations; if they are given the opportunity to define meaningful metrics, they are much more likely to provide quality data and apply them effectively.

And of course, if you need any help with this or other SAFe concepts, consider our catalog of SAFe-related learning courses and certification programs.

If you are applying SAFe® (Scaled Agile Framework®) or are considering doing so, you are most likely aware of at least some of the key updates to the V6.0 release. One of the most critical additions to this update is the concept of “flow”. 

What is Flow in SAFe 6.0?

Scaled Agile’s official definition of Flow is as follows:

“Flow is characterized by a smooth transition of work through the entire value stream with a minimum of handoffs, delays, and rework. In SAFe, we consider flow to be present when teams, trains, and the portfolio can quickly, continuously, and efficiently deliver quality products and services from trigger to value.” (© Scaled Agile, Inc.)

SAFe 6.0 provides a detailed account of the various flow concepts and metrics that you should consider when implementing SAFe. While this information is very thorough, many practitioners I work with expressed an interest in more specific examples related to how to deploy these metrics. Hence, I thought it might be worthwhile to illustrate the use of these metrics through a simple, everyday example that most of us should be able to relate to so we can gain a better understanding overall.

An example from manufacturing

Because of the level of detail that will be covered, it made sense to split this into a two-part series to ensure we provide adequate coverage of all six of the flow metrics that are recommended by SAFe 6.0. Let’s first go over the details of a fictitious project which we will use to clarify the flow concepts.

When I facilitate training sessions for my clients, I often think about a common example that is not specific to any industry or technology so that I can try to reach as many of my students as possible and help them connect to their own contexts. Although there may not seem to be a clear alignment to Agile principles and practices, I often use manufacturing concepts as a backdrop to explain Lean-Agile concepts. For this exploration of flow metrics, we will use the concepts of automobile manufacturing to clarify the ideas.

The Toyota Manufacturing / Toyota Production System (TPS) is considered the foundation for today’s Lean manufacturing processes. Hence, we will connect to SAFe’s flow metrics by inspecting how these may map to building hardware and software solutions within an Agile Release Train.

The 6 Flow Metrics

Let’s first look at the 6 Flow Metrics that SAFe recommends.

Flow Distribution

The key concept behind monitoring the distribution of different types of work is to understand how long-term and short-term objectives are being supported. For example, work may include infrastructure/enablers, sustainment/maintenance, and new capabilities/features. If one type of work is dominating the overall distribution, the risk to the overall health of the product life cycle may be elevated. 

Using an automobile manufacturing assembly as an example, the assembly line will typically contain a variety of car models that are in distinct stages of the overall assembly process. 

Within this context, we may want to see how much of the resources (human capital and technological assets) are deployed for the development of the chassis, painting, electronics, etc. 

From another perspective, at the portfolio level, it may be worthwhile to examine how funding is allocated to research and development for future car models or manufacturing of current-year models. 

By looking at the flow distribution of how work is executed for various types of work, we can assess trends (i.e. peaks, valleys, outliers, etc.) which will enable the team to make informed decisions on potential shifts in the allocation.

Flow Velocity

Using the automobile manufacturing example, flow velocity is easy to explain—it is simply the number of vehicles produced within a time horizon. For example, 1,000 cars per day, or something to that effect. In your world, depending on what type of product or service you are building, this metric may not be as simple to measure, especially if you are not shipping a physical product. However, if you are producing a service, you will probably depend on some type of technology to support that service, which I would suspect to be a digitally enabled system, in which case you can measure the number of features and/or functions that your team is deploying within a specified timeframe. That can also qualify as flow velocity.

One key thing to keep in mind is that the purpose of collecting this data is to evaluate the performance of the team in terms of productivity and efficiency. Trends will be valuable to determine whether the overall performance is improving or degrading over time.

Flow Time

In delivering products or services to the customer, nothing is more noticeable than speed; customers can often compromise on the complexity and sophistication of a solution, but they are almost always eager to receive something as quickly as possible, no matter how incomplete it might be. 

We need to keep in mind that this does not mean we can put low-quality goods into the hands of the customers and expect them to be happy. Faster delivery means we will provide a high-quality product, but possibly without all the special features that may be perceived as “nice-to-have”.

Flow time is one method of measuring how much time your team needs to put that capability into your customers’ hands. It is a trending metric that allows you to determine if your team is improving its efficiency (reduction in time), stabilizing (by a plateauing effect) or even degrading (taking more time to deliver value). 

Within the context of automobiles, flow time can be measured as the number of hours/minutes required to build a complete, functioning car that is ready to be driven.

In Part 2 of this Deep Dive, we will cover the remaining three Flow Metrics:

• Flow Load
• Flow Efficiency
• Flow Predictability

In the meantime, if you need any help with this or other SAFe concepts, consider our catalog of SAFe-related learning courses and certification programs.

If you have been working on projects for any amount of time, you will probably have come across a variety of metrics that are required by your organization or chosen on your own to help you track those projects. If you are like me, you have led projects and are familiar with metrics such as CPI or SPI, and may have also dabbled with other metrics, such as velocity or throughput. 

As more organizations try to stay on top of the latest trends for tracking project health, there seems to be a rise in the complexity of the various ways we try to measure organizational or team health, and they seem to get more confusing as well. I wrote this article to dispel some of this confusion so that project workers can decide what makes the most sense in their specific situations.

What are the differences between KPIs, OKRs, and Agile metrics?

Before we can compare the metrics, let’s first clarify the definition for each.

•       OKR – Objectives and Key Results
•       KPI – Key Performance Indicators

Summary of key metrics

Which metrics do you need to track?

One of the most challenging aspects of metrics is that it is easy to lose sight of the reasons why your organization is spending money to track this data. There are many reasons for this, and one of the most common behaviors is related to the reward system being used to measure performance at either the team or individual levels. We have all seen situations where metrics are used to give out monetary incentives, which often leads to unintended behaviors and consequences. 

One of the key things I try to remind teams I coach is to measure what matters, because what you measure ultimately influences how people behave. Even if there are no direct financial rewards tied to the measures, people are motivated by achievement and want to feel good about what they do. 

So how do we choose the right metrics to inspire our teams to perform at their highest level, yet not compromise their values or ethics? Here are a few ideas to consider:

1.     Measure what they do day-to-day
2.     Ask the team to define what they think “good” looks like
3.     Inspire the team to focus on continuous improvement

Connecting the dots between different layers of metrics

Even if your team has deployed a sophisticated system for tracking metrics, your work may not be done yet. 

We know that there are multiple levels of metrics within an organization, and team level is only one of those layers. One of the worst things we can do as leaders is to deploy metrics that have no direct relationship to the work that the team is doing. For example, it would not make sense to set a goal for a team of software developers to increase sales by 25%. That said, if you can somehow make a connection between the quality or productivity of their work and sales figures, then you can influence this team to perform differently.

If your organization desires to become the largest provider of a specific service or product, you must define how the individual contributors and teams will make an impact through their daily activities. An example of this might be the defect rate. If a team can improve the organization’s ability to gain more market share or increase revenue by increasing the product quality (i.e. reducing defect rate), this would provide a direct correlation from the team to the end objective.

One method of achieving this is to tie the team metrics to KPIs at the project level. Then, you can align your KPIs to the OKRs at the highest strategic level of your organization. This will probably take a bit of work to implement, especially if your organization is not accustomed to this approach.

How to tell if these metrics are providing benefits?

In terms of the impact that is being made by the use of metrics, typically trending is a good technique to help evaluate the direction of the team’s performance. 

For example, if the defect rate is increasing over a period of several months, that’s clearly not a positive state. However, if this trend is flat, that may signal either a positive (i.e. high predictability and consistency) or a negative (lack of improvement). Trends in your data will tell a story, but you must set the foundation to make sense of this story, determining as early as possible what “good” looks like. 

With all the advancements in software tools and the ability to collect massive amounts of data, it is increasingly important to take time to make sense of the data. This will require analytics and potentially the aid of artificial intelligence to determine the meaning behind the data. If you have a good idea what “good” looks like, you can compare the real data to your desired outcomes and assess how things are going.

For more guidance on how to best measure the efficacy of your Agile practice, dive deeper with the article, Agile Metrics – How Do They Boost Team Performance?