The Achilles heel of Agile is without question the Product Owner role, or lack thereof.
In this two part blog I will discuss the role of the Product owner in internal teams and the very different role of the Product Owner developing for a competitive market place and I believe I will shed considerable light on the issues plaguing so many IT functions today who are less than enamoured with the benefits of their agile implementations.
First of all let me say yet again that Agile was never intended to be the band aid of all band aids. It was created to solve a specific problem which it did/does effectively and it has since been overhyped and misused to the point where in a high proportion of implementations all that is left to recognise it is a few rituals and a lack of any structure. I’m not talking about these latter implementation, but genuine agile teams building products for the mass market and internal teams building small systems for internal stakeholders, but failing to do any better than those who went before them.
In theory, a good agile product team can be highly effective if asked to develop a small system for an internal client and prepared to adjust to the different environment before releasing the handbrake. The job is considerably less complex, communication and feedback more readily available and little to get in the way. In reality, though, it is rare that anyone with such a prized asset as a high performing agile product team would let them spend very much time on internal systems.
The difference between a Product manager/Product Owner and BA/Product Owner is significant and accounts for the bulk of the problem I set out to discuss today.
Within an organisation the problem to be solved is a complex one, but one IT departments have greater experience with. A cross-section of the organisation need to work collaboratively to achieve a business goal such as entering the correct data and preparing end of month management accounts. They need a system to reduce the effort and help them achieve the goal more effectively. They are probably operational people, or maybe marketers or accountants. They have no experience with systems. Additionally they are most likely not a team and there will be tensions and politics all heightened by the potential disruption of a new system. The will to agree and cooperate is weaker generally than the will to adapt a defensive stance.
Someone needs to ask the right questions in the right way, record it turn it into a design, bring people along sometimes, dictate at other times and know which reaction is right for which situation. The work to define a product is also and more importantly the design of a process and a new or slightly changed team which is far more significant than the binary stuff. Does anyone still remember the mantra: People, Process then Technology
This is the territory of a skilled Business Analyst and the role should normally represent the customers and oversee UAT to ensure continuity into live and provide a measure of support and adjudication to get it into smooth operation. Sadly few BAs are qualified to do this and come from a wide variety of backgrounds, the majority technical in some way, but amongst the ranks are some very good ones who have self taught. A skilled and experienced technology project manager is able to hire and to guide and oversee where necessary. That’s a whole different blog though.
A good BA, working with the support of an enlightened organisation will be preparing a business case and tracing benefits back to features as far as possible. He will trim the scope with stakeholders to fit time and or budget and give the incoming Project manager a well groomed document of requirements and a charter with a clear definition of what to deliver, the estimated costs and expected benefits. In the course of the project all of this will be further refined before design and development of the technology begins. By that point there is a very good knowledge of the scope, the costs, risks and stretches available and generally only a small allowance for deviation is needed. Skilful project managers can deliver these projects day in and day out with reliability and there is little room for significant failures.
A skilful Product Owner will do a very similar role, the main difference being that he won’t stress himself trying to plan the maximum benefits and predict the end product and he won’t get involved in process design or change management, he will just define a minimum viable product, i.e. the smallest working subset that is delivering a useful function and then start adding features. He will keep a sprint ahead of the developer asking the stakeholders to decide what they’d like next.
Depending on the organisation, the final outcome may differ widely, but in a mature organisation, I would expect it to be very similar. I sometimes think of Agile in this context as IT’s revenge on bullying businesses. In many organisations It is like giving the addict a truck load of heroin instead of nursing him, but in many it keep both sides happy and there’s a lot to be said for that especially if the alternative is stalemate.
In the internal scenario, therefore, I would have to say that the Product Owner role is also a weak point, but not always with really significant costs.
Product Manager/Product Owner
The true Product Owner is a close cousin of the traditional Product Manager a role that is not itself that well understood by many.
The traditional Product Manager either was a dual role or specialised in one or the other of Product Planning and Product Marketing.
The Product Planner owned the product Roadmap. This meant expertise strategic marketing to understand markets, gain and maintain competitive insight within the market, build a competitive analysis and pricing analysis and position an offering that had a powerful chance of succeeding in its market . All this was represented in an MRD. Market Requirements Document. A high proportion of bright ideas never make it through this process because it becomes acutely obvious that it is flawed in some way and can’t possibly be a commercial success. The value therefore of this process is immeasurable.
The Product Planner would then expand this product proposition into a set of detailed features and produce a PRD which went to the development team to develop and test the product and the documentation, help files etc, while he worked with support, distribution, and other teams to prepare for launch and life after launch. A good Product Planner brings continuity to the process and produces rounded user experiences as well as defining feasible profitable business propositions.
The Product Marketer, builds on the strategic proposition to define market segments, messages, approaches and tactics to launch the product and drive ongoing sales and providing critical feedback to the product planner on how the market reacts and how its attitudes change so that the offering remains competitive.
Another common breakdown of the role was between a Technical Product manager who had a sort of CTO role in the product team, a Marketing Product Manager to handle launch and ongoing marketing and Strategic Product manager who was very similar to the Product Planner.
The skill of product management is very significant. Product Managers develop an insight and instinct for their market through immersion over time and they instinctively come up with ideas for potentially winning products based on this deep knowledge.
All product managers understand the importance of stage gates, even if sometimes a little too rigid by design, in the process of whittling down potential products to come up with winners worthy of investment and to cut out the low performers early. Great Product managers know when to persevere with a slow starter and let it grow, weak product owners keep on long after the product has died wasting effort and diluting the brand. It’s an art as much as a science and the most valuable knowledge is often tacit.
Enter the Scrum Product Owner
First of all let me say that there are many product managers who have adapted Scrum as a replacement for the PRD and this has proven a tremendous addition to their armour, but sadly there are far too many who have been given the role because the company is implementing Scrum and it demands a Product
Owner. I have met a great many of them who had no background at all in product management or product ownership and in fact the most common ting is the head of the business unit, not having the time for this close working with developers, delegates the role to a fairly junior person. Despite working with more than 25 different businesses in the past decade, I have yet to see a single product owner with anything approaching suitable skills for this very important role
“Certified Scrum Product Owners® have been taught the Scrum terminology, practices, and principles that enable them to fulfil the role of Product Owner on a Scrum team. CSPOs are typically the individuals who are closest to the “business side” of the project. They are charged by the organization to “get the product out” and are expected to do the best possible job of satisfying all the stakeholders. CSPOs maintain the product backlog and ensure that everyone knows the priorities.” Scrum Alliance.
The Product Owner is responsible for:
-Establishing the high-level vision in terms of creating value for stakeholders
- Obtaining budget
- Getting input on features to be provided and understanding their relative value to the business-stakeholders
-Providing the team with context as needed to help them with development of the sprint
-Agree with the team a reasonable commitment to outputs for a sprint
-Inspect sprint outputs and if necessary suggest improvements
-Evolve the product backlog from Sprint to Sprint
-Decide when to release software to market or to internal stakeholders
-Maintain clear release criteria, dates scope, burn down charts etc
-Take responsibility for return on investment
-Make clear decisions when asked and not constantly need to refer
What you may have noticed is that that there is an almost nonchalant dismissal of so much of what is vital to make products successful.
Scrum training spends typically half an hour talking about how to develop an elevator pitch and write a short vision to paste on the wall near the scrum team. As far as strategic product planning goes, that was about it in my case and most people report a similar experience.
Again don’t read into this a push back against Scrum, I have a lot of respect for intelligent usage of Scrum to develop spirally, what I am simply pointing out is that this most pivotal role in Scrum is not the want to cut corners on.
In fact, if you accept the common argument that agile came about as a solution to the problem of technical teams always being blamed for delivering late and by association with that for cost and profit issues etc, then you must surely realise that the one part of agile actually addressing this issue directly is the person who owns that relationship between the business unit and the technical team. i.e. the Product Owner.
Following that same thread of thought, It is not hard to arrive at the assumption that techies solved their problem once they handed the product owner responsibility over to the business and eliminated the big schedule gantt with a hard date and furthermore that perhaps they had got the measure of their business colleagues after all.