Recently I was called into a mid-size software organization – and got right in the middle of a heated debate that had obviously been going on for some time. Development wanted to move to a Scrum-like agile model, and put pressure on the established Software Product Management (SPM) department to change their name to Product Owner which SPM refused vehemently. Development argued that the agile terms had to be used as symbols for the cultural change to a faster organization that the company executives were aiming at with the move to agile.
Everybody was appalled when I told them that they were discussing the wrong issue. Yes – terms can have psychological impact. But to make the organization really faster first priority has to be on processes, methodologies and a corresponding role model. Once these are sufficiently improved in line with the organizations‘ objectives, tasks and capabilities, you can agree on new names if you want to. Development argued that they did not want to waste time with these discussions since Scrum already defined processes and roles. Now I disagreed.
Scrum as defined in the Scrum Guide is just a framework that requires significant customization for any real world implementation. In fact, the majority of organizations do not even implement all the must-have elements of the framework, but then still claim to do Scrum. That is in particular true for the Scrum roles as is nicely documented in the State-of-Scrum Report of the Scrum Alliance (see http://bit.ly/1C391MK, pp. 22-23). I would not be surprised if this picture stayed quite the same in the report’s update to be published later this year.
The product owner role is defined as a member of the Scrum Team that feeds the team continuously with work in the form of user stories based on the prioritized requirements in the backlog. The product owner is the interface to the outside world, the rest of the team is shielded so that they can focus on their development work with optimal productivity. Implemented like this, product owner is a rather operational full-time role whose tasks overlap with a software product manager’s in the areas of requirements engineering and release planning.
This overlap needs to be sorted out in terms of process and role definitions. Some Scrum consultants claim that the most productive solution is one person who assumes both the product owner and product manager roles and all tasks attached to them – which they call – guess what? – product owner. Well – unfortunately wishful thinking for most organizations! This may work in some environments with one Scrum Team, but it can definitely not scale up. And the poor person who gets this combined product owner/product manager role will always be pushed by the team to prioritize her/his operational tasks. Over time the more strategic tasks are neglected – to the disadvantage of the product and the organization. Alternatively, operational tasks can be delegated to other Scrum Team members, but that boils down to an implicit split of the two roles again.
Don’t get me wrong! I see a lot of value in agile in a lot of situations, but it needs to be customized in the right way. In the end, my customer decided to have two roles – product owner and product manager – strongly linked for optimal communication, but with clearly defined different tasks and responsibilities. And it works – faster.
I will be speaking on this topic at ISPMA webinar on 4th November at 2:30 PM IST. You may register here to attend the webinar. I would request you to ask any questions you have on the subject. I would be happy to answer.
Guest Post by Hans-Bernd, Chairman at ISPMA.
Full disclosure: I am CSPO (Certified Scrum Product Owner), ISPMA Certified Software Product Manager, and Board Member of ISPMA (www.ispma.org).
For more details regarding Upcoming Webinar on PM Vs PO, click here.