Whitepaper

Agile Project Management:

What’s the story?
There is no doubt that Agile project management, the This white paper will explore Agile from all three
adaptive methodology that spread like wildfire around the perspectives, and will offer guidelines for effective Agile
turn of the millennium, is here to stay. project management. It will expose common myths, offer
tips on the cultural shift to Agile, and address concerns
As organizations make the shift to Agile methods, about mixed environments where some departments use
there remains confusion, skepticism, and rampant Agile and others do not. Finally, it will show how Agile is
misconceptions about Agile. And like any methodology, implemented in Planview Enterprise® – with and without
Agile requires organizations to look at the triple adjacent tools such as Atlassian’s CA Agile Central, Version
foundation of people, process, and technology. To One, and IBM Rational® Team Concert (RTC).
underplay any of those is to sabotage success.
Topics we’ll address are: • How is Agile implemented in Planview Enterprise? What
if some departments don’t use Agile?
• What’s different about Agile? What are its benefits?
• If we plan to use Agile tools, how do we effectively use
• How does Agile work? What do all those terms mean? them with Planview Enterprise? Which tool is best for
what activities?
• What roles are required for effective Agile projects?
And specifically, how does the role of the project Whether you’re new to Agile or an Agile expert, in
manager change? addressing these common questions, this white paper will
position you for success and show you how to effectively
• How do we address typical management concerns and use Planview Enterprise for Agile project management.
skepticism about Agile? Are some of those concerns The Agile movement is undoubtedly expanding, and those
justified? who understand its nuances – around people, process, and
technology – will be more effective.
• Can Agile work for Virtual Teams?

Introduction: What’s Different about Agile?

Traditional “Waterfall” style project management methods Agile focuses on people working closely together in
involve detailed up-front planning and design (often short iterations (generally two to four weeks), delivering
known as BDUF or Big Design Up Front). The features and some form of measurable value with each iteration and
scope are predetermined, and a schedule and associated inspecting and adapting as appropriate. And throughout
costs are estimated. This works fine for construction all this, the focus is on the product and the customer.
projects, where details must by nature be predefined.
Another difference about Agile is that instead of having
For knowledge work, however, such as software a fixed scope and then estimating the schedule and
development, research projects, most engineering cost, it involves working in fixed time and cost iterations,
projects, and other types of work that involve a level of and estimating what features can be delivered in those
uncertainty and high change rates, traditional methods fall iterations. In other words, it turns traditional project
short. In an environment where change is the norm and management on its head (see figure below).
value can be improved based on information from new or
unexpected sources, there is a more efficient and realistic Fixed
way to manage. This is where Agile comes in.
Features Cost Schedule

Although Agile-like methods were employed in Japan

Value-driven
as early as 1986, it wasn’t until 2001 that a group of
thought leaders in software development formalized the
approach. This culminated in the Agile Manifesto, which Waterfall Agile
cited 12 principles based on four overarching values that
emphasized: Plan-driven

Cost Schedule Features

• Individuals and interactions over processes and tools
Estimated
• Working software over comprehensive documentation
Collectively, this collaborative and iterative approach
• Customer collaboration over contract negotiation results in:

• Responding to change over following a plan • Faster value delivered to the user . . . because of the
iterative process

2
• Reduced risk . . . because of iterative product delivery • Fewer errors. . . because of greater communication

• Reduced uncertainty . . . because of the product and • Clearer accountability… because of delineated roles
customer focus
With such benefits, it is not surprising that Agile has
• Better decision making . . . because of the collaborative enjoyed such rapid growth in knowledge worker
focus environments, extending beyond just software
development where the idea originated.
• Increased trust . . . because of incremental value being
delivered

How Does Agile Work?

Agile is a whole different way of thinking, so, not The team meets regularly to share information and
surprisingly, the terminology is different as well. Below is progress. In the Agile Scrum methodology, these are daily
a summary of how Agile works, along with the relevant 15-minute standup meetings. The key is to stay out of the
terminology: weeds. These are not problem-solving meetings.

