Na14 agl04 published

The PM Role in a Lean and Agile World
Dave Cornelius, DM, MBA, PMP, PMI-ACP, CSP, SSBB
Servant Leader, Lean & Agile Catalyst, KnolShare.org
Abstract
A project manager (PM) is a highly skilled knowledge worker who has received rigorous training and knowledge in the process of achieving a globally recognized certification. At the same time, in the lean and agile world, the project manager does not have an official role. The project manager’s role is distributed between the agile team members.
However, the knowledge and skills obtained through certification is transferable in the lean and agile organization. In a competitive business climate, all available brainpower must be present on deck to enable the organization to achieve enterprise agility and scale to meet customer, compliance, financial markets, internal opportunities, and competitive demands.
This paper evaluates the project manager role using the Scaled Agile Framework (SAFe) practice and centers on PM participation in the lean and agile transformation as a strategic, leading, and/or lagging PM.
Introduction
The project management field is changing with the adoption of agile practices by many product development organizations. In recent years, project manager-led projects have shifted to team-focused leadership, empowering the knowledge workers responsible for creating products or services in lean and agile transformed organizations. Undoubtedly, this shift has created a change for project managers normally assigned to leading projects. In A Guide to the Project Management Body of Knowledge (PMBOK®Guide) – Fifth Edition stated, “The role of the project manager is to lead the team that is responsible for achieving the project objectives” (PMI, 2013, p. 40). Given the definition of the PM role established by PMI’s Project Management Professional (PMP)® certification, a shift in this role will create challenges for the traditional PM.
Furthermore, the acceptance of project management practice as a key desired management skill moves project leadership from a specialized role back to the functional managers responsible for day-to-day operational management of the teams. Project management is one of the key courses required of students in MBA programs to ensure future business leaders obtain the knowledge to plan and execute projects. The elevation of project management as a key knowledge area for business leaders also will play a role in the reduction of the PM as a specialized role.
In agile frameworks and methods, the PM does not have a defined role. The Scrum practice prescribes distributing the PM role among the Scrum team members. The Scaled Agile Framework (SAFe) practice lists the PM as a potential for the Release Train Engineer (RTE), responsible as the uber-ScrumMaster. Other agile practitioners describe the PM as a coach and facilitator.
The trained PM is equipped with several key characteristics that include the following (PMI, 2013, p. 41):
© 2014, Dave Cornelius, DM, MBA, PMP, PMI-ACP, CSP, SSBB Page 1
Originally published as a part of 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA

• Leadership
• Team building
• Motivation
• Communication
• Influencing
• Decision making
• Political and cultural awareness
• Negotiation
• Trust building
• Conflict management
• Coaching
As the momentum of lean and agile thinking continues to emerge as an enterprise strategy, the PM role will change due to the lack of definition in agile practices. In fact, agile practices do not see a value in the PM role because of the tight connection to the “waterfall” method. However, without the waterfall method, the agile practice would lack a baseline to improve or have a method to compare and contrast.
Through personal experiences with agile transformations, I have witnessed PM struggles with the new role in the lean and agile world. Voices cry out for the good old days, when the PM led initiatives and projects. The new context of the PM role creates a void that will have to be replaced with the acceptance of servant leadership. Berra (2001) stated, “when you come to a fork in the road, take it” (p.1).
This paper evaluates the PM role using the SAFe practice. The SAFe model represents enterprise agility and extends Scrum beyond the team execution level into the organization. The PM role is best characterized through enterprise agility and viewed through the lens of portfolio, program, and the execution teams that are aligned to ensure maximum customer value. The discussion of this paper is centered on PM participation in the lean and agile transformation as a strategic, leading, and/or lagging PM.
All Brains on Deck
The certified PM is one of the most highly trained and skilled knowledge workers in the organization. Few individuals in the organization can navigate 10 different knowledge areas to contribute value to the organization. The 10 knowledge areas are embodied in the PMI certifications and include the following management disciplines (PMI, 2013, p. 74):
1. Integration
2. Scope
3. Time (schedule)
4. Costs
5. Quality
6. Human resources
7. Communications
8. Risks
9. Procurement
10. Stakeholder
The road to achieve a PMP® or PMI Agile Certified Practitioner (PMI-ACP)® requires experience and knowledge in the project management and agile field of practice. The preparation and training is rigorous © 2014 Dave Cornelius, DM, MBA, PMP, PMI-ACP, CSP, SSBB Page 2
Originally published as a part of 2014 PMI Global Congress Proceedings–Phoenix, Arizona, USA

