Author: Elizabeth Walsh

Developed in 2011, the Scaled Agile Framework®, or SAFe, expanded on the traditional Agile manifesto by integrating essential concepts from the Lean methodology.

According to SAFe developers, organizations can achieve a myriad of benefits by leveraging this framework, including:

• 20–50% increases in productivity
• 30–75% faster time to market
• 10–50% increases in employee engagement

Suppose your Executive Action Team (EAT) wants to adopt a Lean-Agile mindset and unlock these project management benefits. In that case, it must first master the art of creating and pitching an Epic Hypothesis Statement (EHS).

Creating a great EHS and selling your stakeholders on your bold idea is essential for achieving business agility and streamlining development processes. Conversely, failing to do so will obstruct your continuous delivery pipeline and prevent you from efficiently developing working software.

With so much riding on your EHS pitch, it’s critical that you get it right. To support these efforts, we’ve created this helpful guide to pitch your Epic Hypothesis Statement to your EAT.

What Is an Executive Action Team (EAT)?

The SAFe framework includes several cross-functional teams, including the Executive Action Team (EAT). This team leads organizational change and removes systemic growth impediments. The EAT is also the audience that will hear your EHS and decide whether they should put it into the Epic backlog.

One of the basic premises of the Lean-Agile mindset is that change must start at the top. A successful EHS pitch will intrigue and captivate stakeholders on the Executive Action Team and encourage them to embrace your Epic Hypothesis Statement.

What Is an Epic Hypothesis Statement (EHS)?

The Epic Hypothesis Statement (EHS) is a detailed hypothesis that describes an Epic or a large initiative designed to address a growth roadblock or to capitalize on a growth opportunity.

Epics are always significant in scale and traditionally customer-facing. They should support a company’s current needs while preparing it to navigate future challenges.

While the Epic Hypothesis Statement itself will be quite detailed, the EHS is usually presented to the EAT like an elevator pitch: brief, clear, and concise.

Key Components of an Epic Hypothesis Statement

The Epic Hypothesis Statement expands on the raw concept presented during the funneling phase of the Portfolio Kanban system. Initially, the idea comprised a single concept, such as “adding self-service tools to the customer’s loan management portal.”

As the Epic Owner, you must hash out this basic idea into a fully developed initiative. If your hypothesis proves correct, you’ll also need to outline the expected benefits the organization will experience. Additionally, your EHS must include leading indicators you can use to document progress toward hypothesis validation.

Let’s build on the self-service tool example.

If you wanted to create an EHS, you could expound on the basic premise of adding self-service tools to the customer-facing loan management portal. When explaining your initiative, identify the specific tools you plan to implement and how they add value to the customer journey.

For instance, expected benefit outcomes for this initiative might include:

• A reduction in customer service calls
• Better customer engagement and satisfaction
• Improved brand image

Admittedly, some benefits would be difficult to track. Therefore, you must carefully incorporate complementary objectives and key results (OKRs) into your EHS, as doing so will help you sell your EAT on the value of your EHS.

Pitching Your EHS

Once you’ve completed your Epic Hypothesis Statement, it’s time to pitch it to the EAT. Here are some musts if you want to engage your stakeholders.

Use Powerful Visuals

The Portfolio Kanban system and the Agile manifesto emphasize the importance of visualization. Incorporating visuals into your EHS pitch shows that you fully grasp these methodologies and helps your audience better understand your hypothesis.

Explain the Applicability of Your OKRs

There should be a clear connection between your proposed initiative and your selected OKRs. Still, it never hurts to drive this point home by explaining how each OKR you chose will help track progress toward proving your hypothesis.

Seal the Deal with a Strong Closing Statement

At the end of the day, your Epic Hypothesis Statement is a sales pitch. Treat it like one by closing it out with a brief but engaging recap. Revisit the potential benefits of your initiative and outline why you believe it will support the organization’s short- and long-term goals.

The Perfect EHS Pitch Starts with a Great Idea

You can develop a comprehensive EHS that captures your stakeholders’ attention by leveraging the above tips and tactics. Remember, however, that your pitch’s success hinges on your idea’s quality.

Work with your EAT to funnel impactful ideas into your portfolio management workflow, then identify a concept you’re passionate about and build your hypothesis around it. You’ll be well on your way to creating the perfect EHS pitch.