Features are defined in stories, which identify the user(s), After each iteration/sprint, the team and stakeholders
action(s), and benefits for that feature. (As an analogy, meet to assess progress, make adjustments, and plan next
think of stories in fiction: they involve character, plot, and steps (i.e. evolutionary planning). This is often referred
motive) to as a retrospective. It differs from the traditional post-
implementation review, which is usually held long after the
User stories are estimated in relative points (though some project and far too late to make a difference on the current
organizations use ideal days). Story points are a measure project.
of relative complexity and effort. As work is completed, the
team can “earn” points for the completed stories. Progress is tracked via burndown charts, which track work
remaining over time (in terms of story points planned vs.
User stories are prioritized so that the highest value earned).
features or enabling features are delivered as soon as
possible. Velocity measures story points completed per iteration/
sprint (i.e. the speed at which value is being delivered).
The team works collaboratively on prioritized stories from
a backlog in fixed-time iterations, generally 1 to 4 weeks A release of a product is generally made up of multiple
in duration (in the Agile Scrum methodology, popular in iterations/sprints. Often, there is a planning sprint at the
software development, these iterations are called sprints). start of each release to plan out the stories for that release.

Agile Roles
With Agile projects, the role of the project manager must The devil is in the details (Agile projects succeed or fail
be reconsidered. This is because: based on mutual understanding of customer needs and
technical capabilities. Thus leaders of Agile projects need
Baselines are irrelevant (A baseline is meaningless if the to understand the details.)
whole concept of Agile is to plan and adapt the features to
fit within fixed time and cost iterations.) It’s all about the product (Unlike traditional projects,
where the focus is on managing the scope, schedule,
Formal up-front requirements don’t apply (Customer and budget, Agile projects are all about the product as
needs must be understood, but detailed requirements are opposed to the project. Items like schedule and budget
not all fixed up front; requirements evolve with learnings are fixed.)
from each sprint.)

3
Agile projects are community-driven (In Agile projects, are prioritized and understood; provides User Stories
developers, analysis, product owners, and customers are (users/actions/benefits)
in constant communication. If they’re not, then the Agile
methodology is not being followed. Unlike traditional • Customer – monitors progress and provides input for
projects, the project manager is not the primary source of valuable deliverables (Note: The Product Manager
communication.) typically serves as the proxy for the customer when it
comes to electronically recording comments and input)
Agile projects are relatively low risk (With a large, complex
project with lots of cross-team involvement and moving • Development Manager/SCRUM Master/Project
parts, Agile may not be the best approach. Agile is often Manager – populates sprints from the project backlog
used in software development and other knowledge- and updates story points based on planning sprints;
work projects that can bear some sort of tolerance for facilitates daily meetings and sprint demos
uncertainty and a single team can work at a rapid pace.)
• Developers – are assigned to stories and make testing
With all this in mind, some may ask the inevitable question: notes against stories; report effort for cost tracking
What, then, is there for a project manager to do? It’s a purposes
valid question, and organizations have taken different
approaches, from not having a project manager at all • Resource Managers – optimize resource utilization
to using the project manager as a facilitator across the across multiple projects and ensure resource availability
product owner, customers, and developers. In some on critical projects
organizations, the Scrum Master serves as the project
manager. • QA/QE Manager/Testers – focuses on quality
assurance/engineering, including process
Below are typical roles in an Agile project: improvements, testing, and measurement

• Product Manager/Owner – determines the product

vision and ensures that features listed in the backlog

Fear of Agile: Addressing the Concerns

Since the beginning of the Agile movement, defenders 7. We don’t want our customers to see our dirty laundry.
of traditional methods have been skeptical. Some of their
concerns are valid, while others are rooted in ignorance of 8. This “teamwork” approach doesn’t sound practical.
true Agile methods. Ten common management fears are:
9. Daily meetings? Our employees will feel like they’re
1. It won’t work for big, complex projects. under a microscope.

