Dave West, CEO & Product Owner at Scrum.org, explores the agile product operating model and its role in integrating digital technology into organizations and its impact on operations and structure.

Over the last ten years, digital technology has become an integral part of our lives. Smartphones, websites and integrated technology have become the norm in our daily routines and work. It’s hard to imagine a time when we didn’t have the supporting infrastructure of maps, transportation, translation and local knowledge in the palm of our hands. However, despite this technology’s prevalence, its integration into organizations remains complex.

For many, digital technology is still a separate entity that needs to be connected to the organization’s core business. This is where product thinking steps in, empowering organizations to leverage digital technology and integrate it seamlessly into their operations.

Product thinking takes center stage

Every organization has products. They describe the goods and services that the company provides. However, for most organizations, products stop at the boundary of a packaged good or service for the customer. Products are supported by an elaborate collection of business processes, applications and systems built to support the product and the people involved in its delivery. A great example of this is when you visit your bank. You are interested in opening a CD, but as you engage with the bank, you are treated to a collection of systems and processes ranging from customer acquisition, risk management, compliance and sales.

Often, these handoffs are hidden from the customer; only when the integration fails does the customer see the collection of systems. Digital brings the complexity of these systems front and center as opportunity, delivery speed, and the relationship with the client are turned on its head. Product thinking does not remove the underlying complexity; it provides a unifying concept to align teams and drive work. It provides a rallying call for teams to focus on the customer and value and uncover dependencies and bottlenecks.

Product operating model

An operating model is a holistic description of how a company realizes its strategy and how it operates to support its strategy. It is the latest name for an organization’s collection of elements to deliver value.

The model includes:

People and Organizations – What are the people’s responsibilities, titles and how are they organized
Processes – How the people work together and what information is required to deliver value
Governance – Who makes decisions, and what oversight and controls are in place
Culture – The values, beliefs, attitudes and rules influencing behavior
Measures and Incentives – The key performance indicators and how performance and success are measured and communicated
Tools and technology – The systems and tools required to deliver value

The model should respond to an organization’s strategy and mission. Over time, the organization’s strategy changes and the operating model should change in response. However, most organizations’ operating models result from years of different strategies. Change is hard, and adding and renaming without fundamental changes is much easier.

The product operating model is the operating model for an organization when it delivers products. It sounds straightforward. However, the idea is much larger than the “product” bit of a typical organization. It is a unifying concept in the digital age and will ultimately change the idea of projects for most work. Yes, projects will happen in a product-aligned organization rather than a separate collection of individuals from specialist areas, like front-end development, marketing, database, manufacturing, etc…

Moving to this model also requires the organization to define its products and understand the boundaries, dependencies, costs  and ultimate value of those products.

Agility manages complexity and risk

Product operating models provide the model for each product and show how everything works together in response to the needs of the product. An organization will have many operating models, one for each product. For products that are digital or have a large digital element, those operating models must be agile. Inherently, digital products are complex because the problem being solved, and the solution has multiple “right” answers. The solution and problem have an odd relationship where one influences the other.

For example, by providing a new capability on, say, a smartphone, changes the user’s behavior in a way that can not be predicted and controlled. That leads to new opportunities and risks. This is why software development turned to agile methods. They provide some respite from complexity by encouraging empirical processes and reducing decision latency through empowered teams. Empirical process describes how in a complex or complicated world that evidence about the situation emerges incrementally. Teams are empowered to take that evidence and make decisions quickly.

The impact on individuals, teams, and organizations

The following impacts result from the agile product operating model:

Organizations will need to build cross-functional teams aligned to products.
This will require removing the barriers between technology, business, and operations in pursuit of customer value and insight. Often, this will result in flatter, more customer-aligned organizations. However, this will also be messy, as many people have built careers focused on building deep knowledge of internal systems, and that alignment is changing. Deep system knowledge continues to be very valuable but must be married with flexibility and a focus on the end-to-end value stream of the user.

Product Ownership and Management will be growing skill sets throughout the organization.
Each product will need clear leadership, which needs to unify the disciplines of product management with the mindset of product ownership. The titles of these people will vary depending on the organization; however, the skills are crucial.

Evidence will help structure planning and decision-making.
Because digital requires an empirical approach, evidence will become crucial in framing goals, work, and outcomes. This will naturally lead to organizations becoming much better at framing problems regarding the evidence required and using data to inform decisions.

