Are effective Product Owners super-human?

The Product owner is the most important Scrum role. That’s a provocative statement but it’s true. It doesn’t matter how good your Scrum team is, if you don’t have a dedicated Product owner who’s prepared to take ownership, accountability and responsibility for the Product backlog and the prioritization of features, then the team will face an uphill struggle which may lead to failure.

In a Scrum team the Product Owner is solely responsible for managing and controlling the product backlog. This person maintains the product backlog, ensuring it is highly visible throughout the organization. They work with the team, ensuring that features are prioritized accordingly and that clear objectives for the sprint goal are agreed with the team.

In many respects the Product Owner shares many of the characteristics of the Product Manager within the Product Management domain. For example, a Product Manager in the classical sense is concerned with driving the product in terms of offering unique benefits and value to the customer. 

In order to achieve this the Product Manager clearly needs to be an expert on the product, but just as important they need to have a pulse on the market and understand their customers needs and wants. They also need to be able to work collaboratively with sales and marketing, technology, and the board to drive the product vision into a roadmap which in turn will inform and be informed by the overall business strategy and company direction.

In essence the classic Product Manager and the Scrum Product Owner are essentially the same role. One could argue that a Product Manager is more strategic in outlook, whereas the Scrum Product Owner is more tactical.

However, it is not uncommon for the Scrum Product Owner role to be fulfilled by someone other than a Product Manager. Sometimes a Business Analyst or a Project Manager may assume the role. From a Scrum perspective this doesn’t really matter so long as they have control over the content and priority of the product backlog and they are able to effectively manage the customers expectations.

What is important is that there needs to be a clear line of communication between the Product Owner and the decision makers within the internal  and / or external organization and this is where things can begin to get quite challenging.

For a Product Owner to succeed they need to have a strong personality and the conviction of their decisions. They may have to contend with multiple conflicting requirements from very senior stakeholders. In order to help maximize team productivity they haven’t got time to gain agreement through committee, they need to be able to make decisions immediately. This can make the Product Owner role a very demanding one.

Even more challenging will be the ability to translate strategic goals into (tactical) Scrum goals, particularly if the product in question is part of a larger product roadmap, which can outline the product requirements anything up to five years or more into the future.

They’ll also need to understand Scrum and ‘get it’. They’ll need to be able to translate the product roadmap into an effective product backlog with the appropriate prioritization in order to maximize the benefit of the product, and know what that benefit is.

That doesn’t mean to say that the Product Owner has to be super-human – they just need to know the product, the market, the strategic direction of the company and know how to properly engage and work with a Scrum team. Easy.

Agile Leadership (Part 1)

One has to be careful when making assertions that leaders exist in agile teams, not least because such teams are supposed to be self-organizing and ‘…accorded full authority to do whatever it decides is necessary to achieve the goal.’ The role of the Scrum Master, for example, is to be ‘…responsible for the success of Scrum and be the driving force behind all of the practices’.

A Scrum Master is definitely not a project manager in the traditional sense, although most people would probably agree that the role of a Scrum Master has more in common with that of a facilitator than a team leader. Yet to me the two labels are almost interchangeable , particularly when you consider the meaning of a facilitator as ‘a person responsible for leading or coordinating the work of a group’ or ’someone who makes progress easier’.

Clearly the Scrum Master has a managerial remit (if I may call it that) in that it is their responsibility to ensure that the values and rules of Scrum are enforced, that the appropriate practices happen, impediments are removed and the team are given every opportunity to succeed. However, there’s also a leadership dimension. At times, particularly at the beginning of an Agile journey or a new project,  the (prospective) Scrum Master may have to sell Scrum or Agile to  colleagues, senior management, and / or to clients. Developing this ‘vision’ can take some skill to articulate, particularly in organizations where traditional project management is the dominant logic. 

Interestingly creating and selling a vision are competencies usually attributed to leaders, so is the Scrum Master a quasi leader-manager? Possibly, but is the Scrum Master more of a leader than a manager, or more of a manager than a leader? A lot will depend on the organizational and cultural context in which the Scrum Master operates but it would help to have a good working definition of the differences between a manager and a leader.

John Kotter (1990) provided a good one in that leadership is all about coping with change, while management is about bringing order and consistency. However, it was Burns who is generally credited with clarifying the differences between leadership and management by introducing the concepts of transformational and transactional leadership, which have since been built upon by other researchers, most notably Bass.

Transformational leadership concentrates on the motivation and morale of followers while transactional leadership concentrates on the followers’ immediate self-interests. In many respects transactional leadership remains the dominant logic within many organizations since it is based upon contingency, in that reward or punishment is contingent upon performance. The transactional leader inevitably allocates work and uses management by exception, such that if something or someone is operating to defined performance criteria then it does not need attention.