Dive deeper into portfolio management with our webinar-on-demand, Lean Portfolio Strategy Part 1: Visualizing your Strategy Flow for Transparent Outcomes.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

SAFe® (Scaled Agile Framework®) is built on the foundation of Lean principles, which originated from manufacturing. “Lean” espouses optimization of the flow of work and elimination of wasteful activities.

While SAFe provides a tailored version of its own set of Lean principles, many teams I have worked with seem to struggle with applying these principles to their daily project work. As an unfortunate result, some teams unintentionally ignore the principles and blindly follow specific practices mechanically, which is risky and likely to be ineffective in the long run. According to the Lean Enterprise Institute, the authoritative source for Lean principles, the Five Core Principles of Lean comprises the following:

1. Identify value
2. Map the value stream
3. Create flow
4. Establish pull
5. Seek perfection

Based on my observations working with a variety of organizations and project teams, I would like to offer my interpretation and provide a few recommendations on making a connection between SAFe and Lean. Let’s inspect each principle and explore how you might apply it within a SAFe context.

1. Identify Value

Working on the most important and most valuable things that your client and stakeholders care about is at the heart of Agile product development. SAFe encourages this practice through a methodical process called WSJF (Weighted Shortest Job First). By focusing on the cost of delay and effort required, WSJF enables program teams to focus on what matters most and what they can deliver in a relatively short period.

2. Map the Value Stream

We encourage SAFe teams to organize around value, which should put emphasis on optimizing the end-to-end flow. Understanding the critical sequence of activities allows the teams to identify inefficient segments of the flow that may contribute to delays; this intelligence will inspire the team to regularly revisit what they can do differently and deliver working solutions faster.

Within SAFe, your teams can deploy a Value Stream Flow Workshop which will allow you to determine the key steps within the process, and will ultimately shed light on where your biggest bottlenecks are. This is a critical event that could alter the entire course of your project.

3. Create Flow

Flow is a necessary component of Lean practices that enables teams to create a sustainable pace and deliver value predictably. SAFe encourages flow by integration of the Innovation and Planning iteration. This practice is a unique approach which acts as a scope buffering mechanism that allows teams to optimize their throughput over multiple Program Increments.

Another method by which SAFe enables flow is the concept of architecture runway, which is supplemented by architecture enablers. By allocating time to infrastructure, teams can prepare the technical building blocks that allow consistent delivery of capabilities.

4. Create Pull

SAFe encourages pull through Kanban methods within the framework. It recommends Kanban at the Portfolio, Program, and Team levels. The pull system relies on the understanding that the people doing the work are in the best position to decide when they can introduce more work into the system.

5. Seek Perfection

Is perfection possible? Maybe, maybe not. But regardless, relentless improvement is at the core of SAFe and is built into the concept of Continuous Improvement and Continuous Innovation. Complacency has no place in the world of Agile product development, and there is an expectation that SAFe teams should consistently look for ways to increase efficiency.

6. What does all this mean?

Here are a few recommendations for your consideration:

• Map your value stream and focus on eliminating inefficient activities that don’t add value. This seems like common sense, but often the simplest things are the easiest ones to forget about when we get preoccupied with complex issues.
• Utilize Kanban correctly; apply WIP (Work-In-Progress) limits so that teams are not trying to do too much work at the same time. Trying to do too many things at once creates a multitude of problems such as loss of productivity, loss of focus, and reduction in quality. Avoiding these self-inflicted issues will improve your chances of success dramatically.
• Apply a pull system; let teams choose their work when they are ready instead of pushing work to them prematurely. Pushing work to the teams is the main reason most teams have been conditioned to become “multi-tasking masters”; we all know that this puts people under excessive stress and erodes confidence and morale.
• Apply IP Iteration and encourage personal/professional development. By skillfully implementing the IP iteration, your team can accomplish two important goals at the same time: (1) Creating a scope buffer that enables your team to throttle the work and still meet customer expectations, and (2) Enabling your team members to focus on improving their current skills in anticipation of future demands. Both activities encourage a smooth flow of work that will lead to higher overall predictability of the entire program/Agile Release Train.

Conclusion

There’s a good reason SAFe emphasizes these values and practices. These approaches improve your team’s ability to perform and achieve their goals. The key is to stay with them and have trust in your teams to do what they know is right!

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