Product thinking will be associated with externally facing customer products as well as internal products.
Clarity in customer, user, value, dependencies, and boundaries will enable teams to build a strong product culture throughout the organization. Internal customers will be treated in the same way as external customers, allowing a more consistent customer-focused approach.

Investment in products will exist across planning horizons.
Products exist until they are removed from the portfolio. Traditional project planning has driven unrealistic expectations around the total cost of ownership for a product, leading to increased technical debt and legacy system blackholes. Investment levels will change depending on choices at the portfolio level, but products will continue to exist even if they are not a focus for this planning period.

So, why should you care?

Moving to an agile product operating model is the next evolution in how organizations take advantage of digital technology. However, like subsequent moves, that move will be challenging as it changes the organization’s power structures and encourages flatter, outcome-based approaches. Because of this, many organizations will adopt product thinking by name only, replacing their existing project operating model with a product one. This ultimately will reduce the value and increase the internal complexity of the organization.

Watch for two warning signs:

1. Work is everywhere. Instead of clear outcome-based strategies and investment themes connected to customers and outcomes, planning, backlogs and reporting centers on work being delivered. Work is, of course, an important thing for teams to focus on, but outside of the team it is a distraction. Leaders should focus not on what teams are doing but the evidence being delivered that shows progress against clear outcomes and goals.
2. Decisions require large groups of people. In more established organizations, decision-making is distributed and complicated. Agility requires rapid decision-making based on evidence. Senior leadership sets guard conditions (for example, budget, timeframes, quality, governance) and clear business goals but allows teams to execute against those goals. Products provide an organization with a model that can help define accountabilities. However, existing organizational structures can undermine those boundaries.

If you face those challenges, try to influence a clear alignment between outcomes and customer opportunities and encourage clarity around product boundaries and accountabilities.

The post Exploring The Agile Product Operating Model appeared first on Pragmatic Institute - Resources.

Most organizations want to improve their agility to be more responsive to customer and market changes. They want  to  build  on  the success they have had with scrum at the team level and apply it across the whole organization. And while they might like to be more like Apple, Netflix or Airbnb, their challenge is that, unlike Silicon Valley
startups and tech giants, they are not starting from a clean slate. Instead, they are trying to change from a traditional, process-centric, hierarchical organization into something else.

Their challenge is compounded because there isn’t a repeatable process for this transformation; everyone starts in a different place and has different goals. The word “transformation” is itself part of the problem; it implies moving from one state to another. Perhaps a more realistic description is that the organization must evolve from one
that values processes and standards to one that values learning and flexibility. Evolution takes time and is ongoing. While standards remain important, even more important is to achieve quality in the products and services delivered.

Agile Is a Culture, Not a Process

An insistence on standardizing the ways that output is produced may add to the confusion of viewing agile as a process rather than a culture. In the 1970s, American auto manufacturers adhered to highly standardized processes but produced low-quality automobiles. They tried to copy Toyota’s production system to fix the problem but missed the essential role of continuous improvement. Toyota’s production system was not a fixed process, but a culture of continuous improvement that managers instilled and reinforced in their employees.

When Kiichiro Toyoda, Toyota’s second president, was asked about the risk of his loom design plans falling into competitors’ hands, he replied, “The thieves may be able to follow the design plans and produce a loom. But we are modifying and improving our looms every day … They do not  have the expertise gained from the failures it took to produce the original… We need not be concerned. We need only continue, as always, making our improvements.”

To make continuous improvements, teams must be empowered to deliver small increments of value—with direct access to customers—in rapid cycles so that they can continually learn and improve. Teams working together to deliver complex products find that cross-team dependencies slow them down, reducing their ability to make decisions and get rapid feedback from customers. A main problem that organizations face when they scale agile is reducing or eliminating cross-team dependencies.

There are no simple answers for enterprise transformation; every team and  product  must  solve slightly different challenges. There are, however, some common practices and patterns that help organizations improve their agility. They are simple to understand, but like  scrum,  are  often  hard  to adopt. However, understanding them can help identify solutions that fit your unique situation and goals.

To Scale Up, First Scale Down