and provides the prospective PM with viable skills that enable potential success during the transformation. Table 1 highlights the training and knowledge required to achieve a PMI certification.
Table 1: PMI certification requirements
Project Management Professional (PMP)
College Degree
Project Experience
Training
Examination
A four-year college degree
4,500 hours leading or directing projects
35 hours PM education
Pass a 200-question test
Without a four-year college degree
7,500 hours leading or directing projects
35 hours PM education
PMI Agile Certified Professional (PMI-ACP)
General Project Experience
Project Experience
Training
Examination
2,000 hours working on project teams within the last five years. The PMP certification satisfies this requirement.
1,500 hours working on agile projects within the last three years
21 hours of training
Note: PMI certification requirements retrieved from www.pmi.org.
Reducing the available pool of knowledge workers as an asset is highly questionable. Smart organizational leaders find ways to include everyone who can contribute to the overall success of developing products and services that meet customer demands. The reality is the organization benefits from using the maximum capabilities of the knowledge worker. Imagine trying to lift a large chair with one hand tied behind your back. I advocate for retooling the traditional PM to embrace the lean and agile way of thinking about product development.
Lean and Agile Thinking
Lean and agile thinking are contextually similar. Agile thinking derives some practices from lean principles. The concept of lean thinking comes from the manufacturing industry and credited to Toyota, the Japanese car manufacturing company (Womack & Jones, 2003). Lean, as a concept, is built on seven principles that include: 1) eliminate waste, 2) build quality in, 3) create knowledge, 4) defer commitment, 5) deliver fast, 6) respect people, and 7) optimize the whole. The lean thinking concept emphasizes continual improvement or kaizen, and respect for people (Larman & Vodde, 2009). The translation is continual learning that embraces change. Team members determine the appropriate improvement methods that reduce negative impact to customers with limited or no interference by the management team.
Lean thinking can be viewed as a practice that:
• Embraces kaizen or continual improvement
• Eliminates delays/waste
• Maximizes the value stream
• Balances flow/work in progress (WIP)
• Streamlines pull/customer demand
• Applies the plan-do-check-act method
Agile thinking is an extension of lean practices and emphasizes speed and flexibility. Agile thinking also can be described as agile critical thinking that inspects, adapts, and takes action based on the situation. The process of agile critical thinking includes the following:
• Logic–creative thinking using principles of formal scientific deduction
© 2014 Dave Cornelius, DM, MBA, PMP, PMI-ACP, CSP, SSBB Page 3

