Abstract
During the past several years, an intense interest in the adoption of Lean Agile methods (Lean, Scrum, Dynamic Systems Development Method (DSDM), eXtreme Programming, etc.) in both private and public sectors has led to an increased demand for agile approaches, tools, and techniques. Industry leaders have discovered that, when implemented appropriately, agile accelerates project delivery times, increases customer and employee satisfaction, and provides flexibility to changes in business requirements.
What are the expectations around the agile project manager (PM) within an agile project management framework? What agile tools, techniques, and approaches does the project manager have at his or her disposal to ensure a productive and successful agile team? How can traditional PMs be best positi oned to execute their new agile roles and responsibilities, while still leveraging certain traditional best practices and knowledge areas from the Project Management Institute (PMI®), A Guide to the Project Management Body of Knowledge (PMBOK® Guides–Fourth Edition?
This paper will discuss how to combine the newer breakthrough principles of lean agile methodologies with complementary time-tested project management practices to deliver business value on agile projects.
Session learning objectives:
- Understand basics around lean and agile principles and approaches,
- Articulate the benefits of agile techniques,
- Understand the typical barriers in implementing agile within an organization,
- Discover how agile frameworks align with the PMBOK® Guide practices and knowledge areas, and
- Experience how the agile principles have been applied to real world projects.
Introduction
Lean agile project management is a combination of three distinct yet harmonious systems of action. Each system is actively pursuing the same goal, to deliver a product or service to the needs and expectation of the customer. Some will argue that the three are camps with conflicting views. We do not. We believe the three complement each other and as a whole will consistently deliver a better product or service, in exponentially shorter time and at a competitive cost advantage. In prior years, PMs would have focused purely on delivering to scope, on time and to budget, working with skill through project initiation, planning, and execution. While at the same time, monitoring events and applying corrective action when needed. But all too often it wasn't enough, as both customers and management would often point out and still do today, too many Information Technology (IT) projects fail, come in late and over budget.
Exhibit 1. Chaos Report from Standish Group (2009)
The Standish Group International first published compelling evidence of the state of technology projects in the CHAOS report (1995). This report noted that challenged and impaired projects were, on average, 189% over budget and approximately 200% of schedule. Recent studies have shown a marked improvement in these percentages, but they are still too high (see Chaos Summary 2009, April). Many of the success factors originally reported the 1995 report are today often cited as lean agile practices, and in fact, agile and optimization are specifically identified as CHAOS critical success factors.
Indeed with the application of lean agile methods, PMs and their teams can significantly outperform their prior performance, and it is not unreasonable to expect gains of 200% to 400% in productivity (Poppendieck & August, 2006, p xix). Lean provides the science for continual process improvement and agile provides already proven disciplines, techniques, and tools for a team to adopt.
Overview of Lean-Agile principles
Lean thinking agilists believe the whole team and indeed the whole organization should be customer focused. This means we actively solicit from our customers what they specifically value about our products and services. We can then study our processes to see which activities actually create customer value and look to optimize these activities and remove or take a less complicated approach to non-customer, value added activities. Surprisingly, less than 10% of business processes (service) actively create customer value and IT processes (cognitive) are typically about 5% efficient (George, 2003, p 36).
Lean evolved from process improvement efforts of manufacturing organizations such as Toyota. Initial improvement efforts focused on operations but later included ‘services’ as found in the ‘office’ (e.g., Human Resources (HR), order delivery, and research and development (R&D) (e.g., product development and software development).
Lean thinking helps us understand what our customers truly value and establish metrics designed to provide evidence of our ability to satisfy their needs. Exhibit 2 provides a typical grouping of such metrics (Lacher, 2008).
Exhibit 2. Lean Agile Performance Metrics
Lean thinking gives PMs and teams tools to see excessive waste, ceremony, and complexity within our daily activities, to recognize which are impediments worth attacking, and then apply an appropriate improvement to obtain a desired result. Most importantly lean insists we maintain run charts that demonstrate our performance over time. Performance can be demonstrated in any of the Exhibit 2 metrics and often while targeting a specific metric to improve, we will witness others improving also.
What is Agile?
Agile is the implementation of lean thinking (Poppendieck, August 2006, p xviii) and while it has become well known in recent years, some of the practices were first coined in a 1986 Harvard Business Review paper called “The New New Product Development Game” (Takeuchi, 1986).
Agile is often thought of as a tool box full of tried and proven disciplines, techniques, and tools for speeding up and delivering on time. It specifies four values and 12 principles. Not all agile ideas will work within a given team. Using lean thinking, you can determine root causes for project impediments, and then select from the agile arsenal those items that are known to have had the desired impact.
Agile Values
In 2001, 17 thought leaders in the software development practices community gathered together and crafted the Manifesto for Agile Software Development, as a statement of shared values:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.” (agilemanifesto, 2001)
The 12 Agile Principles
The 12 Agile principles (abridged) are (agilemanifesto, 2001):
- Satisfy the customer through early and continuous delivery of valuable software,
- The best requirements and designs emerge from self-directed teams,
- Welcome changing requirements and use change for a competitive advantage,
- Deliver working software as frequently as possible,
- Customers and developers must work together daily throughout the project,
- Trust people, and give them the leadership, environment, and support they need,
- Convey information to and within the team using face-to-face conversation,
- Working software is the primary measure of progress,
- Sponsors, developers, and users should be able to maintain a constant pace,
- Continuous attention to technical excellence and good design enhances agility,
- Simplicity (the art of maximizing the amount of work not done) is essential, and
- At regular intervals, the team reflects on what and how to do better and adjusts.
Benefits of Lean and Agile
These are the most commonly reported benefits of Lean and Agile (CC Pace Systems):
- Focus is maintained on delivering the customer's highest priority items first and more frequently,
- Process and progress is open and visible to stakeholders,
- Project can now be managed by trend data as collected in run charts, control charts and histograms,
- Continuous alignment of delivered product to business needs via feedback loops and iterative planning,
- Risk is reduced because of the first three items listed above,
- The solution emerges, allowing continual learning without irreversible decisions early in the process,
- Work in progress is in small batches (reducing complexity),
- There is a controlled response to change at predetermined points (i.e., the start of every new sprint),
- Teamwork, collaboration, and morale improve,
- Relationships with business partners improve, and
- Productivity increases as rhythm develops, inefficiencies are rooted out, creativity flourishes, and morale increases.
Scrum (Agile Project Management) and XP (Agile engineering) frameworks explained
Agile roles and responsibilities
The Product Owner:
- Develops and maintains the product backlog,
- Defines the features of the product, decides on release date and content,
- Is empowered to make decisions for all customers and users,
- Is responsible for the profitability/value of the product (return on investment or ROI),
- Prioritizes features according to market and/or user value,
- Can change features and priority between iterations,
- Accepts or rejects work results, and
- Jointly accountable for the success of the project with the Scrum Team and the Scrum Master.
The Scrum team:
- Cross-functional, seven plus or minus two members,
- Business and technical domain skills to build an increment of functionality,
- Organizes itself and its work,
- Responsible for identifying, estimating, and committing to work,
- Works with product owner to identify iteration goal, specifies work it will commit to,
- Empowered within the boundaries of the project guidelines to do whatever needed to reach, the iteration goal. It takes ownership for what needs to be done and do it,
- Demos work results to the product owner (and stakeholders), and
- Jointly accountable for the success of the project.
The Scrum Master:
- Ensures the process is followed, trains team (and stakeholders) on the process,
- Enables optimum environment for maximum team productivity,
- Enables close cooperation across all roles and functions and removes barriers,
- Shields the team from external interference,
- Ensures impediments are resolved, and
- Jointly accountable for the success of the project.
Unique role of the Agile PM
While the agile scrum approach is clearly a planning approach, it recognizes just the three distinct roles of product owner, scrum master and team member. Agile and scrum does not attempt to codify the role of a PM and leaves it to each organization to determine how project management responsibilities are to be performed. Two common approaches are:
- 1) The PM adapts his or her project management style to include the responsibilities of the scrum master, and
- 2) The PM continues to perform all existing project management duties but defers to the scrum master for activities related directly to the scrum team.
Agile Planning - Scrum
Agile utilizes a simple yet elegant approach called, scrum, to plan a project and to schedule work. Scrum is fast and accurate. It is a “rolling wave” planning approach. It has two levels of planning: product release planning and sprint planning.
A product-release planning meeting will occur at the beginning of the project and in front of each release. The team will agree to work in sprints (a.k.a., iterations). Each sprint is the same length and is typically one-, two- or 4-week(s) long.
Product Release Planning
At the beginning of a project, the PM requests the agile team to attend a product release planning session where the customer (a.k.a., product owner) describes the project scope, which includes the Work Breakdown Structure (WBS). Within the scrum process, the WBS is called a backlog of stories. Each story is a product element, and the product owner tells the team what the story is all about. The team discusses the stories, clarifies its understanding of the story, and offers up a quick opinion as to how they would create a solution for the story. Story narration and discussion typically takes three to five minutes per story, and often will result in as many as 20% additional stories added as a result of the team's analysis. The team quickly assigns a relative sizing to the story, using one of several prescribed approaches. At the end of hearing all stories, the team sums up the relative size of all stories. The team estimates how many story points it can complete in a sprint and divides the total story-point count by the proposed story points the team can complete in a single sprint to determine how many sprints it will take to complete all work.
Sprint Planning
At the beginning of each sprint the team quickly hears the product owner describe the stories he or she wishes completed during the next sprint. The team tasks out the work necessary to completely build the story and volunteers to perform the various tasks. More stories are introduced, tasked and volunteered until the team believes it is at full capacity for the sprint. The team commits to the work and the meeting ends and work immediately begins on the stories within the sprint.
Scrum adheres to Project Management Institute's (PMI) A Guide to the Project Management Book of Knowledge (PMBOK® Guide)—3rd Edition approach to completing a work breakdown structure. Scrum can be used for any “work request' and not just software development. Scrum teams always give empirical evidence when a story is done, by giving a demo of the solution to the customer. Scrum teams reflect at the end of each sprint on what went well and what needs to improve. Any work not completed in the sprint is called hangover, and the team is obligated to complete this work in the next sprint.
Scrum teams see change as an asset and not as a liability, so they welcome change and adapt quickly. Since the team only commits to one sprint at a time, the product owner can reorder, add, change, and withdraw any story in the product backlog. Scope change and the team's ability to adapt are recorded and made highly visible by the Current Code Complete Forecast Chart (Exhibit 4).
Agile Tracking and Metrics
Each sprint the scrum master maintains on the wall a sprint burndown chart (Exhibit 3) of the ideal developer days completed. This chart is often thought of as equivalent to a Schedule Performance Index (SPI). When the “actual” line appears to the right of the “planned” line then the team is behind schedule. When the actual line falls below the planned line (i.e., left of the line) then the team is ahead of schedule.
Exhibit 3. Sprint Burndown Chart
Lean agile teams maintain on the wall a Current Code Complete Forecast Chart that shows the historical record of the scope in terms of story points, of the teams completed story points, and the forecast of remaining story points.
Exhibit 4. Current Code Complete
Exhibit 5. Delivery Rate
Agile Tools and Resources
Software Engineering Techniques and Tools.
Most engineering tools are specific to product development, but the underlying principles are relevant to all workgroups. These principles are to right size your tools and mistake proof your work product. Examples of the specialized techniques and tools are Test Driven Development, Automated Test and Continuous Builds.
Barriers to Agile adoption
In a recent study by VersionOne (VersionOne, 2008 July), the following were cited as barriers for further adoption of agile:
- Ability to change organizational culture – 45%
- General resistance to change – 44%
- Personnel with the necessary agile experience – 42%
- Management Support – 32%
- Project complexity of size – 23%
- Customer Collaboration – 22%
- Confidence in the ability to scale agile methods – 17%
- Perceived time to transition – 10%
- Budget Constraints – 10%
How PMBOK® Guide aligns with agile project management approaches
Today's PMBOK® Guide clearly recognizes the importance of product and process management. Beginning with the third edition, the PMBOK® Guide speaks specifically in the project quality management knowledge area for a process improvement plan and the use of the seven quality analysis tools. Lean addresses these concerns. Another PMBOK® Guide—Third Edition clarification was on the importance of a WBS, referring to the breakdown of the work product and not the work effort. Agile addresses this by planning and scheduling work based on a backlog of stories'. This is the heart of the agile technique called scrum and addresses a lean concept known as Complexity Reduction. You can complete work faster if your end-to-end process and product elements are smaller and therefore less complex.
