Chapter 16 An Introduction to Agile Project Management 599
Case 16.1
Ea
Introducing Scrum at P2P
PART A
Kendra Hua had worked for six years as a software engineer in the IT department at
Point 2 Point (P2P), a large freight moving company. She liked her job and the people
she worked with. While she did some maintenance work, she worked primarily on
projects, usually full time. Her work covered a wide range of projects including system
upgrades, inventory control, GPS tracking, billing, and customer databases. These
projects were typically able to meet project requirements but were consistently late.
Within the IT department it was common practice for a betting pool to emerge regard-
ing completion dates. The rule of thumb was to take the original schedule and multiply
it by 1.5 and start guessing from then on.
Management decided to try to turn things around by changing the way P2P
completed IT projects. Instead of the traditional waterfall approach in which all the
requirements were defined upfront, the IT department was to start using Agile project
management, and more specifically Scrum, to complete their projects.
Kendra had just been assigned to the Big Foot project, which involved develop-
ing a system for monitoring P2P's carbon footprint. To prepare for this project,
Kendra and her entire team of software engineers would attend a two-day Scrum
workshop.
Everyone was given a book on Scrum to prepare themselves for the workshop. At
first Kendra was overwhelmed by terminology-Scrum master, sprints, product man-
ager, sprint logs, and so forth. She questioned the rugby metaphor, since the only thing
she knew about the sport was that one of her ex-boyfriends in college would come back
to the dorm inebriated and bloodied after a match. And why was the project manager
called a master? It seemed demeaning to her. Still, she had heard some good things
about Scrum from a friend who was using it in another company. He claimed it gave
programmers more freedom to do their work and work at a faster pace. So she
approached the two-day workshop with an open mind.
The workshop was facilitated by a trainer who was well versed in the world of soft-
ware development. Participants included her other five team members as well as Prem
Gupta, a veteran project manager who would now assume the role of Scrum master, and
Isaac Smith, who would act as the product manager representing the interests of the
customers. At first everyone gave Prem a hard time, by bowing to him, pleading “mas-
ter, master, master ...” The facilitator quickly corrected them by saying he was not their
master but rather master of the Scrum process. The facilitator went on to emphasize that
they would work as a self-organizing team. Kendra wasn't exactly sure what that meant,
but she felt it had something to do with the team managing itself, not Prem.
The workshop covered all the basic Scrum tools, concepts, and roles. Everyone got
to practice the process by completing a simulated project involving the creation of a
new board game. Kendra liked the idea of the standing Scrum meeting, since most of
her meetings at P2P took way too long. She also liked having the product manager,
who was the ultimate decider on features and when work was completed. Everyone
laughed at the “only one neck to wring” analogy that the facilitator used to describe
this role. Overall she thought the process had promise and she was excited about trying
it out on the Big Foot project. The Big Foot project was estimated to be completed after
five sprints with each sprint lasting four weeks.
600 Chapter 16 An Introduction to Agile Project Management
THE FIRST SPRINT
The first sprint planning meeting went pretty much by the book. Isaac had done his
homework and came to the meeting with a comprehensive list of features the software
needed to provide. There was healthy discussion, and Isaac amended the list to include
some features that the team felt was necessary. The afternoon session featured Isaac,
the product owner, prioritizing the features in the product backlog with feedback from
the team. The final segment was devoted to the team deciding among themselves
which high priority features they would commit to build within the four-week sprint.
Prem did a good job of reminding the team that they were expected to build a fully
functional feature. This tempered the team's enthusiasm, and in the end a challenging
but doable set of features was assigned to the sprint backlog for the first sprint.
The first couple of daily Scrum meetings were a bit awkward as members were care-
ful not to step on each other's toes. One of the first impediments identified was not
having a shared understanding of how a self-organizing team worked. Prem kept
emphasizing that it was up to the team to decide who does what and when. Then one
morning it just suddenly clicked and members came forward claiming work they felt
needed to be done. After that the daily scrums took on a life of their own, interrupted
only when a member had to do five push-ups for every minute late. The pace of work
picked up, and there was a shared enthusiasm as tasks and ultimately functional fea-
tures were completed in rapid fashion. Kendra worked side by side with the other
software engineers to solve problems and share what they had learned. Occasionally
Isaac would be called into the project room to answer questions about specific features
and be shown work in progress.
By the time of the first sprint review meeting, the team was able to demonstrate all
but one of the designated features to Isaac and even three more that were not on the
initial hit list. The team got some useful feedback not only from Isaac but also from a
couple of the end users he brought with him. Eighty percent of the features were pro-
claimed done by Isaac while the others needed only slight modifications. Everyone
agreed that the next Sprint review would even be more successful.
The sprint retrospective meeting was refreshing as members spoke candidly about
both the good and the bad. Everyone agreed that the team needed to do a better job at
documentation. Issues regarding fairness and spreading both the fun work and the
tough work among the entire team were brought to the surface. Kendra was impressed
by how everyone focused on what was best for the project not just themselves.
THE SECOND SPRINT
The second sprint meeting went well. The features that needed rework after the first
sprint review meeting were at the top of the backlog and Isaac made appropriate
adjustments in priorities, and a couple of new features that were discovered during the
sprint review meeting were added. The meeting convened with the team confident that
they would be able to complete the work they had committed to.
Project work progressed quickly over the next week. Kendra felt pressure to accom-
plish what she said she would at the daily Scrum. At the same time, she felt a tremen-
dous amount of satisfaction reporting work done. The entire team seemed energized.
Then one day everything came to a standstill over a sticky integration problem. The
team struggled over the next three days trying to solve the problem until, at the next
Scrum, Prem stepped forward saying, "I think you should do this
ceeded to outline a specific method for solving the problem, even assigning specific
" He then pro-
Chapter 16 An Introduction to Agile Project Management 601
tasks to each team member. During the next two days Prem went back and forth
between team members coordinating their work and solving problems. While there
was some grumbling within the team, his solution worked, and Kendra was grateful to
get back on track.
From then on Prem took a more active role in daily Scrum meetings, often having
the final say as to the work agenda for that day. The meetings took on a different tone
as members waited for Prem to speak first. Isaac was absent from the project room
during this time as he was visiting sites that would be using the new software. Still,
features were being completed and Kendra was happy with the progress. Then one day
Isaac showed up at the morning Scrum meeting. He had just gotten back and had fresh
information he wanted to introduce into the project. He had rewritten the product log
and added several new, high priority features and eliminated a few of the features that
the team had been working on. He wanted the team to shift their efforts and complete
the new features by the end of the sprint.
The team was shocked because one of the principles they had been taught is that you
don't change course midway through a sprint. Prem did his best to explain this to Isaac,
but he was insistent. He kept saying that these changes had to be made, otherwise much
of the sprint output would be a waste of time. He kept repeating that the team needed
to be flexible. “After all, isn't that what the Agile approach is all about?” The meeting
came to an impasse until Prem came forward with a compromise. The team would
agree to do the new work, but the sprint needed to be extended by two weeks. Everyone
agreed and Kendra went back to work.
Up till the end of the second sprint, Prem continued to direct project work. When it
came for the sprint review meeting four of the five new features were completed as
well as most of the original features. However, the feature demonstrations did not go
well. Isaac and several of the end users that were present were critical of the user
friendliness of several of the completed features. Kendra and other team members
defended their work by saying, “Why didn't you tell us you wanted it to perform that
way?” Prem did his best to keep the meeting under control, but the team had little to
say when an important feature simply did not work. In the end, only half of the features
were accepted as being done.
Kendra walked out of the sprint review discouraged. Tomorrow morning was the
sprint retrospective meeting. She had a lot on her mind, but wasn't sure what she
should say or how to say it at the meeting.
1. How well is Scrum working?
2. What are the issues confronting the Big Foot project?
3. Assume you are Kendra. What would you want to say at the retrospective? How
would you say it?
4. What improvements or changes need to be made?
PART B
Prem opened the retrospective by saying he had gotten a call from his boss and she was
not happy with the progress. Prem said that he and the team were under the gun to get
back on track. The list of things that went well during the second sprint was short and
when it came time to discuss improvements there was an awkward silence. Kendra
spoke up and began by saying she had gone back and reviewed the Scrum book. She
went on to say that she thought the whole idea behind Scrum was that the team was to
work to solve their own problems and it wasn't Prem's role to play task master. A
602 Chapter 16 An Introduction to Agile Project Management
couple of other team members murmured agreement. Prem became defensive and said
if he had not intervened it would have taken days for the team to solve the problem.
Another member said he thought it was a mistake allowing Isaac to change the
sprint commitments. Prem agreed that in principle that was true, but said sometimes
have to bend the rules to do what is right. He admonished the team by saying that
you
they had to practice being more agile. The retrospective ended with few specific rec-
ommendations other than that in order to get back on track, Prem felt he would have to
get even more involved in the execution of the project.
The subsequent sprint 3 planning meeting was more of a formality. Isaac updated
the product backlog with revised priorities and Prem signed off for the team as to what
they would commit to. There was little interaction between the team and Isaac except
seeking clarification on performance requirements for specific features.
The team met under Prem's leadership for their daily Scrums. Sometimes the
Scrums went beyond the normal 15 minutes as Prem reviewed progress and described
in detail what needed to be done that day. Isaac would occasionally show up, change
priorities, review work and answer questions. Kendra worked hard on her assignments
and often received praise from Prem for work well done.
One evening when the team got together for a few beers and sushi, one of the team
members pulled out a spreadsheet and asked who wanted to make the first bet on when
they thought the project would be done.
After several sprints, Isaac finally signed off on the last feature and declared the
project completed. A collective “yahoo” sprang from the team. After the meeting
Kendra went around collecting money from each of her teammates—she had predicted
that the project would take 12 weeks longer than planned.
1. How would you assess P2P's effort at introducing Scrum?
Scrum?
2. What challenges does an organization face when adopting an Agile approach like
3. What could P2P have done to enhance success?
Chapter 16 An Introduction to Agile Project Management 599
Case 16.1
Ea
Introducing Scrum at P2P
PART A
Kendra Hua had worked for six years as a software engineer in the IT department at
Point 2 Point (P2P), a large freight moving company. She liked her job and the people
she worked with. While she did some maintenance work, she worked primarily on
projects, usually full time. Her work covered a wide range of projects including system
upgrades, inventory control, GPS tracking, billing, and customer databases. These
projects were typically able to meet project requirements but were consistently late.
Within the IT department it was common practice for a betting pool to emerge regard-
ing completion dates. The rule of thumb was to take the original schedule and multiply
it by 1.5 and start guessing from then on.
Management decided to try to turn things around by changing the way P2P
completed IT projects. Instead of the traditional waterfall approach in which all the
requirements were defined upfront, the IT department was to start using Agile project
management, and more specifically Scrum, to complete their projects.
Kendra had just been assigned to the Big Foot project, which involved develop-
ing a system for monitoring P2P's carbon footprint. To prepare for this project,
Kendra and her entire team of software engineers would attend a two-day Scrum
workshop.
Everyone was given a book on Scrum to prepare themselves for the workshop. At
first Kendra was overwhelmed by terminology-Scrum master, sprints, product man-
ager, sprint logs, and so forth. She questioned the rugby metaphor, since the only thing
she knew about the sport was that one of her ex-boyfriends in college would come back
to the dorm inebriated and bloodied after a match. And why was the project manager
called a master? It seemed demeaning to her. Still, she had heard some good things
about Scrum from a friend who was using it in another company. He claimed it gave
programmers more freedom to do their work and work at a faster pace. So she
approached the two-day workshop with an open mind.
The workshop was facilitated by a trainer who was well versed in the world of soft-
ware development. Participants included her other five team members as well as Prem
Gupta, a veteran project manager who would now assume the role of Scrum master, and
Isaac Smith, who would act as the product manager representing the interests of the
customers. At first everyone gave Prem a hard time, by bowing to him, pleading “mas-
ter, master, master ...” The facilitator quickly corrected them by saying he was not their
master but rather master of the Scrum process. The facilitator went on to emphasize that
they would work as a self-organizing team. Kendra wasn't exactly sure what that meant,
but she felt it had something to do with the team managing itself, not Prem.
The workshop covered all the basic Scrum tools, concepts, and roles. Everyone got
to practice the process by completing a simulated project involving the creation of a
new board game. Kendra liked the idea of the standing Scrum meeting, since most of
her meetings at P2P took way too long. She also liked having the product manager,
who was the ultimate decider on features and when work was completed. Everyone
laughed at the “only one neck to wring” analogy that the facilitator used to describe
this role. Overall she thought the process had promise and she was excited about trying
it out on the Big Foot project. The Big Foot project was estimated to be completed after
five sprints with each sprint lasting four weeks.
600 Chapter 16 An Introduction to Agile Project Management
THE FIRST SPRINT
The first sprint planning meeting went pretty much by the book. Isaac had done his
homework and came to the meeting with a comprehensive list of features the software
needed to provide. There was healthy discussion, and Isaac amended the list to include
some features that the team felt was necessary. The afternoon session featured Isaac,
the product owner, prioritizing the features in the product backlog with feedback from
the team. The final segment was devoted to the team deciding among themselves
which high priority features they would commit to build within the four-week sprint.
Prem did a good job of reminding the team that they were expected to build a fully
functional feature. This tempered the team's enthusiasm, and in the end a challenging
but doable set of features was assigned to the sprint backlog for the first sprint.
The first couple of daily Scrum meetings were a bit awkward as members were care-
ful not to step on each other's toes. One of the first impediments identified was not
having a shared understanding of how a self-organizing team worked. Prem kept
emphasizing that it was up to the team to decide who does what and when. Then one
morning it just suddenly clicked and members came forward claiming work they felt
needed to be done. After that the daily scrums took on a life of their own, interrupted
only when a member had to do five push-ups for every minute late. The pace of work
picked up, and there was a shared enthusiasm as tasks and ultimately functional fea-
tures were completed in rapid fashion. Kendra worked side by side with the other
software engineers to solve problems and share what they had learned. Occasionally
Isaac would be called into the project room to answer questions about specific features
and be shown work in progress.
By the time of the first sprint review meeting, the team was able to demonstrate all
but one of the designated features to Isaac and even three more that were not on the
initial hit list. The team got some useful feedback not only from Isaac but also from a
couple of the end users he brought with him. Eighty percent of the features were pro-
claimed done by Isaac while the others needed only slight modifications. Everyone
agreed that the next Sprint review would even be more successful.
The sprint retrospective meeting was refreshing as members spoke candidly about
both the good and the bad. Everyone agreed that the team needed to do a better job at
documentation. Issues regarding fairness and spreading both the fun work and the
tough work among the entire team were brought to the surface. Kendra was impressed
by how everyone focused on what was best for the project not just themselves.
THE SECOND SPRINT
The second sprint meeting went well. The features that needed rework after the first
sprint review meeting were at the top of the backlog and Isaac made appropriate
adjustments in priorities, and a couple of new features that were discovered during the
sprint review meeting were added. The meeting convened with the team confident that
they would be able to complete the work they had committed to.
Project work progressed quickly over the next week. Kendra felt pressure to accom-
plish what she said she would at the daily Scrum. At the same time, she felt a tremen-
dous amount of satisfaction reporting work done. The entire team seemed energized.
Then one day everything came to a standstill over a sticky integration problem. The
team struggled over the next three days trying to solve the problem until, at the next
Scrum, Prem stepped forward saying, "I think you should do this
ceeded to outline a specific method for solving the problem, even assigning specific
" He then pro-
Chapter 16 An Introduction to Agile Project Management 601
tasks to each team member. During the next two days Prem went back and forth
between team members coordinating their work and solving problems. While there
was some grumbling within the team, his solution worked, and Kendra was grateful to
get back on track.
From then on Prem took a more active role in daily Scrum meetings, often having
the final say as to the work agenda for that day. The meetings took on a different tone
as members waited for Prem to speak first. Isaac was absent from the project room
during this time as he was visiting sites that would be using the new software. Still,
features were being completed and Kendra was happy with the progress. Then one day
Isaac showed up at the morning Scrum meeting. He had just gotten back and had fresh
information he wanted to introduce into the project. He had rewritten the product log
and added several new, high priority features and eliminated a few of the features that
the team had been working on. He wanted the team to shift their efforts and complete
the new features by the end of the sprint.
The team was shocked because one of the principles they had been taught is that you
don't change course midway through a sprint. Prem did his best to explain this to Isaac,
but he was insistent. He kept saying that these changes had to be made, otherwise much
of the sprint output would be a waste of time. He kept repeating that the team needed
to be flexible. “After all, isn't that what the Agile approach is all about?” The meeting
came to an impasse until Prem came forward with a compromise. The team would
agree to do the new work, but the sprint needed to be extended by two weeks. Everyone
agreed and Kendra went back to work.
Up till the end of the second sprint, Prem continued to direct project work. When it
came for the sprint review meeting four of the five new features were completed as
well as most of the original features. However, the feature demonstrations did not go
well. Isaac and several of the end users that were present were critical of the user
friendliness of several of the completed features. Kendra and other team members
defended their work by saying, “Why didn't you tell us you wanted it to perform that
way?” Prem did his best to keep the meeting under control, but the team had little to
say when an important feature simply did not work. In the end, only half of the features
were accepted as being done.
Kendra walked out of the sprint review discouraged. Tomorrow morning was the
sprint retrospective meeting. She had a lot on her mind, but wasn't sure what she
should say or how to say it at the meeting.
1. How well is Scrum working?
2. What are the issues confronting the Big Foot project?
3. Assume you are Kendra. What would you want to say at the retrospective? How
would you say it?
4. What improvements or changes need to be made?
PART B
Prem opened the retrospective by saying he had gotten a call from his boss and she was
not happy with the progress. Prem said that he and the team were under the gun to get
back on track. The list of things that went well during the second sprint was short and
when it came time to discuss improvements there was an awkward silence. Kendra
spoke up and began by saying she had gone back and reviewed the Scrum book. She
went on to say that she thought the whole idea behind Scrum was that the team was to
work to solve their own problems and it wasn't Prem's role to play task master. A
602 Chapter 16 An Introduction to Agile Project Management
couple of other team members murmured agreement. Prem became defensive and said
if he had not intervened it would have taken days for the team to solve the problem.
Another member said he thought it was a mistake allowing Isaac to change the
sprint commitments. Prem agreed that in principle that was true, but said sometimes
have to bend the rules to do what is right. He admonished the team by saying that
you
they had to practice being more agile. The retrospective ended with few specific rec-
ommendations other than that in order to get back on track, Prem felt he would have to
get even more involved in the execution of the project.
The subsequent sprint 3 planning meeting was more of a formality. Isaac updated
the product backlog with revised priorities and Prem signed off for the team as to what
they would commit to. There was little interaction between the team and Isaac except
seeking clarification on performance requirements for specific features.
The team met under Prem's leadership for their daily Scrums. Sometimes the
Scrums went beyond the normal 15 minutes as Prem reviewed progress and described
in detail what needed to be done that day. Isaac would occasionally show up, change
priorities, review work and answer questions. Kendra worked hard on her assignments
and often received praise from Prem for work well done.
One evening when the team got together for a few beers and sushi, one of the team
members pulled out a spreadsheet and asked who wanted to make the first bet on when
they thought the project would be done.
After several sprints, Isaac finally signed off on the last feature and declared the
project completed. A collective “yahoo” sprang from the team. After the meeting
Kendra went around collecting money from each of her teammates—she had predicted
that the project would take 12 weeks longer than planned.
1. How would you assess P2P's effort at introducing Scrum?
Scrum?
2. What challenges does an organization face when adopting an Agile approach like
3. What could P2P have done to enhance success?
Chapter 1 Modern Project Management 17
Understand that manag-
1.4 Project Management Today: A Socio-Technical Approach
Senior management is often involved in selecting projects but seldom involved in
LO 1-5
implementing them. Implementing the project is the challenge.
Managing a project is a multidimensional process (see Figure 1.3, A Socio-Technical
ing projects involves bal-
Approach to Project Management). The first dimension is the technical side of the
ancing the technical and
management process, which consists of the formal, disciplined, purely logical parts of
sociocultural dimensions
the
process. This technical dimension includes planning, scheduling, and controlling
of the project.
projects. Clear project scope statements are written to link the project and customer
and to facilitate planning and control. Creation of the deliverables and work break-
down structures facilitates planning and monitoring the progress of the project. The
work breakdown structure serves as a database that links all levels in the organization,
major deliverables, and all work-right down to the tasks in a work package. Effects
of project changes are documented and traceable. Thus, any change in one part of the
project is traceable to the source by the integrated linkages of the system. This inte-
grated information approach can provide all project managers and the customer with
decision information appropriate to their level and needs. A successful project man-
ager will be well trained in the technical side of managing projects.
The second and opposing dimension is the sociocultural side of project manage-
ment. In contrast to the orderly world of project planning, this dimension involves the
much messier, often contradictory and paradoxical world of implementation. It centers
on creating a temporary social system within a larger organizational environment that
combines the talents of a divergent set of professionals working to complete the proj-
ect. Project managers must shape a project culture that stimulates teamwork and high
levels of personal motivation as well as a capacity to quickly identify and resolve prob-
lems that threaten project work. Things rarely go as planned and project managers
must be able to steer the project back on track or alter directions when necessary.
The sociocultural dimension also involves managing the interface between the proj-
ect and external environment. Project managers have to assuage and shape
FIGURE 1.3
A Socio-Technical
Approach to Project
Management
Sociocultural
Leadership
Problem solving
Teamwork
Negotiation
Politics
Customer expectations
Technical
Scope
WBS
Schedules
Resource allocation
Baseline budgets
Status reports
Chapter 1 Modern Project Management 17
Understand that manag-
1.4 Project Management Today: A Socio-Technical Approach
Senior management is often involved in selecting projects but seldom involved in
LO 1-5
implementing them. Implementing the project is the challenge.
Managing a project is a multidimensional process (see Figure 1.3, A Socio-Technical
ing projects involves bal-
Approach to Project Management). The first dimension is the technical side of the
ancing the technical and
management process, which consists of the formal, disciplined, purely logical parts of
sociocultural dimensions
the
process. This technical dimension includes planning, scheduling, and controlling
of the project.
projects. Clear project scope statements are written to link the project and customer
and to facilitate planning and control. Creation of the deliverables and work break-
down structures facilitates planning and monitoring the progress of the project. The
work breakdown structure serves as a database that links all levels in the organization,
major deliverables, and all work-right down to the tasks in a work package. Effects
of project changes are documented and traceable. Thus, any change in one part of the
project is traceable to the source by the integrated linkages of the system. This inte-
grated information approach can provide all project managers and the customer with
decision information appropriate to their level and needs. A successful project man-
ager will be well trained in the technical side of managing projects.
The second and opposing dimension is the sociocultural side of project manage-
ment. In contrast to the orderly world of project planning, this dimension involves the
much messier, often contradictory and paradoxical world of implementation. It centers
on creating a temporary social system within a larger organizational environment that
combines the talents of a divergent set of professionals working to complete the proj-
ect. Project managers must shape a project culture that stimulates teamwork and high
levels of personal motivation as well as a capacity to quickly identify and resolve prob-
lems that threaten project work. Things rarely go as planned and project managers
must be able to steer the project back on track or alter directions when necessary.
The sociocultural dimension also involves managing the interface between the proj-
ect and external environment. Project managers have to assuage and shape
FIGURE 1.3
A Socio-Technical
Approach to Project
Management
Sociocultural
Leadership
Problem solving
Teamwork
Negotiation
Politics
Customer expectations
Technical
Scope
WBS
Schedules
Resource allocation
Baseline budgets
Status reports
Purchase answer to see full
attachment