Agile and project managers

tough questions

Abstract

Gartner analysts predicted that by 2012 agile development methods would be used in 80% of all software development projects. In 2011, PMI launched its PMI Agile Certified Practitioner (PMI-ACP)® offering as a response to this increase in agile adoption.

As PMI embraces agile approaches to project management practices, project management practitioners are left questioning what it means for their careers. Rally Software surveyed project managers about their most pressing agile questions and received thousands of responses.

The top questions included:

  • How do traditional roles change?
  • How do I work with distributed teams?
  • How do I work with plan driven or “waterfall” teams?
  • How do I fund agile projects?

This paper answers these questions and provides guidance based on individual experiences, expert resources, and best practices amassed over the years by Rally Agile Coaches.

How do Traditional Roles Change?

The underlying question behind this question is “do I still have a job?” Agile does not eliminate your job — there is work for everyone. Your role is your unique set of skills and perspectives that you bring to the team and organization, which may not neatly map to your title.

In Scrum, the most prevalent of the agile frameworks are three roles: ScrumMaster, Product Owner, and Team (also referred to as delivery team or core team); the three combined roles create the Scrum or agile team.

The Scrum Alliance (www.scrumalliance.org) describes the three roles as:

  • Product Owner: responsible for the business value of the project
  • ScrumMaster: ensures the team is functional and productive
  • Team: self-organizes to get the work done

Let's look at the roles in a bit more detail.

Product Owner: Responsible for the business value of the project

The product owner is a very important role in agile. The role of the product owner represents the voice of the customer. The Product Owner conveys the product vision and goals to the team and is responsible for creating and sequencing the work for the team to maximize value delivery.

The role of the Product Owner is in many ways the most dramatic shift when moving from a waterfall world to an agile world. In the waterfall world, we expect requirements to be documented in detail, signed off and handed over to the development team with very little interaction occurring between the business and customer until product delivery. In agile, the Product Owner must be available to the team on a regular basis to answer questions and provide feedback on the delivery increments being created by the team. The Product Owner is a single voice to the team that often represents many stakeholders.

Good Product Owners tends to be domain experts, comfortable working with all types of stakeholders. Product Owners may be currently known as Product Managers, Business Analysts, Marketing Analysts, Solutions Architects, or other titles.

The ScrumMaster: Ensures the team is functional and productive

The ScrumMaster is often referred to as a “Servant Leader,” indicating that he or she serves the team and strives to make the team a high performing one. As such, the role of the ScrumMaster is the chief communicator, facilitator, and impediment remover for the team. The ScrumMaster protects the team from outside distractions so that they can remain focused on their commitments. The ScrumMaster does not commit to schedules and dates on behalf of the team; however, he or she will facilitate planning and communication of dates and schedules in service of the team.

There is a myth that traditional project managers cannot transition to becoming a ScrumMaster. This is generally untrue. Skills that indicate a good fit for a ScrumMaster are people who enjoy facilitating discussions and helping others arrive at solutions, mentoring and developing people, good listening skills, and the ability to see the larger picture.

Team: Self-organizes to get the work done

The role of the team is to deliver the highest value backlog items. The team is comprised of individual people who perform hands-on work to design, build and test, high quality, potentially deployable products. If your current title is “software engineer,” “business analyst,” or “quality engineer,” your agile role most likely will be “delivery team member.” Agile believes in cross-functional team members and given this, agile breaks down traditional silos such as designers, developers, and testers.

In regards to roles, a key differentiator is to break down the traditional silos and work together as a whole team to create high value, high quality products that will delight our customers, regardless of our titles.

Enterprise Agile

Scrum is meant to be a simple foundational framework. As organizations scale from projects to programs and enterprise level agile, you may need to add in additional roles. These roles may look similar to what you might expect in larger organizations. Examples include delivery managers, program mangers, release managers, chief architects, chief product owners, and portfolio managers. The focus of these roles is above the foundational scrum team level.

How do I work with distributed and off-shore teams?

There is a myth that in order to “be agile,” the whole team must be co-located. This is not generally true. None of the agile frameworks requires teams to be co-located.