Only the simplest, leanest way of working will scale. You can’t scale complexity. Complex processes, organization structures and tool chains may seem necessary, but take another look: Is something absolutely essential? Does it require a degree of perfection that is impossible to attain? The idea of keeping things small or lean is reinforced by the ideas of Fred Brooks in his essay, The Mythical Man- Month. It is also demonstrated by the modern-day space company Space X, which employs fewer than
40 engineers to build all the software necessary to launch, manage and land the Falcon spaceships.

Keeping things small is not easy, particularly when you are dealing with complex systems that require specialists. Here are three things to consider:

1. Employ specialists to teach others. Instead of getting another group to do something for the team, get someone from the other group to teach team members, scaling scarce skills in the organization, uncovering gaps in understanding and improving the solution’s clarity. Your ultimate goal should be to encourage people to develop a broad set of skills that complement their deep skills in several areas.
2. Automate repeatable and error-prone tasks. Repetitive tasks that don’t require judgment to perform should be automated and made available on demand. The best candidates for automation emerge naturally from the teams trying to deliver rapidly; give them the time to automate. Resist the temptation to appoint a DevOps team; let the people who understand the problem solve that problem, or risk creating processes and
   automation that are overly broad and useless. Automate just enough and no more.
3. Recognize that not everything should be agile. Agility is the application of empiricism to solve complex problems in which more is unknown than known. There are many simple and complex problems in large organizations where more is known than is unknown. In those instances, agile might not be the right approach. It can feel pointless to use an empirical approach to answer simple questions that have relatively easy answers.

Scaling Agility Is All About Teams

Cross-functional, self-organizing teams are at the heart of any agile transformation. Once they know what outcomes the organization wants them to achieve, these teams should have the freedom to do what is necessary to deliver those outcomes. They should frequently inspect what they are producing to ensure that it achieves the desired business outcome and the desired level of quality.

Agile teams tend to be small; scrum teams consist of three to nine people each. When the desired outcomes require more than one team, teams may become cross-functional and self-organizing. To focus on teams at scale requires that organizations concentrate on the following four things:

1. Attract flexible people who continually learn. Agile requires team members who are willing to do whatever is needed to accomplish the team’s goals. The ideal team member has enough breadth and depth to learn quickly and pick up new skills as needed.
2. Create cross-team specialists only when needed, and only for as long as needed. Generalists sometimes need to be supported by specialists, whose main role should be to teach people new skills and provide generalists with tools that help them do their jobs more effectively. Ideally, specialists should try to work themselves out of a job.
3. Build communities of practice for continual improvement. Communities of practice help organizations build skills and share experiences and expertise across teams. These communities help team members develop their skills and careers as they learn from peers and mentors. Communities need organizational support and nurturing, but they repay that investment by helping to normalize and scale skills across teams and organizational structures. Make time for community participation, measure community contribution and factor community leadership into career-advancement decisions to help the organization grow its technical capabilities.
4. Create a culture of servant leadership. Traditional, hierarchical organizations are characterized by top-down decision-making, while agile approaches encourage decisions that are informed by bottom-up intelligence. In other words, people closest to the problem are the ones best informed to make decisions about it. Leadership is critical to ensuring that teams have clear direction on the right problems to solve, the support to solve those problems, and an awareness of when they may need help and who can give it. This coaching style of leadership is often new to organizations and requires an investment of time and support.

Start From the Edges

Agility enables organizations to more readily respond to change while delivering increased value. Most organizations need agility in the parts of their business that are closest to customers.
Keeping customers at the center of agile scaling efforts helps focus on improving the customer experience and competitive position. Later efforts can then shift to internal efficiency, including a focus on HR, legal and finance.
 
Find out who the customers are. Design thinking and lean startup practices provide techniques that help organizations effectively understand their customers. Agile approaches provide mechanisms to better understand customers, such as frequent feedback, provided that actual customers are engaged. Because many teams only work with internal stakeholders, they miss the opportunity to better understand a real customer’s needs. Focusing teams on a set of customers and specific pain points makes it possible to scale customer knowledge and build a better understanding of their needs.

Empower product ownership. Without clear direction, an agile team will flounder, going from one “important” item to another. To effectively inspect and adapt, decisions must be made about the problem and solution. Product ownership provides a rudder to help stay the course.