• Proof–thought supported by empirical (measured) thought
• Probing–investigative, skeptical, and digs for deeper meaning
• Consistency–doing things the same way
• Reasonable–judgment within acceptable boundaries/calculated probable outcomes
The value stream is one way that agile and lean thinking principles share a common thread. The value stream is the set of actions that create a customer value (Womack & Jones, 2003). Agile thinking is a set of practices that:
• Delivers customer value through iterative steps
• Engages people in the value stream through frequent collaboration
• Inspects and adapts
• Responds to change
• Applies the plan-do-inspect-adapt method
• Embraces continual improvement through retrospectives
PMI leaders recognized the importance of lean and agile thinking and responded with the PMI-ACP training and certification. The PMI-ACP® certification provides a transition point for the certified PM and enables the continued use of knowledge acquired in the PMP certification. A trained PM working within the context of the waterfall method can be at odds with lean and agile thinking. Transforming the PM to the lean and agile thinking will enable change, and organizational change management (OCM) provides the appropriate techniques to support sustainable change.
The Traditional PM versus the Agile PM Role
The traditional PM role, as defined by PMI, leads projects through a five-phase delivery life cycle that includes: initiating, planning, executing, monitoring and controlling, and closing. A similar comparison can be made for the agile product release that includes: initiating, planning, executing, monitoring and “learning,” and closing. Table 2 maps the traditional and agile PM role using the PMI life cycle to illustrate the shift in the PM responsibility when participating in a transformed lean and agile organization.
Table 2: Traditional versus agile PM role activities
Traditional PM Role Activities–Phase-Based (PMI lifecycle)
Agile PM Role Activities–Adaptive
(Modified PMI lifecycle)
Initiating:
• Identify stakeholder and project charter
(two activities)
Initiating:
• Product vision evangelist
(one activity)
Planning:
• Establish project scope, refine objectives, define corrective actions to maintain objectives
(24 activities)
Planning:
• Integration with non-product development teams
• Stakeholder management
(two activities)
Executing:
• Complete the work defined in project plan
(eight activities)
Executing:
• Communicate with non-product development teams
• Vendor relationship management
(two activities)

Monitoring and Controlling:
• Track, review, and regulate project progress and performance
(11 activities)
Monitoring and Learning:
• Metrics (quality, cost, and execution)
• Integration progress
• Risks and dependencies
(three activities)
Closing:
• Formally close the project or phase; close procurement
(two activities)
Closing:
• Formally close the release; close procurement
(two activities)
Note: Traditional PM activities defined by the PMBOK® Guide – Fifth Edition (2013). Agile PM activities assume a non-Scrum master role, with the primary role as integration management.
Observation, after reviewing the traditional and agile PM activities, shows that the agile PM has fewer activities to perform during the project or release life cycle. The primary reason is that the project team assumes more responsibility for project execution and continual improvements. Secondarily, some of the activities prescribed by PMI are eliminated and treated as unnecessary. Reducing waste and maximizing learning are key concepts practiced in lean and agile thinking. Lean and agile thinking fosters ways to improve incrementally and allows the knowledge workers creating the value to inspect and adapt during the process without management oversight.
Sustaining the PM Lean and Agile Transformation with Organizational Change Management
The PM will undergo a paradigm shift from leading projects to embracing the role of a servant leader. The servant leader focuses on serving team members to remove impediments that block the successful product release to market. The agile PM role can be introduced to the organization through formal leadership organization change management (OCM), grassroots methods, or a hybrid model. The formal leadership OCM models include Prosci’s ADKAR (2012), or Kotter’s 8 Steps of Change (2012). The Prosci model is depicted in Figure 1, illustrating the awareness, desire, knowledge, ability, and reinforcement (ADKAR) phases of change.
Figure 1: ADKAR Phases of change (reprinted from Prosci (2012))
Kotter’s 8 Steps of Change guide transformation through the creation of a climate for change, engage and enable the entire organization, and implement and sustain change. Figure 2 illustrates Kotter’s 8 Steps of Change.

Figure 2: Kotter’s 8 Steps of Change (reprinted from Kotter, 2012).
The grassroots leadership change method is ad hoc and driven from within the teams. This method leaves change success to chance, and measuring success becomes difficult. Furthermore, the desired outcome cannot be concisely documented for common understanding throughout the organization. Grassroots change is a viable option but should be tried on smaller teams with careful observation.
The hybrid leadership change model combines the formal OCM and grassroots approach for leading change. Some teams are allowed to pursue alternative approaches to achieving change, while other teams use the formal OCM method.
The desired result should include the following:
• Assess change readiness
• Communicate the need for change
• Provide training to enable change
• Create communities that embrace change
• Collaborate for sustaining change
The outcome will ensure that the PM and other members of the organization are working toward a common goal of lean and agile thinking. A thoughtful approach also reduces the alienation the PM can feel during the transformation into a lean and agile world.
Enterprise agility is the best model to support the vast skills of a certified PM. The SAFe model supports an enterprise agility model that includes portfolio, program, and execution (project) teams for rapid product release to market. The PM can participate in either the portfolio, program, or execution team segments of the organization.
Scaled Agile Framework (SAFe) and Enterprise Agility
The SAFe model supports enterprise agility by scaling agile practices to support business alignment throughout the organization. SAFe provides the framework that enables large teams consisting of 50 to 125 individuals to develop products and deliver to market using frequent cycles of three months. The concept of the agile release train (ART) allows organizational leaders to release products at any time in response to market demands. © 2014 Dave Cornelius, DM, MBA, PMP, PMI-ACP, CSP, SSBB Page 6