However, an agile principle in the Agile Manifesto states, “Business people and developers must work together daily through the project. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

The point is that people need to communicate effectively. Co-location usually makes communication easier. Working in a distributed team is difficult regardless of the type of method you use. If your organization is distributed, you can reduce your risk by implementing agile. Agile requires frequent feedback loops, a regular cadence of inspecting and adapting, and fosters better communication.

Tools that are used by distributed agile teams, include bringing people together from distributed locations for project kick offs and other major milestones. Many organizations are using high quality video conferencing and collaboration tools such as smart boards and electronic ALM tools. The least effective method of communication is passing documentation back and forth.

How do I work with waterfall teams?

Probably not surprisingly — the key is collaboration. The first step in creating an effective environment for collaboration is creating a shared understanding. This is true regardless of traditional or agile methods.

If we take a moment to look at A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Process Groups that encompass a project phase. First there is Initiating, which consists of chartering and stakeholder identification. In many organizations, this may occur before an idea becomes an official project.

Planning is about, requirements, work breakdown structure, estimating, dependencies, risk identification, critical path and sequencing, scheduling, and budgeting.

Execution is coding, testing, resource management, and more. There is a feedback loop between planning and execution. The change in thinking between waterfall projects and agile projects is in the implementation. Most waterfall projects view feedback as “rework” or something to be avoided through better planning. Agile sees the feedback as a critical part of planning that continues throughout execution.

Waterfall projects are often delivered in phases. Agile is similar in that it has five levels of planning: Vision, Roadmap, Release, Iteration, and Daily. The Roadmap and Release levels align almost perfectly with a PMBOK® Guide Phase and multi-phase project. An Agile Release plan describes how a sequence of iterations will combine to incrementally deliver on the objective or theme of a Release.

Agile organizations may choose to use “iteration zero,” which is a time-boxed period at the beginning of a release or project phase when the agile team will prepare and plan for the upcoming series of iterations. Activities in iteration zero may include developing the initial backlog, making initial architectural decisions, creating the initial release plan, and setting up development and testing environments.

The significant differences between Iteration Zero and the Planning activities of traditional teams are:

  • Working as a team – Agile teams don't wait until “experts” have completed the analysis, design and planning before engaging the rest of the team
  • Limit duration – Agile teams intentionally time-box themselves to avoid ‘analysis paralysis’ and to ensure they get started, which is when the most learning happens
  • Keep it high level – Agile teams maintain flexibility and allow details to emerge as they're executing
  • Plan to re-plan – Agile teams intentionally plan to revisit and revise their plans, rather than allowing for the potential to re-plan on an interruptive basis

There are many ways to report status — for the overall program, for the agile and waterfall teams individually, and for specific features, activities and perspectives. Again, the key is communication and collaboration.

How do I plan an agile project?

This question is really about how do I predict or estimate how much something is going to cost and when it will be done? Agile isn't asking you to throw away your current knowledge and expertise on estimating projects. Agile asks the Product Owner to be responsible for managing the ROI of the products being built by the team. Even in an agile world we still have the triple constraint of Scope, Schedule, and Budget. Agile provides us with new and simpler ways of dealing with these constraints.

Central to how agile deals with these constraints, and most everything else, is the idea of THE TEAM. Small, persistent, dedicated, cross-functional, cohesive, collaborative, self-organizing – THE TEAM is at the beginning and end of how agile succeeds. For the purposes of this discussion, there are three attributes of an agile team that are important: backlog, cost, and velocity.

Backlog: The backlog is the list of work for the delivery team “to do”; this includes design, build and test, all activities to create high quality, potentially shippable product increments.

Cost: Every team has a cost. If there is a team of 7 people with a blended rate of US$90 per hour working 40 hours a week—that is US$25,200 per week. If the same team works in two-week iterations, then the team cost would be US$52,400 per iteration; and a four-week iteration would be double that amount.

Velocity: Every team has a velocity. Velocity is equal to distance over time, miles per hour, feet per second. In an agile world:

  • Distance is a measure of “size” of the work to be done, the size of the backlog of work
  • Time is our iteration length, which for this purpose will be two weeks.
  • So, when we talk about velocity, we're talking about how much work the team gets done in a two-week period.