Think in terms of outcomes and experiments, not features and functions. Although stakeholders hold important opinions, customers make the ultimate decisions. And while features are usually built with good intentions, if they are based on flawed assumptions, they will be ineffective. The fastest, most reliable
path to success is to identify unmet customer outcomes, then form and quickly test hypotheses to improve those outcomes. Breaking down complex problems into a series of hypotheses and testing them will provide the team with the flexibility and focus to deliver value.

##tweet##

Enable Scrum Masters to Raise and Remove Impediments

Incorporating scrum and agile helps make problems transparent. Organizations accustomed to hearing that “everything is fine” (until it is not) find this disconcerting, but it’s the means by which to identify and overcome obstacles.

Teams build resiliency by inspecting, adapting and overcoming challenges. But they can’t always overcome challenges without help; teams need engaged leaders who will intercede on their behalf. Sometimes leaders need assistance
to understand where their help is needed; that’s when the scrum master, acting on behalf of the team, needs to escalate problems to management.

Make the scrum master a valued position. This position is often filled by someone who complains least about taking on the role. But a failure to appreciate and empower the scrum master will undermine the scrum team’s ability to be effective. It is important to attract the right people and support them as they embody the scrum values of focus, commitment, respect, openness and courage.

Recognize that a scrum master is NOT a project manager. While project-management experience provides valuable insights, it may come with baggage. The biggest difference is that project managers, when necessary, are empowered to tell people what to do, while scrum masters are not. Instead, they teach people how to do something and hold them accountable to do things right. To  lessen the temptation to slip into old habits, it helps if project managers transitioning into the scrum master role work with a different group of people.

Support the scrum master with experienced coaches. When driving organizational change, it is important to provide support for scrum masters. Effective communities of practice, combined with external coaches, can help scrum masters focus on developing team members and encouraging their teams to deliver more value.

Focus Leaders on Removing Impediments

Scrum masters often lack the authority and influence to remove impediments that lie beyond their own teams. They need executive help. By creating an enterprise scrum team, having an enterprise change backlog, and empowering a product owner for the change initiative, executives will get a taste for the agile approach as they help teams resolve issues.

Introduce an enterprise change backlog. When scrum teams identify impediments with which they need help, putting them on an enterprise backlog ensures they will get senior leadership attention. Just as the product backlog helps scrum teams focus on delivering value, a fully transparent enterprise backlog for organizational change issues enables leaders to focus on the things that will deliver the most value. It also provides a clear message that the executives support agile.

Make the executive team an agile team focused on delivering value and transparency. Executive teams that use agile practices demonstrate not only their  support,  but their confidence in using it to manage their own work. Ensure that sprint reviews, including discussions about progress and demonstrated success, are open to everyone.
 
Measure and communicate success. It is important to provide a platform that demonstrates teams’ success to the organization. Introducing an enterprise backlog and making the executive scrum sprints transparent help provide an organizational foundation to drive change. Scheduling regular events gives teams a chance to demonstrate how they are driving change and dealing with the issues they uncover.

Establish Measures to Drive Continuous Improvement

People-centric, lean, empirical processes enable teams to respond to the challenges of a changing world. However, teams also need a set of balanced, objective measures that tell them whether they are improving over time.

• Current value is what the organization derives from delivering value to customers. Examples include revenue, product cost ratio and net promoter score (NPS).
• Time to market is the time it takes for customers to start benefiting from a new idea or product improvement. Aspects of time to market include release frequency, the time it takes to stabilize a release and overall cycle time.
• Ability to innovate measures the ability to deliver solutions that meet customer needs. The usage index, defect vs. new feature ratio, and assessing overall quality help contribute to this insight.

Building an Agile Organization Takes Practice

Agility is an enabler that makes it possible to achieve your goals. It’s also a complex skill—like learning to play an instrument—that requires practice and dedication and is learned over time. And while there is always room for improvement, all that practice has a goal: to delight the audience, or in the case of the modern organization, to delight the customer.

A great orchestra is more than simply a collection of great musicians. The ability to work together is what makes them do great things. And in the context of delivering amazing value   to customers and stakeholders, it means aligning teams with customer outcomes and creating an environment that supports and fosters change. Agility scales team-by-team, product-by- product, and creates an organization that is always learning, changing and improving.