2. It’s too open-ended. We can’t predict costs. It’s 10. It’s too rigid and inhibits individual creativity.
“sanctioned scope creep.”
The truth is that Agile involves more planning than they
3. It sounds like “back of the napkin” design and realize – with each iteration in fact. And customer and
planning. business involvement is higher and communication is
elevated, so the focus isn’t strictly on technology. But other
4. It’s too “techie” focused. concerns are quite legitimate. Overall, the following ten
strategies can address typical concerns:
5. Software developers don’t talk the same language as
customers. 1. Make the strategy fit the situation (use the right
methodology for the right job; Agile is best for a
6. Customers don’t have time to get involved in planning. cohesive team working on knowledge work with a level
of uncertainty.)

4
2. Reduce risk by focusing on business symptoms over One additional way to reduce other shortcomings of Agile
solutions (don’t lose sight of the business problem is to take an integrated approach to emphasize that which
being solved.) is generally outside of the Agile methodology. To address
this, use a four-phased approach that can sit on top of your
3. Adopt a “see for yourself” policy to assess the user current methodology. The acronym spells UP-IT:
experience (before and after.)

4. Foster a systems-thinking approach (think beyond UP-IT Transform

the software; think also of processes, upstream and
Realization
downstream systems; stakeholder impact, and so on.)

5. Engage a business analyst to ensure that details aren’t Achievement

Iterate
overlooked (developers often lack an understanding of
business details.)
Prepare Ability

6. Bridge the culture gap between technicians and

customers (this can be done through training for Understand Knowledge
developers on customer interaction or by engaging
others to interpret and translate to bridge the gap
between developers and customers.) • Understand (build the knowledge necessary to be
successful on the project; do research; examine the
7. Embrace change, but manage it (assume features will current and desired user experience.)
change based on learnings, but have discussions about
overall scope, and manage and log changes to the • Prepare (gain the capabilities to execute the project
scope.) successfully, such as training, the right tools, gaining
stakeholder commitment, etc.)
8. Focus on product evolution, not project evolution;
manage by prioritized features and release; have • Iterate (plan and execute iterations/sprints to deliver
release targets (most sprints do not result in a value through planned releases.)
deliverable to the customer, but provide some level of
value; releases do result in customer deliverables; also, • Transform (focus on ongoing support and self-
be sure to prioritize features and set milestones tied to sustainability for the customer; be sure to educate
releases.) the team on lessons learned to be applied to future
releases.)
9. Gain management commitment to attend
retrospectives and open demos (without management Lastly, there are some situations where Agile is probably
and customer involvement, the Agile methodology NOT the best approach. Here are eight examples of where
loses its power; gaining commitment is key.) to avoid Agile methods:

10. Focus on outcomes and value, not activities or 1. Large enterprise initiatives that need requirements
hours (don’t make people feel like they’re under a defined up front, and generally require heavy
microscope - focus on what is needed, not how to go documentation
about it; allow flexibility and individual creativity, and
focus only on agreed-upon outcomes and value for 2. Where formal specs are needed for auditability, safety,
each sprint - freedom with hours and creativity can or preciseness
balance out the heavy focus on achievement, and
agreement on what’s achievable can reduce pressure.) 3. Where scope and requirements are known, can be
defined, and are unlikely to change much

5
4. Where lots of approvals are needed by multiple parties 7. If the team lacks interpersonal skills or heavy technical
knowledge (i.e. they can’t be empowered)
5. Where the organizational or team culture is
incompatible with an Agile approach 8. If the team is too large to be effective at cross-
communication (i.e. over 100 people, though this
6. If customers/users are not generally available to number can vary depending on the culture and
participate technology involved)

Virtual Teams and Agile