Every agile team has a velocity — and they track their velocity. At regular cadences they analyze their velocity and use it to determine their capability as a team. Agile teams typically know their “best” or highest velocity, their “worst” or slowest velocity and their average velocity over time. Teams strive for a consistent sustainable pace. The data can then be used to empirically project and plan for the future.

On fixed-scope projects, teams can calculate when the project will be complete in X number of iterations based on our best, worst, and average velocity. On fixed-date projects the team can calculate the cut line of what will be completed by a given time period. The data aren't based on extensive, time consuming and costly analysis; they are based on empirical data provided by the team. This may feel familiar to the “Best Case, Worst Case, Most Likely” formats commonly used in organizations.

Funding Models

Increasingly, we see organizations that are moving toward smaller, more iterative and incremental funding models — independent of agile initiatives. Organizations feel it helps them control risk, maintain focus on priorities, enables them to be more nimble and responsive to their customers and markets. The business can choose to fund projects at whatever incremental cadence they wish — quarterly, monthly, or even at the iteration level. Given the nature of agile projects, delivering potentially shippable product increments during every iteration provides the business with the ability to change directions, without the risk and cost of abandoning projects mid-stream.

Fixed-priced contracts at their core are a way of transferring risk from the purchaser to the supplier. As the supplier, if you don't deliver or if you exceed budget — the cost is yours. You take on the risk versus the client. The customer is paying the organization to take on the risk. Similar to when you would bid a fixed price waterfall project, you want to increase your price to cover reasonable overages, but not too much because you want to win the business. This can make for some tough conversations between customers and sales and sales and development.

Agile actually makes this a lot easier. Because teams have historical velocity – and data about the variability of that velocity – businesses can more effectively and scientifically make these decisions.

  • Should we bid at our average velocity?
  • Our worst velocity?

Thinking back to the biggest question behind the questions, will I still have a job? The magic of agile comes from the whole team. The Product Owner is the voice of the customer and business. The ScrumMaster enables the team by mentoring, facilitating, and growing the team. The Delivery Team understands the goals and shares in the commitment; as the team matures they establish a predictable sustainable velocity, which provides the business with empirical data to make decisions. As organizations scale they need experienced people to steer the ship. Agile includes everyone.

Agile Manifesto (2001). Principles behind the Agile Manifesto. Retrieved from http://agilemanifesto.org/principles.html

Gartner, Inc. (2009). Predicts 2010: Agile and Cloud Impact Application Development Directions. Retrieved from http://www.gartner.com/DisplayDocument?id=1244514

Rally Software (2011). PMP? Bring us your toughest Agile questions. UserVoice.com Feedback Forum archived at http://vote.rallydev.com/forums/123437-pmp-bring-us-your-toughest-agile-questions-

Scrum Alliance (2008). Scrum: The Basics. Retrieved from http://www.scrumalliance.org/pages/scrum_101

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2013, Julie Chickering
Originally published as part of 2013 PMI Global Congress Proceedings — Istanbul, Turkey

Advertisement

Advertisement

Related Content

  • PM Network

    Degrees of Uncertainty member content locked

    By Fewell, Jesse If you've never heard project managers debate the merits of agile, here's a quick summary. A gruff project manager says, "Since your agile approach doesn't fit my oil exploration projects, it's not…

  • PM Network

    Hello, Agile member content locked

    PM Network asks the project management community about agile buy-in.

  • PM Network

    Agile and Ageism registered user content locked

    By Fewell, Jesse A post in LinkedIn sparked comments by project managers feeling caught in the middle of "agile transformations." As a Gen Xer in between the youngest and oldest members of today's workforces, Jesse…

  • PM Network

    Bridging Ambition and Ability registered user content locked

    By Parsi, Novid Agile is everywhere, but not every organization is ready for it. According to the 12th annual State of Agile survey published by CollabNet VersionOne, 41 percent of organizations cite a lack of…

  • PM Network

    On Alert registered user content locked

    PM Network asks the project management community for insight into how to monitor progress in a way that can identify and mitigate potential problems.

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.