Make the scrum master a valued position. This position is often filled by someone who complains least about taking on the role. But a failure to appreciate and empower the scrum master will undermine the scrum team’s ability to be effective. It is important to attract the right people and support them as they embody the scrum values of focus, commitment, respect, openness and courage.

Recognize that a scrum master is NOT a project manager.

While project-management experience provides valuable insights, it may come with baggage. The biggest difference is that project managers, when

necessary, are empowered to tell people what to do, while scrum masters are not. Instead, they teach people how to do something and hold them accountable to do things right. To lessen the temptation to slip into old habits, it helps if project managers transitioning into the scrum master role work with a different group of people.

Support the scrum master with experienced coaches. When driving organizational change, it is important to provide support for scrum masters. Effective communities of practice, combined with external coaches, can help scrum masters focus on developing team members and encouraging their teams to deliver more value.

Focus Leaders on Removing Impediments

Scrum masters often lack the authority and influence to remove impediments that lie beyond their own teams. They need executive help. By creating an enterprise scrum team, having an enterprise change backlog, and empowering a product owner for the change initiative, executives will get a taste for the agile

approach as they help teams resolve issues.

Introduce an enterprise change backlog. When scrum teams identify impediments with which they need help, putting them on an enterprise backlog ensures they will get

senior leadership attention. Just as the product backlog helps scrum teams focus on delivering value, a fully

transparent enterprise backlog for organizational change issues enables leaders to focus on the things that will

deliver the most value. It also provides a clear message that the executives support agile.

Make the executive team an agile team focused on delivering value and transparency. Executive teams that use agile practices demonstrate not only their support, but their confidence in using it to manage their own work. Ensure that sprint reviews, including discussions about progress and demonstrated success, are open to everyone.

Measure and communicate success. It is important to provide a platform that demonstrates teams’ success to the organization. Introducing an enterprise backlog and making the executive scrum sprints transparent help provide an organizational foundation to drive change. Scheduling regular events gives teams a chance to demonstrate how they are driving change and dealing with the issues they uncover.

Establish Measures to Drive Continuous Improvement People-centric, lean, empirical processes enable teams to respond to the challenges of a changing world. However, teams also need a set of balanced, objective measures that tell them whether they are improving over time.

• Current value is what the organization derives from delivering value to customers. Examples include revenue, product cost ratio and net promoter score (NPS).
• Time to market is the time it takes for customers to start benefiting from a new idea or product improvement. Aspects of time to market include release frequency, the time it takes to stabilize a release and overall cycle time.
• Ability to innovate measures the ability to deliver solutions that meet customer needs. The usage index, defect vs. new feature ratio, and assessing overall quality help contribute to this insight.

Building an Agile Organization Takes Practice

Agility is an enabler that makes it possible to achieve your goals. It’s also a complex skill—like learning to play an instrument—that requires practice and dedication and is learned over time. And while there is always room for improvement, all that practice has a goal: to delight the audience, or in the case of the modern organization, to delight the customer.

A great orchestra is more than simply a collection of great musicians. The ability to work together is what makes them do great things. And in the context of delivering amazing value   to customers and stakeholders, it means aligning teams with

customer outcomes and creating an environment that supports and fosters change. Agility scales team-by-team, product-by- product, and creates an organization that is always learning, changing and improving.

The post How to Scale Agile: Simple Ideas for a Complex Problem appeared first on Pragmatic Institute - Resources.

Agile Loves Roadmaps and Plans

First, let’s dispel a myth. Agile and scrum don’t discourage the creation of a product roadmap. In fact, scrum teams plan frequently. To quote the agile guru Mary Poppendieck: “Agile hates plans, but loves planning.”

In short, with agile teams there is both the need for frequent planning and the challenge of keeping a plan up to date. But many scrum teams want to start a sprint before they have a clear vision for the product. Or worse, if there is a clear vision they ignore it and focus on what they think is best. Having a vision and a backlog are the cornerstones for any scrum team and sprint. In Agile Project Management with Scrum, Ken Schwaber, a scrum co-creator, writes, “The minimum plan necessary to start a scrum project consists of a vision and a product backlog. The vision describes why the project is being undertaken and what the desired end state is.”

Support the Empirical Process

There is no single silver bullet for building the perfect roadmap. Each situation is defined not only by the product, but also by market, audience and organizational culture. What makes sense for a bank selling bonds won’t work for a web company delivering a new media product.  Remember the golden rule when you use scrum: Support the empirical process.