According to Gartner, by 2015, three quarters of webinars, Twitter-like tools such as Yammer, collaboration
knowledge-based project work in the Global 2000 will be websites, or other media. Some organizations have even
completed by distributed virtual teams. This presents new taken to the use of Wikis to capture, organize, and share
challenges in collaboration, which is a central tenet of knowledge.
Agile. With this in mind, an understanding of new media
and online collaboration tools will become more and more This also applies to organizations that are currently unable
important. or unwilling to co-locate their development teams. Most
Agile experts agree that co-location is best, but with the
Agile teams will need to employ methods to stay in right technology and the right principles, distributed
regular communication, whether by teleconference, teams can still be effective.

Planview Enterprise and Agile

Planview Enterprise has features to support organizations • To-Do List and Notes functionality for story details
that use the Agile methodology. These include:
• Content Management for documenting and storing
• Agile column sets when examining project schedules in information from sprint retrospectives
the Work Manager. Built-in fields include:
• A Community page for discussions and team updates
•• Sprint (the associated Sprint name)
• Resource authorizations for tracking time and cost
•• Story # - unique identifier code (can optionally link
to a URL and/or other software) • Resource Reserves for high level resource demand
planning
•• Story Status (e.g., Done, In Progress, Not Started,
etc.) • Defined user roles for the various participants in the
Agile methodology
•• Sprint Start Date / Finish Date
• Custom reporting dashboards and Insight Analytics
•• Story Points Planned (manually recorded) OLAP reporting tool, offering iteration velocity
comparisons, weekly burndown charts, and end-of-
•• Story Points Planned Roll-Up (calculated iteration reports
automatically)

•• Story Points Earned (manually recorded)

•• Story Points Earned Roll-Up (calculated

automatically)

6
Below is a typical Agile column set for an Agile project:

The typical Agile process using Planview Enterprise is as • Iterations or sprints may be planned for whatever
follows: duration is determined by each project team. And
stories can include those from developers, testers and
• Managers and developers populate sprints with user other team members to ensure that working software or
stories from the project backlog with a simple cut/paste tangible value can be delivered on a frequent basis.
function.
•• Note: Some companies, such as Planview, have all
•• Note: If stories are finished early, the remaining time projects on the same sprint schedule. Others have a
in the sprint can be spent on other stories from the separate schedule per project.
backlog.
• There is no need for scheduled start, scheduled finish,
• Developers may assign themselves as resources to duration, or planning of effort. Sprint dates are fixed,
stories, make testing notes directly against the story and progress is tracked via planned and earned story
for viewing and editing by all team members; they can points.
also track actual effort expended against a story via
Planview’s timesheet for project costing purposes. •• Note: This frequently requires a cultural adjustment,
so plan accordingly.
•• Note: Assignments can be done in a number
of different ways. Allocations are NOT the
best approach because effort is not planned
and schedules should not “slip.” The reserve/
authorization combo is best. Reserves (soft booking
named resources) and Authorizations (allowing
named resources to enter time) can be at a project
or phase level.

7
Using Planview Enterprise with Other Agile Tools
Many Agile developers use products such as Atlassian’s • In the Agile tool, developers assign and implement the
JIRA, CA Agile Central, Version One, and IBM Rational work to deliver features
Team Concert. These products and others, have full-
featured Agile capabilities, each with their own emphasis • Story Point and Status updates go to Planview
and strengths. Enterprise for the project manager