By way of comparison transformational leadership is more of a selling game, involving the development of a vision and the selling of that vision throughout the organization. Creating trust and maintaining high personal integrity are essential if the transformational leader is to motivate followers. Such leaders are therefore often charismatic, focus on the big picture, and have an ethic grounded on moral foundations of intellectual stimulation and individualized consideration for followers.

Can you see any parallels here? For me transactional leadership leans more towards the management end of the management v leadership spectrum.  In this respect it is more akin to ‘traditional’ project management while agile project management is more aligned to transformational leadership.

Successful Scrum Masters embody a lot of the characteristics associated with transformational leaders. This is perhaps why a lot of ‘traditional’ project managers who make the transition over to agile find it quite challenging . Perhaps it’s because they are used to operating in a command and control context, where a transactional leadership style was the norm and indeed expected?

Transformational leadership is not something that can be easily learned. In fact some would argue that it can’t possibly be learned or taught since leaders are inevitably born that way. In turn this reflects a wider nature or nurture debate.

However, Scrum provides an excellent environment and framework in which teams can attain many of the benefits associated with transformational leadership.

Back to basics

The other day I was in a meeting with the CTO of major web portal, and he was telling me how his development team of 60+ had just completed their Scrum training and had their first sprint underway. Together with the board he had decided to implement Scrum wholesale, and let the teams take responsibility for self organizing, assigning their work and figuring out their fastest path for delivering quality software. As you can imagine, the management team were a little apprehensive but very excited about the possibilities. The CTO was prepared for his teams to experience some failures and he asked my opinion on whether they  were doing the right thing and what should management do to support them.

I found it quite refreshing how the organization had put it’s faith 100% into agile. In my experience it’s quite a rare thing for an organization go completely agile without first setting some success benchmarks and measuring these through a pilot. I was impressed how board members (for example the marketing director) and their representatives were assuming the role of Product owner within each team. I also liked how they were phasing in and staggering each team sprint, rather than going for a big bang with all sprints running in parallel (makes sharing specific resources between teams less of an impediment). For me the two things management should focus on were to let the teams know they were there to help remove the major ‘enterprise’ impediments and to also encourage the teams to focus on the basics. At the same time, management should adopt a more transformational leadership style, and avoid regressing into a transactional style when they perceive things are going wrong. More on this in a later post.

Understanding the basics of Scrum is critical in the early stages as there may be a tendency to drop or modify elements based on certain behaviors of experiences of team members. This is the challenge with Scrum, in that at first it appears to be a disarmingly simple framework for delivering software projects. It’s only when you start cutting your teeth for the first time do you realize differently. I was reminded of this when I was introduced to some of the newly qualified Scrum Masters, for a Q&A session. They asked many questions about Scrum, should they do it this way, should they do it that way, to which I replied ‘guys it’s up to you, but if I were you I’d focus on the basics first’. A few of the Scrum Masters, coincidentally the older more experienced individuals, questioned whether Scrum was too prescribed, particularly the length of the iterations, and wouldn’t it be more productive to adapt these now?

I suggested that they should give the four week iterations a chance, but by all means they were free to assess this during the retrospectives, and if they agreed as a team on a better duration then go for it. However, it was crucial that they all concentrated on getting the fundamentals right first in order to give themselves a chance to get to a norming state of self organization, thereby enabling increases in productivity and quality. Otherwise adapting Scrum too soon ran the risk of  failure and possibly loosing the confidence of the teams and the organization as a whole.

To help bring the point home I asked the Scrum Masters what the fundamentals of Scrum were.  As you’d expect most of them could recite the key elements like the product backlog or the daily stand up, but when I probed further into the constituents of each element or how these elements should be used in Scrum things started to get a little fuzzy. Hardly surprising given these were green Scrum Masters who were probably struggling with forming the team. Yet it illustrates the point that for teams to get the best out of Scrum and to be able to call themselves agile they need to use Scrum the way it is intended. Applying a few of the principles here and there can certainly help teams become familiar with Scrum, but it won’t make them Agile. 

That’s why, even now, I still sometimes refer to the Scrum crib sheet that I put together shortly after completing my CSM in 2004. Over the years it’s been adapted slightly, but it certainly helps to not only reinforce the principles and characteristics of Scrum, but also the wider values and principles it embraces through the Agile Manifesto.

Agile Leadership (Part 2)

Until relatively recently the research into project management has focused on the skills, knowledge and procedures of project management in the context of an “iron triangle” of time, cost and quality (or scope) constraints. Even now if you take a look at some of the key project handbooks by the likes of Turner, Simister, Morris & Pinto, or industry standards such as the PMI’s Project Managers Body of Knowledge (PMBOK) you’ll see what I mean.