As customers scale from their loose confederation of Scrum teams to the formality of the Scaled Agile Framework©, features often become a source of confusion and sometimes consternation. In this article, I will draw from my experiences to offer practical tips to make features viable as you implement and execute SAFe©.

Features are Not Just Renamed Epics

Any team members who show up to your SAFe Agile Release Train (ART) having worked as a Certified Scrum Master or Product Owner will probably have a good idea of Agile Alliance’s definition of an epic:

“An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories.”

They will feel confident saying, “So SAFe just takes epics and renames them to features, right?” As a coach, your answer should be an emphatic no. Yes, features represent work which is larger than one increment. And yes, features can (and should) be split into smaller user stories. But in the SAFe framework, features represent something wholly different from traditional Scrum epics.

Agile Alliance continues:

“There is no standard form to represent epics. Some teams use the familiar user story formats (As …, I want…, So that…) while other teams represent the epics with a short phrase.”

SAFe provides a recommended approach for representing features. Leveraging design thinking and customer-centricity, the Features and Benefits (FAB) matrix allows the coach to emphasize the Benefit Hypothesis. Here is an example provided by Scaled Agile, Inc.:

From my experience, enterprises adopting SAFe embrace the measurable benefit aspect of the benefit hypothesis. In their mind, “if I am giving you the money to develop this feature, explain what I am going to get for my investment. Otherwise, maybe I will not give you the money to do it.”

As a coach, differentiating traditional epics from SAFe features will offer the opportunity to introduce or emphasize the concepts of Personas and Empathy Maps. In most cases, features should provide broader capabilities than a single persona. Embrace the traditional Business Analyst’s “what about …” questions as you map stories to features.

Embrace WSJF Early or Never

I have found that one of the most challenging SAFe concepts to introduce is Weighted Shortest Job First. SAFe references Don Reinertsen’s Principles of Product Development Flow: Second Generation Lean Product Development and specifies:

“Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (eg., features, capabilities, and epics) to produce maximum economic benefit. In SAFe, WSJF is estimated as the Cost of Delay (CoD) divided by job size.”

Cost of Delay is broken into three components:

• Time criticality
• User business value
• Risk reduction-opportunity enablement

Time criticality

This is where the thrashing can begin as you introduce these concepts to both Scrum aficionados and Agile newcomers. A concept as seemingly simple as time criticality, can represent a not-so-subtle change to the organizational mindset. The Program Manager may come to the feature refinement session saying “all features should have a Fibonacci value of 5 since they all are required ASAP.” In fact, you may come to find that everything they are committing to for the Program Increment is “required ASAP.”

The “teachable moment” here is to emphasize that this thinking needs to change. If everything has the same time criticality, then it renders this aspect of WSJF meaningless. Product Managers must summon the strength to work with their Business Owners to determine if there are actual factors contributing to the time criticality of the feature. The classic example SAFe provides is the availability of a feature to demo at a trade show. Most organizations have other factors you can bring into focus if you’re creative:

• Does this feature relate to time critical regulatory compliance deadlines?
• Does the feature relate to a new product launch or “Go Live” with an established timeline? 

User business value

It’s also challenging to establish an understanding of user business value. Depending on how distant the Product Manager is from the business, they may have little to no visibility into the value the feature represents. As a coach, this is an issue you can point out. By bringing the business stakeholders closer to the process, the Product Owner can manage the horse-trading that frequently goes into prioritizing items for the business. Again, this requires the Product Manager to have the fortitude and self-assuredness to say no to individuals who may be higher on the corporate ladder.

Risk reduction-opportunity enablement

Finally, you must monitor the use of risk reduction-opportunity enablement to increase Cost of Delay value. Product Owners, business stakeholders and others can use risk reduction and opportunity enablement as a catchall for getting their feature prioritized. I have seen intellectual backflips being performed to game the system using the risk reduction-opportunity enablement value:

• The circular logic approach –  “This feature represents a significant opportunity whose value cannot be underestimated as to the potential opportunity this feature promises to provide.
• The Risk Boogeyman – “The lack of prioritization of this feature poses a significant risk to the organization whose implementation we cannot risk delaying.”
• The vague promise of realizing an amorphous opportunity – “We believe this feature represents a dynamic opportunity to advance our product and act as a catalyst to be a key market differentiator.”

