Why is SCRUM putting new pressures on product managers? The processes that are defined as Agile have often been hidden within the confines of software development departments. With the emergence of SCRUM, actors beyond the software development team, most notably product managers, are caught between those in an organization implementing the new approach and those that are not.
Over the past few years Agile processes have swept into development organizations around the world. The most notable process gaining ground is SCRUM. While developers have quickly taken to the process and altered their approach to thinking about software development, this change has created some difficult challenges for Product Managers, Product Owners, and customers. The focus of the article is to examine how Product and Development Managers are often caught in the middle of this change, the un-seen positives that emerge from it even though it can seem painful, and ideas on how to position the process with respect to customers and clients.
Why is SCRUM putting new pressures on product managers? Over the past ten years, the processes that are defined as Agile have often been hidden within the confines of software development departments. With the emergence of SCRUM, an Agile process that places emphasis on actors beyond the software development team, product managers are now caught between those in an organization implementing the new approach and those that are not.
In the past, many software development organizations would claim to be Agile simply by implementing certain concepts in their daily development approach, such as unit tests, regression tests, daily builds, continuous integration, peer development, and other common Agile practices. While on their own these methods make positive contributions to any development team, they have little impact on product life-cycle, customer expectations, organizational transparency, and the general controlled chaos that surrounds many software projects. To product management, these Agile terms, when they have any meaning at all, usually provide a notion of practices that would improve the general quality of the product, but rarely require more than just cursory involvement in the process. With SCRUM, just as much emphasis is placed on the product owner, who is frequently the product manager. In fact, for SCRUM to succeed all the actors involved in the process must come together effectively.
Much of the SCRUM process is based on just-in-time principles. While Agile processes traditionally focus on building only what is needed when it is needed, SCRUM goes further by minimizing requirements gathering to just before the initiation of the iteration, or “sprint”. The expectation is that the SCRUM team will have access to the product owner as questions arise and concepts need to be analyzed. Furthermore, the product owner is responsible for keeping the product backlog up-to-date, re-orienting the priorities based on customer and stakeholder feedback, and preparing the user stories for the upcoming sprints. While some of these tasks are already part of a product manager’s portfolio, the key element is timing.
SCRUM teams tend to work in the shortest, effective, iteration time frames possible. This is one of the core tenants of SCRUM (High smith, J. Agile Project Management:Creating Innovative Products. Indiana: Pearson Education, 2004.). The more frequently the stakeholders have access to the application, the more informed their decisions can be with respect to product priorities, functional feedback, and general usability. Frequent releases also help maintain a quality product. Thus, the expectation is that at the beginning of each sprint, the user stories are ready, the priorities are set, the results of the previous sprint have been reviewed, and any required pre-sprint discussions have occurred. This can be a daunting undertaking for a product manager who is already working 60 to 80 hours a week, not only doing his or her job, but as often is the case, plugging various holes in the organization. The workload is even heavier if the development team is using a two week sprint cycle, which is widely considered an optimum cycle for many teams.
Why do product managers find themselves in these circumstances? The main reason is that an organization, as a whole, does not recognize that the SCRUM process is more than just what happens in software development and consequently does not adjust itself to the process. SCRUM requires organizational change, not just software development change. This process impacts when a product is released and how priorities are set. Change becomes an asset rather than a detriment while giving everyone a stake and a portion of the responsibility. All of this creates transparency, but also accentuates organizational weaknesses. When an organization only makes a partial transition to SCRUM, the individuals that straddle both new and old find themselves squeezed in between the demands of both; and the most likely person in this role is the product manager. The new requires that the product manager makes a commitment to the process, while the old pulls the product manager in all the previous chaotic directions. What results is an almost untenable situation for those caught in the middle.
Without having other organizational expectations adjusted for the product manager, two things occur once the role of product owner is accepted. The first is that the product manager does even more work, increasing his or her own hours to compensate for the added work. The second is that the sprints break down, get delayed, and become dysfunctional as the flow of information becomes erratic and unexpected. Often, both situations occur to varying degrees. The result is that the process is undermined, creating the very situation that SCRUM is meant to alleviate: low morale, missed deliverables, increased chaos, and customer dissatisfaction. Inevitably, the process itself comes under scrutiny, when in fact the process has identified the weak link, which is the unavailability of the product owner due to the organization’s inability to position that person for success in the SCRUM process
How can this problem be addressed? The most direct answer is usually the one least likely to occur, which is that the rest of the organization must adapt to SCRUM. There are often numerous reasons why other parts of an organization do not participate or make allowances for individuals who are participating, some legitimate and others less so. At times the problem is a simple misunderstanding of the process, a perception that nothing is wrong, an aversion to change, an inability to change for other reasons, or just an unhealthy dependency on the product managers because of their knowledge and skills. In any case, the ability to get the complete organization to adapt may not be practical.
Alex Gladshtein is a development manager at The CBORD Group, Inc. in
Ithaca, NY. CBORD is the world's largest supplier of food and nutrition
software solutions, campus-wide ID card programs, cashless dining, and
housing management systems. Alex holds undergraduate and graduate
degrees from the University of Michigan, and when not obsessing about
his products he enjoys spending time with his wonderful wife and
cheering on the Michigan Wolverines.Contact Alex Gladshtein at firstname.lastname@example.org