Figure 3 provides the illustration of the SAFe model. Key elements of the SAFe model include:
1. Scrum scaled as an enterprise agile solution
2. Customer engagement
3. Organization alignment
4. Responsiveness to change (inspect and adapt)
5. Team engagement
6. Transparent behaviors
7. Improved time to market
©2014 by Scaled Agile, Inc. (Reprinted with permission).
Figure 3: SAFe enterprise agile model
Servant leadership is one of the key skills the PM will need to adapt to work in the SAFe environment. The transition from the “command and control” to the servant leader model can be challenging at first. The SAFe model describes the servant leader with the following characteristics (Scaled Agile, 2014):
• Coaches the teams to deliver
• Emphasizes objectives
• Is invested in the program’s overall performance
• Asks the teams for answers

• Allows the teams to self-organize and hit their stride
• Assists others with fixing issues
The servant leader embraces serving team members to ensure continual learning to achieve success by delivering value to customers. Transitioning the PM into this mindset will be challenging for some, but the use of OCM will potentially create a community that embraces change.
The roles defined in the SAFe model provide potential transitional opportunities that a PM can assume and thereby become a valuable contributor. The SAFe portfolio, program, and execution (project) teams are three areas of the traditional project model that the PM will be familiar. As the PM role is evaluated using the SAFe model, the PM will take on a new persona and characteristics emphasizing the PM as strategic, leading, and/or lagging. A strategic PM supports the organization’s strategic objectives. The leading PM identifies ways to minimize impediments. The lagging PM provides answers to past team behaviors.
Strategic PM
The strategic PM works with the organization’s leadership responsible for the decisions that include:
• New business and architecture initiatives (epics) based on customer demands
• Market competition response
• Compliance demands
• Internal innovations (business and/or architecture epics)
• Financial market volatility
Figure 4 illustrates the portfolio level of the organization, with the strategic PM participating as a servant leader.
Figure 4: SAFe portfolio organizational level
The strategic PM plays the role that:
• Provides lean and agile coaching
• Enables future innovations
• Facilitates organization alignment
• Collaborates with portfolio management and business leaders
• Evaluates strategic insights implementation
• Measures the “voice of the customer” (VOC) deliverables
• Tracks implementation of the investment themes

• Provides project portfolio performance metrics
Table 3 compares the proposed strategic PM role in the SAFe model to the traditional PM role. A strategic PM role in the SAFe model supports the portfolio organization. The transition of portfolio members to the lean and agile world is left to an external coach for support with the implementation of the new practice. A quarterly release-planning event (RPE) connects the portfolio organization business and architecture initiatives (epics) to the organization’s execution teams but does not evaluate the success or failure of the delivered products.
Table 3: New strategic PM versus the traditional PM roles
New Strategic PM—SAFe
Traditional PM Role
N/A
The project portfolio manager role
A gap exists between measuring the external factors that triggered the portfolio initiatives and the success of delivering a solution to satisfy the desired outcome. In the software industry, a narrow view is often taken to assume the solution delivered immediately satisfied the customer demand. However, the question of return on investment (ROI) goes unanswered. Imagine investing in your 401(k) and never evaluating the return on your investments. The strategic PM can assume the responsibilities of the traditional project portfolio manager role to capture business metrics and communicate status with business leaders. Enterprise solutions require business metrics even when transforming into a lean and agile world.
The performance of an organization’s initiatives needs to be evaluated by looking at five drivers that include:
• New business and architecture initiatives (epics) based on customer demands
• Internal innovations (business and/or architecture epics)
The strategic PM plays a significant role providing information that enables business leaders to make decisions to select the appropriate business and architecture initiatives to fund.
Leading PM
The leading PM charts the future by anticipating and preventing issues that are potential impediments for the team. The role is key for leading organizational change management activities that enable cross- functional teams to adapt to the changes in the working environment. The changes can be as follows:
• New features introduced based on customer demands
• Internal innovations
Figure 5 illustrates the portfolio level of the organization with the leading PM participating as a servant leader.