This behavior related to the risk reduction-opportunity enablement offers an opportunity to emphasize the skills required to write a good feature. Items brought up during feature estimation should have been described as part of the Benefits Hypothesis. The feature estimation meeting should not be the first time someone references the seismic market-shaking opportunity this feature represents. The coach should also emphasize the measurable benefit the feature offers as it aligns to the proposed Risk reduction-opportunity enablement.

As a coach it is critical to set the expectation that estimating with WSJF is difficult, but it will get easier. By establishing these values as soon as the ART launches, they can act as a reference point. If the ART delays, defers or obfuscates on implementing WSJF, they will most likely never use this valuable tool.

Summary

The feature represents a key artifact on an organization’s journey to aligning teams of teams so they can deliver core business functionality. Their commitment to supporting Agile Coaching is a good sign that an organization is willing to embrace the level of change required to implement the Scaled Agile Framework. But it often takes time to create something great. Just as we advocate incremental change to our delivery teams, we need to drive incremental change within the Lean Agile Center of Excellence.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

While some may disagree with this, I believe that SAFe^® (Scaled Agile Framework) is a highly complex model that requires significant effort to learn and master. That said, SAFe also provides significant value if you are able to focus on specific areas and use the guidance to improve your business agility in an iterative fashion. While the concept of DevOps has been around much longer than SAFe, integrating DevOps and SAFe is often challenging because teams struggle to figure out where to begin. As with many practices that SAFe recommends, DevOps techniques require patience and perseverance.

Having coached many program teams in this domain, I would like to offer a few tips regarding implementation of DevOps within your agile transformation. Along these lines, I will share a few “do’s” and “don’ts” so that you can try to avoid making the same mistakes that I made with your DevOps efforts.

Tip #1 – DO start simple

One thing I have observed is that many teams are very ambitious when it comes to DevOps and want to “do it all” when it comes to automation. Who wouldn’t want to automate everything?! That is usually a utopian vision that we all aspire towards, but not always feasible given real-world constraints. My recommendation is to start small and focus on the basics. Before you can build an end-to-end workflow that encompasses Continuous Integration, Continuous Deployment, Continuous Testing/Validation, etc., you will benefit from mapping your current state, which can take the form of a Value Stream Map.

There are many benefits in going through this exercise, such as shared understanding of how work is done today, where the bottlenecks and inefficiencies are (who is waiting on whom, how much time is lost waiting, etc.). By doing this activity, you may be surprised to find out how many versions of the truth exist in your organization through open and honest discussions. If your team is truly committed to optimizing the flow of value to the customers, gaining insight into how work flows through your system today is a great place to start.

Tip #2 – DO think long-term

While we usually have the desire to fix problems today, we often miss out on the bigger picture. In order to improve your current processes, you have to also think about where you want to go and what success looks like. This may take the form of a “to-be” future-state vision (or Value Stream map) that will provide a target for you and your team to rally behind. Having a goal to shoot for is important and powerful, but keep in mind that this vision may need to morph and evolve as your understanding of business needs change.

Tip #3 – Define a few useful metrics

One of the tenets of SAFe’s DevOps philosophy (C-A-L-M-R; Culture, Automation, Lean, Measurement, Recovery) is “measurement”, which focuses on metrics. As we are all aware, metrics can be helpful but also harmful if mis-defined or misused. Hence, it is essential to define the “right” set of metrics that helps your team connect with what is most important to your customers.

Think about what your customers really care about. Do they care about how many Story Points your teams delivered in the previous sprint? Does that really make a difference to them? Or, perhaps they care more about the Mean Time To Repair which helps them understand your team’s ability to address unforeseen problems? If you are not able to clearly communicate what your customer wants you to measure, it is absolutely critical for you to have a conversation with them so that you are measuring the right things. Keep in mind that how you measure your team will influence how they behave as well as the decisions they make, so measuring the wrong things will likely cause unanticipated problems.

Tip #4 – Focus, focus focus

One of the most important concepts of DevOps is optimizing flow of work/value through your system, which is heavily dictated by attributes such as batch size and total work in-process. If your team regularly attempts to work on too many things at any given time, it is highly likely that you will struggle to achieve an efficient flow due to context-switching. Many studies have demonstrated the negative effects of such behaviors which usually includes loss in productivity and quality. However, most of us still feel obligated to juggle many things simultaneously.