Scrum, unlike waterfall, is an empirical approach. Drawing on the ideas of scientific method, it provides a lightweight framework that encourages inspection and adaption through transparency. It assumes you don’t know everything up front and encourages you to deliver working software frequently to learn. Managing the unknown requires agility. Therefore, it is crucial that a product roadmap not provide a detailed list of features and timeline, but instead provides direction for the team to build the right software. In a nutshell: Do not bring a waterfall roadmap to a scrum product delivery.

5 Tips for Managing the Agile Product Roadmap

The following five tips will help you manage and deliver an effective agile product roadmap.

1. Focus on customer and user outcomes, not features and functions. Many roadmaps emphasize features and their delivery. But concentrating on customer outcomes makes it possible to describe the plan’s business focus. It also provides flexibility so that scrum teams prioritize the right things rather than requirements that may not deliver the right business outcomes. Avoiding product feature descriptions allows you to focus on intent and define clear measurable success, rather than test criteria. Finally, if the roadmap is well-written, you won’t need to continually explain the objective of a particular item to the rest of the organization.
2. Eat the elephant one bite at a time. Roadmaps, unlike college assignments, don’t benefit from size. The best roadmaps don’t provide a detailed list of features. Instead, they instill their audience with a sense of the product’s direction. Rather than providing detailed descriptions, find a phrase—like mobile-first release—that explains the intent. This helps others latch on to the meaning of the release and provides flexibility for the scrum teams to build what is required. Delivering frequent, incremental roadmap updates, or providing an intranet site that shows roadmap status, helps manage change and provide a clear sense of direction. Of course, those updates must clearly connect to the work of the scrum teams delivering against those broad objectives to demonstrate regular progress against these goals.
3. Be honest without scaring everyone. How many times have you been to the roadmap presentation only to hear that the killer feature has once again slipped to the next release? Roadmaps that support scrum teams should still forecast, but do it in an honest and open way highlighting that the farther out an item is, the less likely it is to be delivered. Roadmaps are like weather reports: the longer the forecast, the less likely it is to be true.
4. Add a clear measure of success to your roadmap and report data on its success. Instead of simply describing the need, provide a way to measure its success. For example, if a required capability is for the user to obtain their credit score, you could define that 12 percent of all customers execute the feature and 50 percent of new customers as a measure of success. By adding a measurable success benchmark to a roadmap item, you provide clarity and encourage the development team to instrument the application. Instrumentation provides a platform for lean analytics and connects nicely to empirical processes that are driven by learning and results. By connecting this data to roadmap items up front, there no ambiguity for the business or the delivery team.
5. Put everything in the context of true north. Everyone wants to work on something that matters. In Drive: The Surprising truth About What Motivates Us, Daniel H. Pink describes purpose as one of the three key elements to personnel motivation, along with autonomy and mastery. The purpose of a product is something more than its features, functions or even its user outcomes. Purpose describes why the product exists and is closely linked to an organization’s mission. Describing everything in the roadmap in the context of its purpose allows scrum teams to better understand why at the macro level. The purpose is reflected in the sprint goal, which helps define the sprint backlog and which is then reviewed in the sprint review. Purpose helps connect all these scrum events.

Communicate, Communicate and Communicate Some More

Ultimately, the product roadmap is a tool for communicating direction and providing a broad vision for timelines. It should be used to measure outcome success, communicating future intent and previous learnings. A short, business-focused, customer-oriented and measurable roadmap allows your organization to not only build the right product, but to motivate the entire organization. A successful product roadmap will become the narrative for your entire organization.

 Dave West is the product owner at scrum.org. He is a frequent keynote speaker and a widely published author of articles, along with his acclaimed book: Head First Object-Oriented Analysis and Design. He led the development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson running the North American business for IJI. He also managed the software delivery practice at Forrester research where he was vice president and research director. Prior to joining Scrum.org, he was chief product officer at Tasktop where he was responsible for product management, engineering and architecture. Email Dave at Dave.west@scrum.org.

By Dave West

To learn more about roadmapping, read the Product Roadmaps issue of Pragmatic Marketer.

The post True North: Managing Long-Term Roadmap Needs with Agility appeared first on Pragmatic Institute - Resources.