Are you a product owner and wondering how you can impact the “product vision”?
Don’t worry, be happy, you cannot!
Did you know the words “product vision” don’t even exist in the Scrum Guide!?
That’s correct, they were removed in the 2020 version.
Why write this article, what purpose will it serve?
I often get asked why I share my “unpopular viewpoints” on Agile and Scrum.
To me, the Agile industrial complex has done a lot of damage chasing multibillion-dollar revenues. There is a lot of work required to undo the damage, part of this is raising awareness and guiding people who love the world of product development on what BS looks like and how it can be avoided so they don’t end up working in factory-like teams.
In this article, I will explain why you can fundamentally not contribute to the product vision in the role of Product Owner if an organization practices Scrum.
We will also briefly look at why Scrum is a fundamentally flawed concept for product development that should only be used by certain organizations in 2022, as it is not fit for purpose for modern product practices.
There are a few articles over the last decade that have covered why Scrum is just terrible, however, they do not talk about the impact on product & business vision!
For instance, a great quote from John Cutler’s 2017 ‘The trouble with Scrum’ article is – “They’re shipping crap no one wants. Fit for purpose improves slightly, but not as much as you might expect.” – He talks about the feature factory model, created by scrum teams.
Some articles look at what is Zombie Scrum and then there was this beautiful illustration on ‘Shiteration’ by Mauro Strione in 2019 showcasing problems with Scrum – or as some people call it scrum anti-patterns.
While some might say these are anti-patterns, I strongly believe these are the inherent problem with scrum. It can and is weaponized. So why not just avoid it?
Sidebar
Before you dive into this article and wonder why my views are so strong against the world of Scrum & Agile, understand that I first tried to work with Scrum in 2016 across multiple teams and industries.
I was once a supporter of the ways of Scrum and even worked as a Product Owner and Scrum Master across multiple different organizations. I have even been offered the role of an Agile Coach multiple times. (Yuck!)
People in the past have even called me an “Agile Purist/Ninja”. However, when I found issues with the fundamental problems in the world of “Agile and Scrum” I decided to share what I found.
When it comes to software delivery, I have personally taken many organizations and teams on a journey of Scrum, Agile, Kanban, and DevOps and found what works and what doesn’t. In this article, I will shed light on some of this.
My opinionated views are based on fact/reality and not idealism as found in the Agile cults.
Some people who have similar journeys can relate to them while others find it hard to understand and refute to even understand what I am saying.
Summary of this article
The multiple layers of fluff strategy – Product vision vs Business vision vs Product goals
3 main types of teams in product development in 2022
Business Management Canvas, Business Model Canvas & Product Vision/Strategy Canvas
The origin story – why is scrum flawed – How scrum stemmed from factory production management, project management, and the inherently flawed design of Scrum, which spread like an epidemic. The Kaizen Paradox and why Scrum doesn’t lead to innovation.
The multiple layers of fluff strategy - Business vs Product Vision vs Product Goals
I have found that in product development businesses, there are multiple layers of fluff!
To keep it simple, let’s consider the 3 main ones.
Business Vision
Think of the strategic long-term goals – for instance, increasing share valuation by 100 Mil.
They are driven through a business strategy, normally drawn from a business model canvas, market research, and solid competitor analysis to position the business financially well above the rest of the competition or grow it to a certain size.
Product Vision
A business may consist of multiple products, so these happen to be strategic longer-term goals for a product. Think of them as the Big Hairy Audacious Goals. For instance – Be the number one global real estate platform.
Product Goals
These are more action-oriented and tactical, which can further be broken down into initiatives. For instance – Create an additional revenue stream with an initiative of launching a particular feature that shifts revenue by 10%.
What is the importance of the fluff?
The fluff drives alignment, which impacts value creation and is a critical piece in influencing and driving decisions among teams.
I have covered the importance of fluff in detail, plus the technique of product evangelism to alignment, in my previous article written in Jan and updated recently in Sept (link) – be sure to check it out.
3 main types of teams in product development
The way I have seen the fluff play out is very different based on the approach an organization takes. Currently, there are 3 main types of organizations out there – empowered product teams, Agile/Scrum project teams, and Waterfall/SAFe teams.
1. Empowered Teams
In empowered teams, the business leadership team works on a business vision in cohesion with an empowered product team. The product team contributes to the Big Hairy Audacious Goals, which then allows them to determine the product goals they need to deliver. The team helps drive the decisions, strategy, and goals. It’s not an order-taking mentality from up top. Things are fairly simple or so it may seem.
2. Scrum Teams
In Scrum, aka ‘scream’ organizations, the business leadership – normally the HIPPOS works on a 5-year business strategy plan – most likely in a PPTX file saved on SharePoint.
This vision is not in cohesion with any product development team because that is the inherently flawed design of scrum teams. They are just order takers.
Soon after the ‘order taker’ – i.e. the product owner will receive their orders from the minions in middle management to get the “Dev” team to deliver on a certain set of requirements to build out a certain Frankenstein product that no one needs.
The Product Owner then goes to the scrum team and pushes them to deliver on some “commitment” the team needs to make. The focus is simply production/output focused.
These teams are normally equipped with “Scrum Masters” who whip the team in shape and help them improve “delivery efficiency”.
3. SAFe Teams
In SAFe organizations, the condition for the delivery teams worsens as there is now a portfolio of minions with everyone having a backlog of some sort!?
Not to mention a Fake product manager role that has no bearing whatsoever on a real product manager.
These large-scale organizations that implement these are generally dinosaurs stuck in the very problem they created a hampered growth cycle.
Their key focus is governance and process so they look forward to things like “SAFe” which gives them the false hope there is control over what is happening and “Risk” can be managed.
Business Management Canvas
In the snippet below, I share a partial business management canvas.
This one is specifically for a B2B org with core product teams (platform & experience), PaaS professional services, and SaaS implementation teams.
They have fairly complex business models and business units, as they are doing both SaaS and PaaS products.
This results in having a fairly complex portfolio with a greater level of scale of operations required but still aligned on a vision – business, portfolio, and product.
I have found this type of ‘organization model’ common in older software organizations that have tried multiple transformations including the ones to move their customers from PaaS to SaaS or even some that stem from professional services or sales-led organizations.
They are generally still struggling to connect the dots from strategy to tactical this is where product vision comes, and the rest of the fluff layers come in.
It helps drive the alignment of where the organization is heading and provides direction to teams that operate therein, creating a level of psychological safety.
Sometimes these teams need a compelling bundled vs unbundled product portfolio mix strategy and need to figure out which customers to service and which products to sell and what to deprecate.
It is important to map this type of system design out in an organization to help derive how the strategy connects to the tactical to support layer and data points beneath it.
The full system map looks something like this, which I will cover in future articles at digitalproductjobs.com.
Product vision and Business model canvas
When I coach product teams, I try to explain the difference between the types of goals by using a blend of a business model and a product vision canvas.
The key callout here is that executives in an organization set key business goals based on their business strategy.
For instance, they are chasing a 1-billion-dollar evaluation.
They then need to work with their head of departments – typically a head or VP of product to determine the key strategic goals and initiatives that may stem from that. (Examples in images)
These VPS will normally approach the Product Management team – Senior PMs, Group PMs, Product Directors & PMs to help understand how to enhance the products through either value creation or capture.
It is then at the PM level the tactical initiatives are executed.
Note – how there is NO product owner mentioned here?
This is because the role of the PO doesn’t cover any of this!
Scrum is flawed at that, and its excuse is to say it’s a “lightweight” framework which is a bunch of BS! In my opinion, that’s just a sign of inherent problems and ignoring them using “lightweight” as a COP OUT.
The origin story – why is scrum flawed from its inherent design and not fit for purpose
Scrum stemmed from factory production management, and project management. This resulted in the inherently flawed design of Scrum. Scrum then spread as an epidemic has resulted in a massive number of feature factories and the Kaizen paradox.
We have a global problem where due to low product development maturity software product management practices that exist are either poor or nonexistent.
Scrum adds to this low maturity by selling certifications, training courses, and conferences. It's a multi-billion dollar business model.
Scrum came about at a time when most of the work was done in “projects”. In addition to this, most of the software funding was carried out by government organizations.
Thus scrum was inherently designed to manage expectations while delivering some level of scope.
Scrum’s design of the Product Owner role has made it equivalent to an order taker/ waiter. In reality, the Product Owner takes an order from their stakeholder and then passes the order to the kitchen staff to process.
Let’s get some facts straight first when we look at inherent design problems with scrum
1. Scrum failed to copy the great parts of the TPS - The Toyota Production System
The concept of scrum came from the production line system in Toyota; this was designed for Toyota specifically and wasn’t meant to be broken into mini patterns and manipulated as a system by itself. A good example here is another example where Hitachi Tool Engineering failed to copy the TPS as pointed out by the late Eliyahu Goldratt – the author of the must-read book The Goal. When Scrum broke off into its own thing, it completely ignored the ‘just in time aspect.
An example of this is the backlog on most scrum teams.
That is the biggest example of WASTE and is not lean!
This is why Kanban as a framework is so much better than Scrum and why many high-performing teams gravitate to Kanban or DevOps, which replaces Kanban. Scrum was used in the government where process controls are heavy, and everything is driven by ‘project lifecycles’.
This ensured that it was designed for “Project environments” not modern-day product-based. Even with all the updates to the Scrum Guide, the inherent design problems have led it to be purely useless and not fit for purpose.
2. Failed to copy Japanese martial arts bushido
Japanese martial arts culture (Bushido) and Scrum are closely related, or at least that is what Jeff mentions in his book when he talks about “Shu Ha Ri.” This is what Jeff says “Scrum has its roots in Japanese thought and practice. When I traveled to Japan recently to meet with Professor Ikujiro Nonaka, he made it clear to me that in Japan Scrum isn’t seen as the latest work fad. They regard it as a way of doing, a way of being, a way of life. When I teach people how to do Scrum, I often talk about my personal experience studying the Japanese martial art of aikido over the years.”
I can relate to what Jeff says here, as I have spent the last 29 years training in the world of martial arts and even practiced Aikido for a few years.
So, I am well aware of what Jeff is talking about, but the inherent problem here is that Scrum is built in an immutable way and it fails to understand that in martial arts, the practitioner doesn’t just do “Kaizen” – incremental change, they practice all of it including ‘Kaikaku’, ‘Kakushin’, ‘Mushin’ and ‘Zanshin’.
These all impact how things change, improve, innovate, and are delivered. The simple way of thinking about the distinction between Kaikaku and Kakushin is that the former is something new to you. Kakushin is new to everyone. Scrum leads to what is called the “Kaizen Paradox”.
“The Kaizen Paradox is a common predicament for many businesses, where small investments are made to achieve productivity gains, but in so doing, they dilute the business case for a greater investment, causing them to plateau at a lower level of productivity.” Sound familiar?
Simply put - Scrum is not designed to help perform radical change or disruptive change.
Conclusion
Scrum stemmed from factory production management and project management. This resulted in the inherently flawed design of Scrum. Scrum’s design of the Product Owner role has made it equivalent to an order taker/ waiter.
A good contrast to look at is the role of a product manager. A product manager can impact and drive vision at a product and business level.
Of course, this changes with the scale of the organization. Because in a startup, the business vision may be the product vision. While in larger organizations, multiple product visions will contribute to a portfolio vision and, ultimately, the business vision.
KJ Sethna
Read also
Experience the new way of doing product management