Figure 5: SAFe program-level model
In the lean and agile transformation, the SAFe model program level provides the leading PM with the most opportunities. The leading PM can participate in one of the following roles in the SAFe model:
• Release Train Engineer–facilitates processes and programs for the agile release train (ART) by escalating impediments, managing risks, and coaching program-level continual improvement for maximum outcome
• Release Manager–accountable for product release to market
• Product Owner–accountable for prioritized work for the team
• ScrumMaster (coach/facilitator)–accountable for team Scrum practice; enables the transition from non-agile practices to agile and lean thinking
The four roles are responsible for connecting the execution teams’ output with the portfolio leadership initiatives. An important context is the relationship of the roles in the SAFe model to the traditional PMI model. Table 4 provides a cross-reference of the leading PM roles in the SAFe and traditional PMI model.
Table 4: New leading PM versus traditional PM roles
Roles the Lagging PM Assumes in SAFe
Traditional PM Roles
Release Train Engineer
This role can be mapped to a senior PM or program manager
Release Manager
The release manager function is part of the service management team
Product Owner
N/A
Scrum Master (Coach/Facilitator)
N/A
Lagging PM
The lagging PM explains the team’s execution or past performance through metrics, charts, and reports. The metrics include:
• Planned versus actual story points
• Team velocity trends over a three-or-more sprint timeframe
• Financial trends
• Number of defects outstanding

Corrective actions are implemented based on the team’s past performance with project or release execution. Figure 6 illustrates the organization execution team level that the lagging PM participates in as a servant leader. The results captured by the lagging PM are important for the program-level team members. The captured information enables the program team leaders to make decisions for the next set of features to produce based on the execution team’s capacity.
©2014 by Scaled Agile, Inc. Reprinted with permission.
Figure 6: SAFe execution team-level model
The lagging PM can participate in one of the following roles in the SAFe model:
• Product Owner–Validates the completed and prioritized work
• ScrumMaster (score keeper)–Measures velocity, quality, and continual improvement; tracks dependency, risks, and integration (Scrum of Scrums) issues
The product owner is responsible for the following:
• Works with the product management team to plan releases
• Ensures that the team pursues a common vision
• Drives business value through a prioritized backlog
• Defines and accepts user stories
• Represents the customer to answer questions by the product development team
The ScrumMaster is responsible for the following:
• Protects the product development team from outside noise
• Removes impediments
• Facilitates team meetings
• Coaches and facilitates agile behavior and practice
• Serves as Scrum of Scrums Master who facilitates integration (Scrum of Scrums) meetings that manage dependencies and risks
• Enables the transition from non-agile to agile and lean thinking
The product owner and ScrumMaster roles are central to enable the execution teams to build products required to satisfy business value and respond to customer demands. The lagging PM monitors and communicates learning from the execution team’s behaviors. Corrective actions come from the information gathered and enable the execution team to practice continual improvements.
An important context is the relationship of the roles in the SAFe model to the traditional PMI model. Table 5 provides a cross reference of the lagging PM roles in the SAFe and traditional PMI model. © 2014 Dave Cornelius, DM, MBA, PMP, PMI-ACP, CSP, SSBB Page 11