This is one reason that focus is critical; limiting the number of items in-work can dramatically improve throughput. Just imagine trying to paint two different rooms in your house at the same time…you will lose a significant amount of time and productivity running between the two rooms as compared to focusing on just completing a single room first, then moving to the next room.

So how do we achieve this? Many DevOps teams leverage Kanban boards to make work visible, yet they do not implement WIP (Work In Progress) limits which significantly reduces the benefits of the Kanban method. Start by setting a maximum limit on the step in your workflow that you suspect may be a bottleneck; use the total number of team members as a start, and see how that impacts the flow of work. You will need to experiment by adjusting this limit up or down to see how it affects your team’s ability to deliver value.

Tip #5 – DO NOT be afraid to experiment

One of the key principles of DevOps is continuous experimentation and learning, which is built on the idea that we don’t always know the best solution until we try something and learn from the experience. While not all organizations are comfortable with this approach, this is at the heart of the empirical nature of DevOps – experimentation is necessary to prove or disprove a theory; without experimentation, we are just guessing without a methodical way of obtaining useful feedback. If your organization is risk-averse, try to find a small project (or process) that is relatively low risk so that a failure will not bring down the entire company. This would be a good place to start your first experiment to see how the process works and gain some valuable data for bigger projects.

To wrap up, there is no single way to apply DevOps practices. The key is to start with what you know, pick a direction, and try a few things. Think iteratively and learn from each experience, and you will likely discover surprising insights that you had never expected.

Scrum was created to help organizations and teams to solve complex problems. Scrum does this by delivering increment(s) of value in a Sprint, created by a Scrum Team who continuously experiment and seek feedback along the way to learn and improve as they deliver solutions to complex problems. A Scrum Team is therefore instrumental to the success of Scrum.

In this blog, I provide answers to the following questions in relation to the Scrum Team:

1. What is a Scrum Team and what are their accountabilities?
2. What is the purpose of a Scrum Team?
3. What are the characteristics of a Scrum Team?
4. What must a Scrum Team know to deliver value?

In each section, I have also raised a number of follow-up questions for you to consider. These questions are there for you to reflect on and for self-assessment purposes.

What is a Scrum Team and What Are Their Accountabilities?

A Scrum Team is a small team of people (typically 10 or less). It consists of:

• One Scrum Master (who is accountable for establishing Scrum and team effectiveness).
• One Product Owner (who is accountable for maximizing the value of the product resulting from the work of the Scrum Team).
• Developers (who are committed to creating any aspect of a usable increment each Sprint).

Questions:

How Big is Your Scrum Team?

• • Is it too small, too large, or is it about right? If it’s too small, do you struggle to be cross-functional and be able to deliver an increment at the end of a Sprint? If it’s too big, how does this impact the team’s ability to self-organize, self-manage, collaborate and communicate effectively?
  • What patterns / behaviors have you noticed? Are team members stressed due to the demand of work (for small teams)? For larger teams, have some team members ‘checked out’? Have smaller sub-teams formed? Has a team boss emerged?
  • For larger teams, do you have a single shared Product Goal or Sprint Goal?  Or do you find it hard to craft goals? What challenges does this present for you? If the Scrum Team is too big, have you considered reorganizing the team into multiple cohesive Scrum Teams, each focused on the same product?

• Are they able to live the Scrum Values? Is there trust within the team?
• How transparent are you as a team? Is the team enabling effective empiricism? Are they learning together and adapting together as they learn new things? How visible is the process of work?

Do You Have a Scrum Master Who:

• Is a change agent to enable a culture in which Scrum teams can flourish? Are they accountable for establishing the Scrum process within the organization? If not, who within the organization is? How does/will this impact the effectiveness of Scrum to deliver value?
• Is a coach who coaches the Scrum Team on mindset and who models the Scrum values? For example, do they reinforce a teams’ commitment when they facilitate a Sprint Planning?
• Fosters team courage by creating safety for teams to have difficult conversations?
• Encourages team focus, by ensuring full team member participation in each Daily Scrum?
• Encourages openness in Sprint Retrospectives?
• Has developed respect in their teams? Team members listen to each other in Sprint Planning.
• Is a mentor who transfers their agile knowledge and experience to the team?
• Is an impediment remover and is actively championing agility within the organization and works to remove organizational impediments? If not, what impact does this have on the Scrum Team’s ability to deliver value?
• Acts as a true-leader, measuring their own success by the growth of the Scrum Team?
• If no, to any of these questions, how does it impact trust within the team? Are you as a team willing to be vulnerable with each other?

