Making the time crunch even more vexing: Scrum has no
defined role for the project manager. So while business
partners struggled to carve out enough time, project
managers found themselves with too much of it.
disbanded and Scrum became the
new mandated approach.
The speed at which our organization transitioned to agile was impressive. In our exuberance, however, we
failed to ready all stakeholders for the
new standard.
Problem: A Wrinkle
in Time
After the first few projects in which
we used Scrum, we learned that to be
successful, the new approach required
a product owner to spend at least half
of his or her work week focused on
the project.
Because the role is designed to
ensure the project delivers on business
value, it seemed to make the most sense
for our business partners to become product owners.
What we didn’t immediately realize is that this time requirement far exceeded the few hours per week business partners had
historically budgeted for status meetings. They were now tasked with
attending daily meetings and prepping for grooming sessions with a
backlog of tasks and feature requirements known as user stories.
No surprise, the business partners were unable to devote the
necessary time alongside their existing commitments.
Making the time crunch even more vexing: Scrum has no
defined role for the project manager. So while business partners
struggled to carve out enough time, project managers found
themselves with too much of it.
Solution: Redefine and Reassign
Most project managers paired with business partners as product owners to help them manage their new Scrum-related
responsibilities.
Project managers now maintain the backlog populated with
user stories, and our business partners check in with them
weekly—a big time saver.
The match was ideal, considering that the project managers and business partners had worked together for years and
already had an established line of trust and cooperation. And
because our project managers had development backgrounds
and a working knowledge of business needs, they could encourage the selection of technical implementations that both solved
business problems and limited development time.
Problem: Individual Interpretations
To help everyone understand the transition and their new roles
and tasks, all of the developers received the Manifesto for Agile
Software Development. But differing interpretations of this
document created problems.
For example, the manifesto recommends we choose “
working software over comprehensive documentation.” Reading
this, some team members concluded that documentation was
no longer required.
The word “over” is at the root of the confusion here:
The manifesto uses the word to represent the relationship
between different activities. “A over B” does not mean we do
not do B, only that we scrutinize the value of doing B before
embarking on it.
Solution: Community Art
To bring teams to a common understanding of agile, we pasted
the manifesto on the wall next to the cubicles of IT development team members. We also called a department-wide meeting and talked through each line of the manifesto as a group.
We return to the visual manifesto whenever a process
needs clarification or a mistake is commonly occurring, and
this continuous reinforcement helps mature our project
management practices. PM
Toby Lang, PMI-ACP, PMP, is a project manager and
business relations analyst at grocery retailer Overwaitea
Food Group in Surrey, British Columbia, Canada.
