On a project using a sequential development process, the project manager has the difficult job of ensuring that the product a customer wants is the one that is developed. To do this, the project manager must try to manage everything about the project, including scope, cost, quality, personnel, communication, risk, procurement, and more. Some of these responsibilities really belong to others. Scope control, for example, rightfully belongs with the customer. No one else is in the position to make the necessary trade-off decisions that will arise during product development, as priorities, team velocity, and market conditions shift. Prioritization is not a static, one-time, all-at-the-start activity that can be managed by a project manager.Yet time and again, sequential projects demand that project managers make educated guesses to deliver the right product.
On Scrum projects we acknowledge the untenable role of the project manager and eliminate it. Eliminating the role, though, does not mean we can do away with the work and responsibilities. As you might guess, since self-organizing teams are a core tenet of Scrum, a great deal of the responsibility previously shouldered by the project manager is transferred to the Scrum team. For example, without a project manager to assign tasks to individuals, team members assume the responsibility of selecting tasks themselves. Other responsibilities shift to the ScrumMaster or product owner.
Former project managers often assume one of the roles that have taken on some part of their past responsibilities—the project manager becomes either a ScrumMaster, product owner, or team member, depending on experience, skills, knowledge, and interests.
Some people became project managers because they considered it the next step in a desirable career path, yet they don't enjoy project management. These individuals miss the technical challenge of working as a programmer, tester, database engineer, designer, analyst, architect, or so on. Many of these individuals will take advantage of the elimination of the project manager role to return to work they found more satisfying.
Other project managers have used their roles to become knowledgeable about the business and its customers. A project manager in this situation will leverage that knowledge into a role as a product owner. This can be an excellent fit, especially for the project manager who is having a hard time completely relinquishing the ability to tell the team what to do. As part of their role, product owners are allowed to tell the team a bit of the "what to do" as long as they stay largely away from telling them how to do it. This can satisfy a former project manager whose nature makes it hard to stop occasionally directing the team. If a project manager can overcome the old habits of directing the team and making decisions for it, it is likely such a project manager can become a good ScrumMaster. This is the most common new role for project managers in organizations adopting Scrum. The new role will likely be difficult at first for the former project manager as she learns to bite her tongue and let the team learn how to work through its own issues and make decisions. Often, new ScrumMasters are put in the challenging position of coaching teams at something that they are not yet good at themselves—being agile. The best strategies for a ScrumMaster in this situation include the following:
• Stick as close as possible to doing Scrum by the book. Initially follow the advice of this or another Scrum book closely. Or engage an on-site trainer or coach and follow her advice to the letter. Only begin customizing the process after you have real, hands-on experience with it.
• Talk to other ScrumMasters as much as possible. If there are multiple ScrumMasters in your organization, form a community of practice with 7 5 . SEE ALSO the other ScrumMasters and share good and bad experiences. Look to . . Communities of learn by extracting lessons from commonalities among these experiences.
• Learn as much as you can as quickly as you can. Read books, articles, blogs, and websites. Look into local agile interest groups and attend their meetings. Try to attend one or more of the major agile or Scrum conferences.
Doris Ford, a software engineering manager with Motorola, was a classically trained project manager and a Project Management Professional (PMP). However, despite having a traditional background in project management, Doris's approach has always been about supporting and enabling her teams. Because of that, she was able to easily move from project manager to ScrumMaster. She writes of how her job has changed with Scrum.
Over the years in managing agile development I have learned not to sweat the task details. As a traditional project manager, I always needed to stay on top of who was doing which tasks, what were their dependencies, and would they be done on time. I spent countless number of hours just asking these questions to get the answers in attempt to meet the scope/schedule/budget/quality constraints and reporting upwards on the progress (sometimes using earned value). In an agile environment I had to learn to trust the team members that they would identify and do the tasks necessary to complete the scope for each sprint. It was hard letting go at first, but I quickly learned that the team could do this. I now spend the majority of my time supporting the team members by addressing impediments that they raise and keeping external noise from diverting their focus.
Why the Title Change?
If it's possible for a project manager to become a team's ScrumMaster or product owner, why do we need to change the person's title? Let's consider the term ScrumMaster. Years ago, when I first started running Scrum projects, the term ScrumMaster didn't exist, and it never dawned on me to call the role anything but project manager. This worked well enough. But, I was hiring new individuals into these roles; I was clear with these new hires about my expectations for how they'd interact with the team. I avoided domineering, command-and-control-style individuals. Also, these new project managers reported to me, which allowed me a lot of influence over how they interacted with their teams. Calling them project managers worked fine.
As our company continued to succeed and grow, we began to acquire other companies. In those companies I would inherit project managers who sometimes did have very traditional mindsets about the role of the project manager. I was confronted with helping them shift that mindset to one more compatible with agile development. I found this much harder than just hiring project managers with a collaborative approach suitable to self-organizing teams.
Years later in a discussion with Ken Schwaber, he helped me understand why transitioning existing project managers had been more difficult than I had anticipated. Schwaber informed me that by allowing the project managers to retain their titles, I was allowing them to think that the changes were less allencompassing than they were. He invented the word ScrumMaster in 1997 in part because it would remind everyone that this was not just the project manager role with a few additional responsibilities removed or added. Schwaber told me that "the vocabulary of Scrum is a vocabulary of change. The words are often intentionally ugly—burndown, backlog, ScrumMaster—because they remind us that change is occurring."
Although I recommend it, you do not necessarily need to banish the title project manager. If you or your organization is enamored of it, continue to use it. But be mindful of Ken Schwaber's advice and my experience that using the old words will slow or prevent the adoption of the new approach. Retaining an old title discourages thinking in the new way. Further, if people are unwilling to relinquish something as insignificant as a j ob title, they will probably also be unwilling to make the far harder changes necessary to adopt Scrum.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
On Scrum projects we acknowledge the untenable role of the project manager and eliminate it. Eliminating the role, though, does not mean we can do away with the work and responsibilities. As you might guess, since self-organizing teams are a core tenet of Scrum, a great deal of the responsibility previously shouldered by the project manager is transferred to the Scrum team. For example, without a project manager to assign tasks to individuals, team members assume the responsibility of selecting tasks themselves. Other responsibilities shift to the ScrumMaster or product owner.
Former project managers often assume one of the roles that have taken on some part of their past responsibilities—the project manager becomes either a ScrumMaster, product owner, or team member, depending on experience, skills, knowledge, and interests.
Some people became project managers because they considered it the next step in a desirable career path, yet they don't enjoy project management. These individuals miss the technical challenge of working as a programmer, tester, database engineer, designer, analyst, architect, or so on. Many of these individuals will take advantage of the elimination of the project manager role to return to work they found more satisfying.
Other project managers have used their roles to become knowledgeable about the business and its customers. A project manager in this situation will leverage that knowledge into a role as a product owner. This can be an excellent fit, especially for the project manager who is having a hard time completely relinquishing the ability to tell the team what to do. As part of their role, product owners are allowed to tell the team a bit of the "what to do" as long as they stay largely away from telling them how to do it. This can satisfy a former project manager whose nature makes it hard to stop occasionally directing the team. If a project manager can overcome the old habits of directing the team and making decisions for it, it is likely such a project manager can become a good ScrumMaster. This is the most common new role for project managers in organizations adopting Scrum. The new role will likely be difficult at first for the former project manager as she learns to bite her tongue and let the team learn how to work through its own issues and make decisions. Often, new ScrumMasters are put in the challenging position of coaching teams at something that they are not yet good at themselves—being agile. The best strategies for a ScrumMaster in this situation include the following:
• Stick as close as possible to doing Scrum by the book. Initially follow the advice of this or another Scrum book closely. Or engage an on-site trainer or coach and follow her advice to the letter. Only begin customizing the process after you have real, hands-on experience with it.
• Talk to other ScrumMasters as much as possible. If there are multiple ScrumMasters in your organization, form a community of practice with 7 5 . SEE ALSO the other ScrumMasters and share good and bad experiences. Look to . . Communities of learn by extracting lessons from commonalities among these experiences.
• Learn as much as you can as quickly as you can. Read books, articles, blogs, and websites. Look into local agile interest groups and attend their meetings. Try to attend one or more of the major agile or Scrum conferences.
Doris Ford, a software engineering manager with Motorola, was a classically trained project manager and a Project Management Professional (PMP). However, despite having a traditional background in project management, Doris's approach has always been about supporting and enabling her teams. Because of that, she was able to easily move from project manager to ScrumMaster. She writes of how her job has changed with Scrum.
Over the years in managing agile development I have learned not to sweat the task details. As a traditional project manager, I always needed to stay on top of who was doing which tasks, what were their dependencies, and would they be done on time. I spent countless number of hours just asking these questions to get the answers in attempt to meet the scope/schedule/budget/quality constraints and reporting upwards on the progress (sometimes using earned value). In an agile environment I had to learn to trust the team members that they would identify and do the tasks necessary to complete the scope for each sprint. It was hard letting go at first, but I quickly learned that the team could do this. I now spend the majority of my time supporting the team members by addressing impediments that they raise and keeping external noise from diverting their focus.
Why the Title Change?
If it's possible for a project manager to become a team's ScrumMaster or product owner, why do we need to change the person's title? Let's consider the term ScrumMaster. Years ago, when I first started running Scrum projects, the term ScrumMaster didn't exist, and it never dawned on me to call the role anything but project manager. This worked well enough. But, I was hiring new individuals into these roles; I was clear with these new hires about my expectations for how they'd interact with the team. I avoided domineering, command-and-control-style individuals. Also, these new project managers reported to me, which allowed me a lot of influence over how they interacted with their teams. Calling them project managers worked fine.
As our company continued to succeed and grow, we began to acquire other companies. In those companies I would inherit project managers who sometimes did have very traditional mindsets about the role of the project manager. I was confronted with helping them shift that mindset to one more compatible with agile development. I found this much harder than just hiring project managers with a collaborative approach suitable to self-organizing teams.
Years later in a discussion with Ken Schwaber, he helped me understand why transitioning existing project managers had been more difficult than I had anticipated. Schwaber informed me that by allowing the project managers to retain their titles, I was allowing them to think that the changes were less allencompassing than they were. He invented the word ScrumMaster in 1997 in part because it would remind everyone that this was not just the project manager role with a few additional responsibilities removed or added. Schwaber told me that "the vocabulary of Scrum is a vocabulary of change. The words are often intentionally ugly—burndown, backlog, ScrumMaster—because they remind us that change is occurring."
Although I recommend it, you do not necessarily need to banish the title project manager. If you or your organization is enamored of it, continue to use it. But be mindful of Ken Schwaber's advice and my experience that using the old words will slow or prevent the adoption of the new approach. Retaining an old title discourages thinking in the new way. Further, if people are unwilling to relinquish something as insignificant as a j ob title, they will probably also be unwilling to make the far harder changes necessary to adopt Scrum.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
|
|
0 comments
Post a Comment