Do You Have a Single Product Owner Who is:

• Empowered to make decisions to maximize the value of the product?
• Willing to make decisions with incomplete information and who is able to make decisions with a degree of risk?
• Willing to try new things, explore, and experiment?
• Just a Project Manager in disguise? Not interested in value but is an output maximizer? Remember the purpose of Scrum is to generate value. What is important to you, outputs or outcomes?
• A subject matter expert (they think they are) and describe not only the ‘why’ and ‘what’ of the Product but also ‘how’ work should be done? Do they create a task list for you to complete? How does this make you free? Are they violating scrum values?
• A ‘visionary’ and is able to communicate the Product Vision, Strategy, Business Goals etc.
• A true collaborator and actively seeking input from all stakeholders and setting expectations with them?
• A decision maker and is available to help answer questions and guide the value created by the Developers during the Sprint

Do You Have a Group of Developers Who:

• Are a team of experts? Do they have all the skill sets to deliver an increment each Sprint? Are your Developers t-shaped in person? Do they exhibit empathy and enthusiasm about other Developers disciplines, to a point where they actually start to practice them?
• Have autonomy over how they develop and deliver the increment within the guardrail of a Sprint?
• Pursue technical excellence? Do they have a clear understanding of the definition of ‘done’ that they have created? Which they improve and enhance over time to ensure quality? Do they use Extreme Programming practices as a source of inspiration?
• Refine the backlog as a team? Everyone is involved and not just a few ‘senior’ developers?
• Know how to have fun with each other? Is there a sense of camaraderie? Are some of the best decisions made around the ‘water cooler’?
• Dislike Scrum events and skip them? Do they feel these events as pointless and of no value? Do you skip events to keep up with work demands? What impact does this have on the effectiveness of Scrum?

What is the Purpose of the Scrum Team?

The Scrum Team exists to deliver a series of valuable product increments.  The Scrum Guide adds that the ‘Scrum Team is responsible for all product-related activities.’ In addition, the Scrum Team owns their artifacts. Each artifact maps onto a Scrum ‘commitment.’ The three commitments are:

1. Product Goal

The Product Goal describes a future state of the product which can serve as a target for the Scrum team to plan against. The Product Backlog commitment is the Product Goal.

2. Sprint Goal

The Sprint Goal is the single objective for the Sprint. The Sprint Backlog commitment is the Sprint Goal.

3. Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The Increment commitment is the Definition of Done.

Questions:

• Is your Scrum Team able to perform all of these product-related activities? Is your Scrum team cross-functional and able to take a feature from idea to implementation? If not, are the Scrum Teams dependent on other teams within the organization to perform these activities? What impact does this have on the team’s ability to be empirical? What impact does this have on the flow of work and the Scrum Team’s ability to create a usable increment each Sprint?
• Has your Product Owner articulated a clear Product Goal? Does the Product Goal align to business objectives? Is your Product Backlog ordering influenced by the Product Goal? Is the Product Goal realistic and attainable in a timely manner? Does the Product Goal enable transparency in that it aids the objective of building the product? Do your Sprint Reviews merely inspect specific increments, or does it monitor the progress in achieving the Product Goal?
• Do you craft a Sprint Goal during a Sprint Planning event? Does it clearly describe how it serves to achieve the Product Goal? Does your Sprint Goal describe the ‘why’ of the Sprint and the outcome that is desired at the end of the Sprint and its associated value? Have the Developers created a Sprint Backlog which is aligned to the Sprint Goal, which has been created and is an actionable plan and owned by them? Do the team think that the Sprint Backlog is fixed and is a detailed plan? How often is the Sprint Backlog updated as new insight is learnt? Do Developers recognize that the Sprint Goal is an operational commitment by them?
• Have your Developers written and own its Definition of Done? Is it transparent? Does it create a shared understanding of what work needs to be created for an Increment to be created?

What are the Characteristics of a Scrum Team?

Typically, a Scrum Team exhibit the following characteristics, it is:

1. The team members share the norms and values
2. They act as a whole, collectively accountable for the delivery of the Product Goal
3. They are empowered and work autonomously
4. They are self-managing and cross-functional
5. Able to adapt to feedback from stakeholders and the marketplace