Planview Enterprise and Agile tools all offer story point • A story identifier in Planview Enterprise links to the story
entry and tracking, velocity and burndown charts, and in the Agile tool
collaboration. This may lead to the question: What’s the
benefit of using Planview Enterprise with these other Agile • Resource Authorizations and Reserves are entered in
products? Planview Enterprise at the project or phase level, and
time tracking (if desired) is done in Planview Enterprise
The benefits of using Planview Enterprise in the mix with
other Agile solutions are as follows: Some organizations only use Planview Enterprise for
resource authorizations and reserves, doing all their
• To align program and portfolio management with tracking and reporting in their Agile tool. Others allow
development work stories to be entered in the Agile tool or Planview
Enterprise, depending on the development team’s
• To better integrate operational plans to Agile execution preference, with everything being electronically replicated
in Planview Enterprise and the other software via a batch
• To enable resource managers to balance demand with process.
capacity
To summarize:
• To share project status seamlessly across management
and development teams Planview Enterprise has Agile support, including Agile
column sets that support story creation and story point
• To enable project managers and developers to tracking, as well as team-based capacity planning, content
communicate in their own languages – everyone gets to management, collaboration, and burndown and velocity
work within their own preferred tool charts.

• To make high-level approval, timing, and resource Planview Enterprise software can also be used in
allocation decisions based on how you plan capacity conjunction with leading Agile software, such as JIRA,
and demand, be it FTEs, money, user story points, ideal CA Agile Central, Version One, and IBM Rational Team
developer days, and/or other measures Concert.

• To improve efficiency, productivity, and collaboration When using Planview solutions with an Agile tool, multiple
options exist, and the approach depends on organizational
The integration with an Agile tool provides a different preference and overall use of Planview Enterprise.
workflow:

• In Planview Enterprise, a product or project manager

inputs project phases, iterations, and high level tasks

• The data is sent to the Agile tool

8
 About Planview Enterprise
Today’s business leaders are under pressure to execute Planview Enterprise, a market leading solution for end-
on strategy, given the reality of constrained people to-end portfolio management, from ideation through
and financial resources, in an increasingly competitive operational planning, execution, and value delivery.
marketplace.
Learn more about Planview Enterprise for Agile in the
Planview Enterprise is a portfolio and resource Planview Enterprise demo.
management solution that connects strategy to execution
by improving decision making across the enterprise,
including product development, IT, and services. By
integrating planning and execution, Planview Enterprise
enables organizations to prioritize their portfolios, balance
organizational capacity against demand, link plans
and resources to project execution, and manage the
underlying financials of the entire process. Planview’s focus
on portfolio and resource management drives a unique
level of innovation and commitment to customer success.

About the Author

Jerry Manas is an internationally is a popular speaker at events around the world, speaking
best-selling author, speaker, and on resource planning, organizational change, lessons from
consultant. He is frequently cited history, and other topics.
by leading voices in the world
of business, including legendary In addition to his writing, consulting, and keynotes, Jerry
management guru Tom Peters (“In is a founding member of The Creating We Institute, an
Search of Excellence”), who often international thought leadership community dedicated
references Manas’s bestselling book to fostering WE-centric thinking in organizations through
Napoleon on Project Management research in neuroscience and positive psychology. He.
for its insights on simplicity and character, and Pat was also part of the leadership team for several Project
Williams, Senior VP of the Orlando Magic, who called Management Institute standards.
Manas’s book Managing the Gray Areas “a new path for
leaders.” Jerry’s work has been highlighted in a variety of
publications, including the Houston Chronicle, Chicago
Jerry’s latest book is The Resource Management and Sun Times, National Post, Globe and Mail, Huffington
Capacity Planning Handbook (McGraw-Hill), which Judith Post, and others. He has appeared on radio and TV
E. Glaser, noted author of Conversational Intelligence, internationally, including Iceland, where he appeared
touted as “the first book dedicated to what is essentially on a National TV program talking about their economic
the drivetrain of organizations—the effective use of its recovery.
people toward its most important activities.” He also
co-authored the bestseller, 42 Rules for Creating WE with Follow him on Twitter @jerrymanas
Glaser, which Angela Ahrendts, CEO of Burberry, called
“today’s greatest guide for team success.”

A sought-after consultant, Jerry helps clients maximize

their organizational people resources, leading to a greater
capacity to innovate, a more value-focused and productive
workforce, and an increased ability to adapt to change. He

WP709LTREN © 2017 Planview, Inc., All Rights Reserved.