Table 5: New lagging PM versus traditional PM roles
Roles the Lagging PM Assumes in SAFe
Traditional PM Roles
Product Owner
N/A
Scrum Master (score keeper)
Comparable to the traditional PM responsible for monitoring, reporting, and controlling project health
Mapping the Strategic, Leading, and Lagging PM to the PMBOK® Guide – Fifth Edition and SAFe Processes
Now that the strategic, leading, and lagging PM roles have been defined, the discussion about the relationship to SAFe and the PMBOK Guide® can be reviewed. The PMBOK® Guide – Fifth Edition consists of 10 knowledge areas, five process groups, and 47 project management processes. The project management processes are activities performed or delegated by the traditional PM.
The SAFe model consists of practices from portfolio, product, and program management, lean, and Scrum methods. The SAFe processes can be directly performed or facilitated by the strategic, leading, and lagging PM roles. Table 6 summarizes the traditional PM activities associated with the PMI project management processes, process groups, and knowledge areas, as well as the strategic, leading, and lagging PM roles associated with the SAFe processes.
Table 6: Mapping the strategic, leading, and lagging PM to the The PMBOK® Guide and SAFe Processes
PMI Knowledge Areas & Process Groups
PMI Project Management Processes
Traditional PM
SAFe Processes
Strategic PM
Leading PM
Lagging PM
Integration Management
Initiating
Create charter
√
Define strategic themes
√
Planning
Develop project management plan
√
Prioritize portfolio backlog
√
Executing
Direct and manage work
√
Optimize value streams
√
√
Monitoring and Controlling
Monitoring and controlling project work
√
Lean portfolio metrics radiators
√
Perform integrated change control
√
Release planning event (RPE) based on a potentially shippable increment (PSI) boundary
√
Closing
Close project or phase
√
Close the release
√
√
√
Scope Management
Planning
Plan scope
√
Prioritize portfolio backlog
√
Collect requirements
√
Split epics, prioritize features
√
Define scope
√
Prioritize product backlog
√
√
Create WBS
√
Prioritize team sprint backlog
Validate scope
√
Defined by the prioritized work in the product backlog
√
√

Control scope
√
Execution team size and velocity limits scope
√
Time Management
Planning
Plan schedule management
√
Fixed sprints and PSI durations
√
√
Define activities
√
Frequent backlog grooming
√
√
Sequence activities
√
Prioritize user stories
√
Estimate activity resources
√
Observed team velocity
√
Estimate activity durations
√
User stories sized based on Fist of Five and Fibonacci sequence
√
Develop schedule
√
Team members commit to sprint backlog
√
Control schedule
√
Fixed sprints and PSI durations
√
Cost Management
Planning
Plan cost management
√
Agile Release Train (ART) funding
√
Estimate costs
√
Allocation based on customer demands
√
Determine budget
√
Agile Release Train (ART) budget
√
√
Control costs
√
Costs are defined on a PSI boundary
√
√
Quality Management
Planning
Plan quality management
√
Definition of ready
√
Executing
Perform quality management
√
Behavior driven development (BDD); acceptance test driven development (ATDD); and continuous integration
√
Perform quality control
√
Definition of done, pair- testing
√
Human Resource Management
Planning
Plan human resource management
√
Evaluate team capacity
√
Executing
Acquire project team
√
Dedicated teams assigned
√
Develop project team
√
Retrospectives and continual learning
√
Manage project team
√
Self-organization
√
Communications Management
Planning
Plan communications management
√
Daily stand-up meetings, sprint demos, and retrospectives
√
√
√
Executing
Manage communications
√
Display work state on Kanban boards
√
√
√
Control communications
√
Highly collaborative environment; lean portfolio metrics radiators
√
√
√
Risk Management
Planning
Plan risk
√
Deliver in small
√
√
√