Questions:

Is Your Scrum Team(s) Self-managing? For Example:

• Are they able to determine how it does its work? Has the team taken ownership of its processes (i.e., how it converts ideas into increments?)
• Does the Scrum Team share knowledge and Skills? Are they open and transparent? Do they have a shared commitment to one another?
• Are they empowered to make changes to its processes and tools to be more effective and efficient?
• Does the Scrum Team craft its own Sprint Goal which includes the team collaborating on the why (the Product Goal), the what (product backlog items) and the how (the work to be done).
• Do the Developers determine the work it will executive on a daily basis on new insight and feedback.
• Is the Scrum Team able to maximize the value of its work, minimize waste and maximize the flow of its processes (and reduce the average cycle time of work)?
• Are your Scrum Teams working on multiple projects/products simultaneously and context switching/ What impact does this have on team morale and efficiency of the team? Does the value you gain from the work outweigh the cost or potential waste?

If not, is Scrum actually understood to help the organization and teams to create value?

What Must a Scrum Team Know to Deliver Value?

Scrum Teams must:

• Understand the motivations, behaviors, and needs of user’s and customers, the business and their capabilities
• Align the product’s vision, its strategy, and the mission and objectives of the organization and
• Measure the actual value delivered

Questions:

• Are your Scrum Team(s) able to speak directly to the customer? If not, what challenges does this bring in your ability to deliver products / solutions that deliver a value proposition to your customer?
• Does the Scrum Team work align to business goals and product vision? Or are you just a feature factory delivering ‘stuff’. How does this impact the motivation of the Scrum Team?
• How do you measure value? Are you focused on output (e.g., story points delivered, no defects, unit test performed) or do you use outcomes (changes in customer behavior, customer retention, revenue and sales). How will you switch from focusing on outputs to outcomes?

I hope you were able to answer as many questions as possible. What next?

Go back and look at your answers. Now consider the current trends for each one:

1. Is the Scrum Team moving toward desired outcomes?
2. If not, what can the Scrum Team do? How would you order your list of improvements? What is urgent now, which will have the biggest impact on the team’s effectiveness?
3. In which areas do you feel the Scrum Team is moving backwards?

Why not take your findings to a future retrospective and share your thoughts on your answers. After 3 or 6 months, revisit these questions again. Have things improved? If you have any questions, reach out to me.

Identifying Products

Maximizing customer value and increased speed of delivery are two benefits often seen by companies after moving to a product-centric application delivery model. This is possible because product thinking provides teams, or programs, a shared vision and a shared understanding of not just the product, but the customers and the markets they serve. This enables teams to learn and adapt to market changes faster than they could in a project model. As a result, teams spend more time focused on building the right thing and less time creating waste (the stuff people don’t want).

If you want to achieve the benefits of a product-centric model, but are overwhelmed by where to start, continue reading. In this post, I present an approach to identifying products you can use to launch your journey.

My favorite definition of Product is “The thing you build, or service you provide, that impacts people.” It’s simple, easy to remember, and cuts to the point. But in the digital age, where much of what we create impacts people, what makes a product? Is this blog post a product? Is a marketing campaign a product? What about a support ticket; support is a service and the ticket resulted in a customer satisfaction survey. Does that make support a product? Is everything you do “a product” or only the tangible things a customer buys? 

Product identification is often a challenge especially for complex organizations or those that grew quickly through mergers and acquisitions. The complexity of organizations and the bureaucracy created through organizational structure often makes product identification a struggle (on a good day). 

When identifying products, it helps to think about your business from the customer’s perspective. The following 4 steps provide a framework to help organizations identify products and establishes the mindset necessary to become a product-centric:

1. Understand the value your organization delivers to its customers.
2. Identify how value flows through the organization
3. Consider how value is delivered to your customers
4. Consider how those products are enabled

Understand the value your organization delivers to its customers

In the late 90s I worked for Delta Technologies, the IT arm of Delta Airlines at the time. Like many companies at the turn of the century we were project based. I’ll use this experience to provide an example of how one might identify products by taking a customer first approach. Any resemblance to Delta’s current products, or those of any other airline, is coincidental.

A flight between two locations is the primary value customers receive from an airline. But several steps are necessary for a customer to realize this value. Each of these steps is an opportunity for the airline to impact their customer.

