Analogy: Your Restaurant Experience
By way of analogy, imagine you come to an expensive restaurant, being willing to pay for a very expensive bowl of an exotic soup. You sit at a table and wait for your dish to be delivered. When a waiter comes, you see that on his tray, there are raw ingredients that are used to prepare a soup, but there is no actual soup. You are puzzled. This is not what you paid for. Each ingredient, although a required constituent of a final product, is not a product in itself. Even if a waiter, head chef and restaurant owner tried to explain to you that ingredients also cost money, and are [raw] products on their own, you still have a strong reason to disagree, as you paid your money for something that you can immediately consume upon delivery: a delicious, exotic soup. As a customer, if you do not receive what you paid for, you will be unhappy, probably, ask for your money back and not come to this restaurant ever again.
What Is Operating Model
What is an operating model? This is the term that many companies like to use, to describe their internal ways of working. Essentially, instead of using the term that may suggest an adoption of a commercial, off-the-shelf solution, a.k.a. framework, companies prefer creating their own, language that suggests that a home-grown, unique, sophisticated and tailored approach is being implemented. Thus, the term: OPERATING MODEL.
This sensitivity and avoidance of large, of commercially widespread, populistic, “unpack & install” solutions is understandable, especially, given the historical “dark side of agile business” that involves a lot of relabeling and “terminology mapping“. But of course, it always begs the question of how unique that justifies creating its own, special operating model (a.k.a. framework)?
What Is “Product” Operating Model
Following the same train of thought a “PRODUCT” OPERATING MODEL (quotes are intentional) implies that a company’s ways of working are optimized for product development and delivery (also assumes customer/user centricity). This further assumes that a company’s organizational design is changed to support a product operating model. More specifically, instead of defining “products” around traditional bodies of work (portfolios, programs, teams’ capabilities, teams’ private technical backlogs), real products should become a leading factor that dictates how teams (also, the rest of an org, involved in product development) are structured, what capabilities they should have and what information should be kept in product backlogs. Traditional ways of managing work (portfolios, programs and, of course, projects) should become trivial and, eventually, seize to exist. For majority of organizations, this means 180 degrees course correction to their agile transformation.
The analogy above (an exotic soup) is synonymous to a product development situation, when at the end of a sprint (Sprint Review) users are presented with multiple technical components that were built by a scrum team but not not fully integrated into complete features. This kind of a sprint review, very quickly, will becomes a low-interest event for business people and they stop attending it.
Lack of product centricity in sprint-work is often caused by lack of teams’ capabilities, to deliver front-to-back product features, without external dependencies. This is the problem of organizational design. If a team is designed, as a component/delivery team, its end-of-sprint delivery would be a technical component, not a product feature, and therefore, of low interest to business people.
This lack of product centricity in team design can be further traced to a weak (fake) product definition, with each team, adopting a belief that they develop a “mini-product” or a “sub-product”.
At scale, and especially in organizations that rush to make a political claim that they have become a true product organization (large banks is a good example), this leads to what is a.k.a. Productization Saga – each and every body of work becomes a product.
This is why for majority of organizations, an internal “product operating model” is just a part of a much bigger Agile Theater Chaos.
Unless we see deep systemic improvements that involve changes in a reporting structure (flattening), removal of boundaries between traditional vertical silos (departments, groups) and ownership-by-technology areas (platforms, shared services), reduction of local management, in favor of self-management, these product operating models are doomed to fail.
With that, some roles, maybe, even entire job families, such as fake program managers and product owners (with no real products to manage and business priorities to own) and agility leads (ex-no-longer-needed roles, fabricated just to keep people busy) may have to be reduced, as non-essential, because they do not measurably contribute to ROI.
Typical Organizational Challenges – If You Have Them, Ask For Help
The below list of challenges (top 25 are listed but there could be more) indicates that your agile transformation’ is offtrack and your ‘product operating model’ does not work. If you recognize that you are having a problem, you may wish to rethink if/how you wish to proceed further, because the further and for longer you move in a wrong direction, the more difficult it would be to course-correct later.
If you feel that you need help, in the form of an assessment, reflection, private consulting, training or extended coaching support, please reach out. Do not wait until it becomes too late.
- In a rush, to become agile, did your organization adopt an “operating model”, by incorrectly copy-pasting something that has been well known in the industry for years but required a much deeper understanding, before implementing?
- In pursuit to become product-centric organization fast, did your end end up with tons of products-wanna-be, such as: “area products”, sub-products, technical products, “tech-for-tech” products, “no_real_customers_no_human_users” products?
- At your company, are products defined by a technology managers and architects, or business people? What impact does it have on customer centricity?
- Do multiple back-end applications get integrated into a single product way too late in a process, resembling a classic waterfall?
- Does it feel that coordination between so many, so-called, products is unexplainably hard, time consuming and expensive?
- Does it feel that the financial/budgeting aspect is missing from product management/ownership and is handled by org structures that are too distant from product management/ownership/development?
- Does it feel that product managers and products owners, “manage and own” in spirit only, and are, mostly, disempowered?
- Do you feel that technology people lack basic understanding of business, whereas business people have lost their trust in technology?
- In your organization, does technology dictate “what agile is” and expect business to follow?
- Do you feel that too many locally optimized, mid-level managers are focused too much on their own, personal successes that frequently do not add up to a collective success?
- Does it seem that there are too many local initiative owners, whose priorities compete for budget, and whose personal agenda prevails over collective agenda?
- Does it seem that legacy resource management/sharing and skill set capacity allocation are being applied to agile (adaptive) ways of working?
- Is executive management disengaged from strategic discussions that define value?
- Does executive management set strategic priorities?
- Is there a lack of synergy between business strategic goals and technology strategic goals?
- Is there a lack of effective collaboration among technology teams, and between business and technology?
- Are people still confused with how to focus on products in an environment of portfolio-to-program-to-project management?
- Is there a confusion between portfolios of true-real products and traditional budgeted work, loosly called “portfolios”?
- Is there a misalignment between strategic goals, product roadmaps and product backlogs?
- Is there a confusion between outputs and outcomes, defined by short-term and long-term plans?
- Is there a confusion between true product/feature teams and component/application/delivery teams?
- Is there a gap between financial decisions/costs and product prioritization decisions?
- Are there challenges in identifying meaningful metrics and separating them from vanity (gaming) metrics?
- Is there confusion about what should be included in executive reports?
- Is there a confusion when to apply: Scrum, XP, Large Scale Scrum, Team Kanban, Enterprise Kanban?