SCRUM: The Product Management Challenge
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.
The worst solution is to do nothing and let the process fail. This will subvert all the efforts to address the circumstances that initially led members of the organization to search for a new approach. A compromise is to attempt to use the SCRUM process beyond development. One way to do this is to have an intake sprint before the development sprint begins. This is a sprint for just the stakeholders and the product owner, lasting the same duration as a development sprint. These sprints are structured like a software development sprint, but the tasks are centered on generating the information required by the software development sprint team. Normally these would occur just before the software development sprint, for example, ending the Friday preceding a Monday development sprint planning meeting. In effect, this creates a process lasting four weeks from initial functional discussion to availability in the product for review. The motivating force for the intake sprint would be an understanding that any task not completed in this intake sprint would not be accepted by the development sprint, in a similar fashion to how any uncompleted development task is not included as part of a release at the end of a sprint. For the intake sprint to be effective, a commitment must be made by the members of the intake sprint to the approach and completion of prioritized tasks, just as in a development sprint. This technique allows individuals who are part of other groups to have a greater stake in the process and motivate more individuals in an organization to increase participation. The benefit is that the product manager is not the only individual carrying the burden and the added participation places greater emphasis on organizational commitment.
Another compromise is to provide support assistance for the product manager. This support may not even be for SCRUM, but for other duties that could be executed by different individuals in the organization. Additional support is particularly important for those product managers who have responsibilities outside the realm of product management. These tasks prevent product managers from effective participation and are often the cause of unexpected interruption. The organization already pays for these tasks with hidden costs and positions the sprints for failure.
A third approach is to allow the sprint team to act more independently, work more closely with the customer, and create some of their own user stories. This allows the team to use one of the SCRUM principles to solve their problems (to be self-organizing and agile based on changing circumstances to ensure that the sprint is completed). The downside is that by missing input from one of the most critical members of an organization, the product manager, the development team may require more iterations to get closer to the product vision and may lose user story velocity by allocating team members to other tasks.
Whichever approach is taken, the most important aspect of the SCRUM process is continuous improvement and adaptability to changing circumstances. No matter how badly one sprint may go, it has an end, providing an opportunity for change. Members of a SCRUM team have a responsibility to find the optimum road, even if the organization is not structured to provide complete process support. At the same time, product managers should not accept their fate, but work actively as change agents for the process, much as they work as agents for the products they represent.
There is no guarantee that every organization implementing SCRUM will provide complete support for the process, and consequently, the product manager may be extraordinarily challenged. At the same time, having SCRUM fail is worse for all involved. Thus, it is necessary to derive alternative solutions to move the process forward. While the solutions may not be ideal based on SCRUM principles, the process will spotlight the problems and the participants should continue to move the organization to change, just as SCRUM teams embrace change.
Special thanks to Amir Kolsky from Net Objectives for an introduction to the concept of an intake sprint.
Looking for the latest in product management news, articles, webinars, podcasts and more?