Identify how value flows through the organization

The first opportunity occurs when an individual decides to take a trip and realizes that the airline can get them there at a convenient time for an affordable price. Once the decision is made, the next opportunity occurs when the person books the flight. Finally on the day of travel there are several opportunities: check-in, boarding, the flight, deplaning and baggage claim. This customer experience can be visualized as follows:

The customer centric approach yields seven opportunities to impact our customers or potential customers. Now we need to look at how value is delivered to our customers.

Consider how value is delivered to your customers

Implementation choices determine how, and to what degree, a company serves the needs of their customers. In the digital world, these decisions also create products. An airline may choose to build siloed applications for each opportunity or one monolith to service everything but the actual flight. Another airline may identify key services and build multiple interfaces to target specific users (customers vs internal agents).

The image below illustrates how an airline might deliver value to its customers. There is a dedicated solution used to create a schedule and a dedicated reservation system used by call center employees to create reservations on behalf of customers. Airline employees working at the airport use an airport logistics system to serve customers at check-in, boarding, deplane, and baggage claim. Additionally, there are web and mobile solutions and a kiosk for customers that want to self-serve. Finally, there is an aircraft to take customers to their destination.

When considering how value is delivered, focus on the needs of the business customer. To meet those needs you may identify a solution that has an internal customer. For example, the immediate customers for the Airport Logistics product are airline employees, but these employees are there to provide value to the flier (the business customer).

Consider how value delivery is enabled

All of the products we’ve identified so far impact the customer either directly or indirectly. Our last step considers how the business enables value delivery. Products that fall into this category are used by employees to enable a customer facing product. Internal products are like supporting cast in a movie; they are an important part of the story and necessary for the main character to accomplish their goal; but the story is about the main character. Since internal products are sometimes bought (i.e. using ZenDesk to enable customer service), we only want to consider bespoke solutions created to meet specific business needs. /span>

At Delta Technologies, I was part of the Network Management group. The network we managed did not consist of routers and cables, but rather flight routes, airplanes and crews. We served a department in Delta Airlines that was responsible for creating the schedule. Their goal was to maximize value for the airline by determining when and where planes flew. 

A lot of work goes into creating a schedule besides choosing desirable cities. There are airport restrictions and regulations on crew and equipment that must be considered. In addition, airlines enter partner agreements in order to serve more markets. These agreements come with restrictions that must be considered as part of creating a schedule. Finally, schedules are not static, they represent a plan; weather, sickness, and maintenance issues all contribute to delays and cancellations that impact what actually happens. When these events occur, temporary schedules are put in place, and passengers re-accommodated, to get everything back on track. 

As with the previous step, implementation choices drive products. Back in the 90s we worked on projects to create various solutions to manage the inputs used to generate a schedule. A straightforward approach to product identification would be to consider each of those solutions a product. But we need to ask ourselves if that approach creates a structure that enables us to provide maximum value to the customer (internal and/or external)? It might, but another approach would be creating a product team capable of supporting all existing solutions but charged to optimize the system to maximize value delivery. The latter approach solves a system problem by creating a team focused on the outcome of generating a better schedule instead of optimizing a single input. 

Wrap-up

Let’s recap the products we were able to identify in this fictitious airline example.

The value to our customer is a flight between two locations. To achieve this value, the customer needs a schedule, to make a reservation, to check-in, to board, to travel, to deplane, and claim their bag if one was checked. These are the products that enable value to flow through our organization. 

In our example, those products were delivered by the scheduling system, a reservation system, an airport logistics system, and an aircraft. Additionally the customer could self-serve using a web interface, mobile applications and a kiosk at the airport.

We only considered how value delivery was enabled for the Scheduling aspects and that exercise resulted in one product. This product consists of several applications working together to enable the schedule. 

The complete product map is illustrated in the following image.

Conclusion

Don’t let the task of identifying products in your organization overwhelm you. Start with an understanding of the value your organization delivers to its customers and identify how that value flows through the organization. Next consider how that value is delivered to your customers. Finally, consider how the products you’ve identified are enabled. When considering internal products, start with the obvious and then optimize for the system. One final tip: don’t do it alone. Successful transformations, like successful product development, begin with a cross-functional team collaborating to solve a problem. If you are interested in learning more or want guidance in your product-centric transformation, let us know. Cprime has people with the skills and experience to help.