The post Exploring The Agile Product Operating Model appeared first on Pragmatic Institute - Resources.
]]>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.
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.
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.
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 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.
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:
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.
]]>The post How to Scale Agile: Simple Ideas for a Complex Problem 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.
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.
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:
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:
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##
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.
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.
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.
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.
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.
]]>The post True North: Managing Long-Term Roadmap Needs with Agility appeared first on Pragmatic Institute - Resources.
]]>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.”
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.
The following five tips will help you manage and deliver an effective agile product roadmap.
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.
]]>