management
increments; mid-PSI reviews
Identify risks
√
Fishbone and 5 Whys techniques;
Scrum of Scrums
√
√
√
Performance qualitative risk analysis
√
Swarm and proactively resolve
√
√
√
Performance quantitative risk analysis
√
Swarm and proactively resolve
√
√
√
Plan risk analysis
√
Mid-sprint reviews
√
√
√
Control risks
√
Apply WIP constraints
inspect and adapt;
remove impediments
√
√
√
Procurement Management
Planning
Plan procurement management
√
Establish strategic relationships
√
Executing
Conduct procurements
√
Develop business partnerships
√
√
√
Control procurements
√
Align with lean and agile practices
√
√
Closing
Close procurements
√
Close contracts
√
√
Stakeholder Management
Initiating
Identify stakeholder
√
Identify business owners
√
√
√
Planning
Plan stakeholder management
√
Align to a common vision
√
√
√
Executing
Manage stakeholder engagement
√
Frequent collaboration; team agreements
√
√
√
Control stakeholder engagement
√
Limit team interference
√
√
Note: The PMI Knowledge Areas, Process Groups, and project management processes are from the PMBOK® Guide – Fifth Edition (2013). The SAFe processes are retrieved from www.scaledagileframework.com.
Summary
The certified PM is a highly skilled knowledge worker capable of adding value in the lean and agile world. The training and knowledge received through the rigorous PM education program positions the PM to participate effectively in enterprise agile organizations. However, organization leaders must deploy a formal OCM to ease the PM transformation into the new paradigm of agility. Additionally, a grassroots approach can be effective to enable the PM to learn and grow into the role through trial and error.
A PM deployed in a Scrum-only environment limits the PM to the choices to participate as the product owner or as a ScrumMaster. The product owner and ScrumMaster roles are essential for teams to have prioritized work and experience continual improvement. However, PM knowledge and skills can be used in multiple ways to serve the enterprise.
The SAFe model provides the best opportunity for the PM to use skills obtained from PM training. The enterprise focus of SAFe provides the PM with a landscape to operate within the strategic, leading, and lagging PM roles introduced in this paper. The SAFe landscape includes portfolio, program, and execution (project) levels.

The PM is expected to lead by influence without authority. In the lean and agile world, the PM must become a servant leader. The transformation into a servant leader is difficult when previous experience has been a command-and-control model. The realization of becoming an agile PM provides a value that enables continual learning and improvement to members in the organization.

References
Berra, Y. (2001). When you come to a fork in the road, take it! New York, NY: Hyperion books.
Kotter, J. P. (2012). Accelerating change. Harvard Business Review. Retrieved from www.hbr.org.
Larman, C. & Vodde, B. (2009). Scaling lean & agile development: Thinking and organizational tools for large-scale Scrum. Boston, MA: Pearson Education, Inc.
Prosci. (2012). ADKAR. Retrieved from www.change-management.com.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® Guide) – Fifth edition. Newtown Square, PA: Author.
Scaled Agile Framework. (2014). Retrieved from www.scaledagileframework.com.
Womack, J. P. & Jones, D. T. (2003). Lean thinking: Banish waste and create wealth in your corporation (2nd ed.). New York, NY: Free Press, A Division of Simon & Schuster, Inc.

Acknowledgments
To my wife, Carmen, for putting up with me working on these projects on the weekends and after work in the evenings. Thank you for the patience.
Dr. Dave works in a Scaled Agile Framework (SAFe) environment as a coach and agile PM. Learn more about Dr. Dave by visiting www.Dave-Cornelius.com. Follow Dr. Dave @DrCorneliusInfo on Twitter. Dr. Cornelius is affiliated with the University of Phoenix – School of Advanced Studies.
A special thanks to Jon Jorgensen (@waterscrumban), Victor Bonacci (@agilecoffee), and Brett Palmer (@brett_palmer) for feedback on this subject. It has been great working with you on the agilecoffee.com project.
I am thankful for the support and partnership with Jill Stack Public Releations for editing my writings and making them presentable to the world.

Na14 agl04 published

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (8)

Similar a Na14 agl04 published

Similar a Na14 agl04 published (20)

Más de Dave Cornelius - Value Contributor-agility and innovation

Más de Dave Cornelius - Value Contributor-agility and innovation (10)

Último

Último (16)

Na14 agl04 published