However, just because you’ve got the qualification doesn’t mean you will be a successful project manager. The same applies in the agile world.

Experience has a large role to play, but perhaps more importantly is the leadership style of the project manager. Any successful project manager will tell you that in order to get things done they have to adopt their style depending on the organisational context, whether it is being autocratic with a team or consensual with stakeholders. Its how you engage with others and the relationships you build that ultimately determines how successful you are.

Clearly success doesn’t happen in a vacuum, but if you follow the prescribed process and have the ability to adapt your style to get things done then the likelihood of success will be higher, at least in the eyes of your sponsor and stakeholders.

This is where it gets interesting, because there is no clear definition of what project success is, nor how to measure it. What constitutes project success remains a contentious issue within the project management world, and it will differ between organisations, teams, stakeholders and academics. But that’s for another post.

When it comes to leadership the ‘traditional’ project manager clearly differs from their agile equivalent. Recent empirical research has indicated that successful traditional project managers appear to exhibit a greater reliance upon managerial (MQ) and intellectual competencies (IQ) (Geoghegan & Dulewicz, 2006; Muller & Turner, 2007), whereas their successful agile counterparts tend to exhibit a greater dependency upon emotional competencies (Porthouse & Dulewicz, 2007).

Emotional competencies are another way of saying emotional intelligence (EQ) and this has been defined as “the capacity for recognizing our own feelings and those of others, for motivating ourselves, and for managing our own feelings and those of others, for motivating ourselves, and for managing our emotions well in ourselves and in our relationships” (Goleman, 1998).

I’m not saying that traditional project managers don’t rely upon EQ when managing their teams, far from it. However, when I reflect on how I managed traditional projects in the past I usually defaulted to a transactional leadership style, more concerned with meeting milestones on a schedule, and telling teams what they must do, and when by, rather than what they could do.

Although this is an anecdotal example, and an oversimplification, it does imply that this is typical behaviour for a traditional project manager, especially where the research is concerned.  More time and energy is spent on the process and the mechanisms of control (the MQ and IQ), rather than focusing on coaching and empowering the team (the EQ) to take on a self-organising character and affording them full authority to do whatever it needs to do to achieve their goals.

In the next post in this series I’ll present a framework that can be used to determine the types of competencies required for a successful agile project manager, and how these relate to a standard definition of MQ, IQ and EQ dimensions. It won’t be a guarantee for success, but rather it will help individuals or organisations to tailor learning and development initiatives and begin to think about the types of skills and competencies required to deliver agile projects and initiatives.

REFERENCES

Geoghegan, L. and Dulewicz, V. (2006) Project managers’ leadership competencies and project success. Henley Working Paper HWP 0607. Henley-on-Thames, Henley Management College.

Goleman, D. (1998). Working with Emotional Intelligence. London, Bloomsbury.

Muller, R. and Turner, J. R. (2007) “Matching the project manager’s leadership style to project type/” International Journal of Project Management 25(1): 21-32.

Porthouse, M. S. and Dulewicz, V. (2007) Agile Project Managers Leadership Competecies. Henley Working Paper HWP 0714. Henley-on-Thames, Henley Managemet College.

Let me introduce myself..

Welcome! My name is Michael Porthouse, and I’m passionate about helping teams and organizations adopt Agile software development using Scrum. My background is predominantly in consulting, focusing on software delivery and project management within the retail financial, investment banking, telecommunications and media and entertainment sectors.

I first came across Scrum back in 2004 when I was a ‘traditional’ project manager and I acted as an independent sprint retrospective facilitator for a client team. I was amazed at the buzz and the energy coming from the team and how enthusiastic they all were. More importantly, everyone in the team contributed with open and honest reflections. Nothing like the typical project post-mortems I was used to!

As a result I signed up for the next public Scrum Master course and was fortunate to be trained by Ken Schwaber and Joseph Pelrine, receiving my CSM in the summer of 2004. Since then I’ve worked in variety of roles, including development manager and a department head, where I introduced Scrum into my teams.

I am particularly interested in Agile Leadership, and the competencies which make a successful Agile Project Manager, and I specialized on this subject for my MBA. With the involvement of members of the Scrum Alliance my research established that successful Agile Project Managers rely more upon emotional intelligence competencies than their traditional counterparts. For me having been a practicing ‘traditional’ project manager and then a Scrum Master the findings were not surprising but it was good to have some rigorous research confirming my hypothesis.

This blog will therefore provide me with an opportunity to share my learning and personal reflections on using and introducing Scrum to teams and organizations. If my experiences can help anyone about to embark on, or are already on an Agile journey then so much the better.