(Re)Introducing Project Management in a SAFe world

From apppm
(Difference between revisions)
Jump to: navigation, search
(→‎Background)
(→‎Why (Re)Introduce an (A)PMO)
 
(41 intermediate revisions by one user not shown)
Line 1: Line 1:
−
Prior to 2017 Scaled Agile Framework (SAFe) had no concept of a PMO. With SAFe versions 4,5 the model begins to re-introduce the functions of a PMO. Companies that implemented the earlier versions of SAFe could benefit from (re)introducing a PMO.
 
−
This article addresses issues with not having a PMO and best practice for (Re)introducing a PMO.
 
−
It is intended for SAFe practitioners, Project, Program and Portfolio Managers and Executives that lead Agile organizations.
 
  
 
By Ben Blackburn
 
By Ben Blackburn
 +
 +
Prior to 2017 Scaled Agile Framework (SAFe) had no concept of a PMO. With SAFe versions 4,5 the model begins to re-introduce the functions of a PMO. Companies that implemented the earlier versions of SAFe could benefit from (re)introducing a PMO. This article addresses issues experienced with SAFe Implementations and with not having a PMO as well as best practice for (Re)introducing a PMO.
 +
It is intended for SAFe practitioners, Project, Program and Portfolio Managers and Executives that lead Agile organizations.
  
 
==Background==
 
==Background==
Line 38: Line 38:
  
  
−
As a consequence many companies have had to contend with a variety of issues caused by the removal of PPPM practices and would benefit from (Re)-introducing them. Issues:
+
As a consequence many companies have had to contend with a variety of issues caused by both the Agile Transformation and the removal of PPPM practices and would benefit from (Re)-introducing a (A)PMO. This wiki looks at 3 groups of Issues:
  
−
- During Implementation
 
  
−
- General issues with Scaled Agile Frameworks
 
  
−
- Specific Issues with SAFe
+
- General issues with Agile Frameworks
 +
 
 +
- Conceptual Issues with SAFe specifically
 +
 
 +
- Personal observations on SAFe implementations
  
  
Line 121: Line 123:
  
  
−
=== During Implementation ===
 
−
 
−
 
−
 
 
=== General issues with Agile Frameworks===
 
=== General issues with Agile Frameworks===
  
Line 131: Line 129:
  
 
Issues 1,2,3,4 & 7 in the report are generally related to the implementation but 5.6.8 & 9 can be seen after implementation.  
 
Issues 1,2,3,4 & 7 in the report are generally related to the implementation but 5.6.8 & 9 can be seen after implementation.  
 +
  
 
5.Top-down versus Bottom-up Implementation of Large-Scale Agile Frameworks
 
5.Top-down versus Bottom-up Implementation of Large-Scale Agile Frameworks
 +
 
For example: Bottom up models tend to create large numbers of teams that have fragmented working practices, Tooling, Methods of communicating, Definitions of done etc. This can create additional complexity coordinating amongst teams and getting a clear picture of the organization from the top. Whereas Top down models tend to take the enthusiasm out of the Agile transformation by being seen a prescriptive and unresponsive to the needs to the teams
 
For example: Bottom up models tend to create large numbers of teams that have fragmented working practices, Tooling, Methods of communicating, Definitions of done etc. This can create additional complexity coordinating amongst teams and getting a clear picture of the organization from the top. Whereas Top down models tend to take the enthusiasm out of the Agile transformation by being seen a prescriptive and unresponsive to the needs to the teams
 
PMO's can support the bottom autonomy while helping deploy best practice and standards that may be needed across ART's and Value Trains to support consolidated business level planning for the top   
 
PMO's can support the bottom autonomy while helping deploy best practice and standards that may be needed across ART's and Value Trains to support consolidated business level planning for the top   
  
 
6.Over-emphasis on 100% Framework Adherence over Value
 
6.Over-emphasis on 100% Framework Adherence over Value
 +
 
For example: Maintenance teams that rely on kanban for their workload management being called into PI planning events and 2 weekly sprint cycles despite the practice being wasteful and unnecessary for the team.
 
For example: Maintenance teams that rely on kanban for their workload management being called into PI planning events and 2 weekly sprint cycles despite the practice being wasteful and unnecessary for the team.
  
 
8.Maintaining Developer Autonomy in Large-Scale Agile Frameworks
 
8.Maintaining Developer Autonomy in Large-Scale Agile Frameworks
−
For example: Autonomy and flexibility in choice of tooling is difficult to scale as corporate IT systems and policies are not designed to support unlimited variety in tooling. Tooling often also represents the working behaviors, practices and limits of teams activities and the variety of working practices works against the principles of flexibility of the teams across the whole organization to work together on new challenges.
+
 
−
Dependency Management can also be problematic when there are a wide variety of practices      
+
For example: Autonomy and flexibility in choice of tooling is difficult to scale as corporate IT systems and policies are not designed to support unlimited variety in tooling. Tooling often also represents the working behaviors, practices and limits of teams activities and the variety of working practices works against the principles of flexibility of the teams across the whole organization to work together on new challenges. Dependencies across team can also be problematic when there are a wide variety of possible communication channels, prioritization methods and cadences etc      
 +
PMO's can help manage the complexity of different teams working differently 
  
 
9.Misalignment between Customer Processes and Large-Scale Agile Frameworks
 
9.Misalignment between Customer Processes and Large-Scale Agile Frameworks
−
Manifests in 2 forms. Customer engagement especially on larger Epics is not well accounted for. Agile suggests customer engagement but SAFe stops at the Epic Owner assuming the are always aligned with the customer. But there is also a wider point that SAFe does not have specific customer engagement roles which may be required to manage for example: large Client contract relationships. It is also does not account well for management of third parties and interfaces with the wider enterprise it operates in.  
+
 
−
PMO's can provide flexible resources to help deal with things like supporting the development organization deal with external stakeholders
+
Agile suggests customer engagement but SAFe stops at the Epic Owner assuming the are a proxy for the customer that is always engaged with and aligned with the customer.
 +
 
 +
===Conceptual Issues with SAFe===
 +
 
 +
A common theme across articles on SAFe is ultimately that SAFe is not Agile enough <ref name ="problems">https://productcoalition.com/the-major-problems-with-safe-1e797f7e48f8 </ref>
 +
<ref name ="problems2">https://blog.projectmanagementacademy.net/common-problems-with-safe#:~:text=%20Common%20Problems%20When%20Using%20Scaled%20Agile%20(SAFe),approaches,%20the%20word%20%E2%80%9Cepic%E2%80%9D%20refers%20to...%20More </ref>it:
 +
 +
 
 +
c- Focuses on Methodology. So things like Processes and velocity become the focus rather than creation of value
 +
 
 +
 
 +
- Lacks of Flexibility & Autonomy. Teams are constrained by ART structures, PI's and processes to support control in a wider organization
 +
 
 +
- Can hide the real issues. For example by focusing on Co-ordination between teams to manage dependencies it can look over organization as the underlying problem
 +
 
 +
 
 +
Although these are not issues that would be resolved by a PPPM or a PMO specifically, they do point to a need for organizations to have a clear idea of what Agile is to their organization. They also  need to align everyone in the organization with that vision to ensure everyone  is pulling in the same direction. An APMO can support the Lean Agile Center of excellence with this
 +
 
 +
===Personal observations on SAFe implementations===
 +
 
 +
Below are personal observations based on 2 organizations that have adopted SAFe
 +
 +
- Issues with Epic ownership.
 +
Epic owners have influence but not authority to get their initiatives prioritized. Without a PMO escalation of issues can be more difficult for an Epic Owner as they have less access to peers and best practices. If Epics are run from within an ART/Value stream (Usually by Product Management) they have great authority within their ART but are often unable to focus on the Epic as it is only one of very many responsibilities they have, the Product Manager may have factors limited knowledge outside their ART/Value stream and a number of other factors  from Politics between Peers to maturity of Dependency management processes can effect their ability to execute   
 +
 
 +
-SAFe is rooted in Scrum which in turn made its biggest successes in Business to Consumer product development and when used inside companies in house IT teams. It is optimized to deliver small packets of work that create value at the end of each sprint. This works very well for delivery of a new feature for an app, or delivery of new feature to a trading desk. But it does not necessarily support delivery of large complex packages of work that are tied into formal contracts or large deliveries. There are issues with A) the conflicts between MVP for a contract and PO's making the customer happy with every feature, B) Very large cross functional things are hard to get prioritized C) Regulatory and Contract penalty dates for Large developments are problematics as estimates based on the last "large thing" can easily be wrong by a significant margin.  The approach to solving these problems is not the same as smaller more certain things. Mitigations like Spikes to look into work for the next PI can give an illusion of progress rather than ensure success, in effect more analysis work is required upfront than SAFe suggests.
 +
 
 +
- Interfaces outside of the SAFe Organization Interfaces with the rest of the organization, Management of customer contracts and 3rd party suppliers etc is very unclear in the model. SAFe pretty much ignores that this may require substantial effort and assumes it can easily be absorbed into other roles. SAFe does not open up to roles that may be needed as part of managing these interfaces
 +
 
 +
 
 +
A formal PMO could assit with all of these points.
  
 
== (Re) Introducing a SAFe APMO  ==
 
== (Re) Introducing a SAFe APMO  ==
  
 +
===What are the benefits from introducing an APMO===
 +
 +
Much of the published literature on the subject of "Issues with SAFe Implementation" focuses on abstract concepts that relate to Agile principles.
 +
 +
But some issues from the literature and my personal experiences provide concrete issues that (A)PMO's can address.
 +
 
 +
(Re)Introducing a APMO:
 +
1) Will add significant additional budget control to most large organizations.
 +
2) It will ensure strategy is defined and executed throughout the organization in line with Managements expectations
 +
3) It can support at a senior level for cross organization projects and programs that may otherwise have insufficient sponsorship
 +
4) A PMO incorporating a Lean Agile Center of Excellence can support the spread and adoption of new practices across the organization by helping remove impediments throughout the organization
 +
 +
=== Why (Re)Introduce an (A)PMO ===
  
−
===Motivation for (Re)Introducing an (A)PMO ===
+
'''Successful Agile companies recognize the value of Portfolio Management'''
−
'''Formal Portfolio Management is a best practice in successful Agile companies'''
+
  
 
Market Research from CA Technologies suggests that "Agility Masters" (defined as the top 18% of respondents in terms of maturity of Agile and DevOps practices) are:
 
Market Research from CA Technologies suggests that "Agility Masters" (defined as the top 18% of respondents in terms of maturity of Agile and DevOps practices) are:
Line 159: Line 203:
 
2) 4.1 times more likely to agree the company has the right Vision and strategy <ref name ="intagpract"> https://docs.broadcom.com/doc/how-agile-and-devops-enable-digital-readiness-and-transformation /Page 12</ref>.
 
2) 4.1 times more likely to agree the company has the right Vision and strategy <ref name ="intagpract"> https://docs.broadcom.com/doc/how-agile-and-devops-enable-digital-readiness-and-transformation /Page 12</ref>.
  
−
This leads to the conclusion that larger companies benefit the most from Implementing SAFe with a strong PMO supporting strategy formation and execution regardless of any specific direction or lack of direction about this from SAFe.
+
This leads to the conclusion that companies benefit the most from Implementing SAFe with a strong PMO supporting strategy formation and execution regardless of any specific direction or lack of direction about this from SAFe.
  
  
−
'''PMO's address many of the problems raised with early versions of SAFe'''
+
'''Dean Leffingwell says so...'''
 +
Dean Leffingwell (the creator and chief methodologist at SAFe) advocates having an APMO in recent versions of the model.
 +
His support for this appears to have been longstanding as all the way back in 2010 Dean Leffingwell in his 2010 book "Agile Software Requirements"<ref name ="ASR">Dean Leffingwell, Agile Software Requirements, (Wesley, 2010),</ref> he suggested "Re-tasking your project managers  as Agile Project Managers."  Both then and now Dean Leffingwell appears to be recognizing that PPPM was more than just the tasks handed out to Scrum Masters and Product Owners but it has other responsibilities such as stewardship of value, facilitating strategy execution. 
  
−
The study "Recurring Concerns and Best Practices of Agile Coaches and Scrum Masters" <ref name ="communication"> Recurring_Concerns_and_Best_Practices_of_Agile_Coaches_and_Scrum_Masters, Oct 2019</ref>
 
−
Analyzes the issues raised by Scrum Masters and Agile coaches. The issues are analyzed and specific best practices within Agile suggested to resolve them. The conclusion of the study is that the majority of issues in SAFe implementations can be addressed with the mediating actions below.   
 
−
(1) PUBLISH GOOD PRACTICES
 
−
(2) SUPERVISION
 
−
(3) GLOBAL IMPEDIMENT PROCESS
 
−
(4) GLOBAL IMPEDIMENT BOARD
 
−
(5) DON’T USE SCALING AGILE FRAMEWORKS AS A RECIPE
 
  
−
When modified to apply to fits very well with many activities performed by a formal PMO along the lines of the those recommended by Axelos or the PMI. Points 3 & 4 relating to Global Boards very explicitly states that Companies should have higher level bodies to help manage issues across teams conflicts incorporate best practices regardless of its inclusion in the SAFe model formally or not.
+
The introduction of the APMO into SAFe suggest an active role for a PMO to both support execution and to act as a Center of Excellence(CoE). Many would recognize this as two of the key aspects of a Portfolio planning function in line with P3O best practice.
  
−
'''Dean Leffingwell says so...'''
+
=== Preparing for (Re)Introducing a (A)PMO ===
−
As Dean Leffingwell (the creator and chief methodologist at SAFe) advocates having an APMO from Version 4,5 the most up to date versions of the model suggest having one optimal for organizational performance. As the monitoring and control of value is managed out of the APMO it may also be advantageous to as Dean Leffingwell says himself in his 2010 book "Agile Software Requirements"<ref name ="ASR">Dean Leffingwell, Agile Software Requirements, (Wesley, 2010),</ref> "Project Managers should be re-tasked as Agile Project Managers." to monitor value on projects.
+
−
Both then and now Dean Leffingwell appears to be recognizing the value of all of the parts of project management that were not passed explicitly into the scrum teams themselves such as contract and relationship management and communication interfaces with suppliers, customers and other parts of the enterprise.
+
  
 +
Can be broken down into 2 areas.
  
−
The introduction of the APMO into SAFe suggest an active role for a PMO to both support execution and to act as a Center of Excellence(CoE). Many would recognize this as two of the key aspects of a Portfolio planning function in line with P3O best practice.
+
1) Maturity Assessment
  
−
=== How to (Re)Introduce a (A)PMO ===
+
2) Change Management
  
−
Best practice would suggest implementing a P3M3 maturity assessment to identify the state of the organization prior to identifying at what stage of maturity the organization is as well as to identify the organizations aspiration for the function and best practice implementation approach.  
+
===Maturity Assessment ===
−
It would be advisable for any Assessment to be run by someone who is also used to the SAFe  model to ensure alignment of language and full awareness of the practices that already exist in the SAFe organization that mitigate many concerns that could otherwise be raised.  
+
Best practice would suggest implementing a P3M3 maturity assessment. This is used to identify the state of the organization prior to identifying the organizations aspiration and then the relevant best practice implementation approach.  
 +
Its advisable for any Assessment to be run by someone who is also used to the SAFe  model to ensure alignment of language and full awareness of the practices that already exist in the SAFe organization.
  
−
[[File:p3m3.PNG]]
+
The P3M3 model below shows the factors considered in the maturity model at each level, Prohject, Program & Portfolio. (Resource management, financial management etc.) these for a standard 5 phase maturity model from processes in each area starting at Aware and moving up from reoeatable to defined to managed to optimized.   
  
 +
[[File:p3m3.PNG]]
  
 +
===Change Management===
  
−
Best practice would suggest use of a formal change management model such as ADKAR to guide the introduction of these changes.  
+
Best practice suggests use of a formal change management model such as ADKAR to guide the introduction of these changes.  
  
 
As many SAFe organizations have spent considerable time and energy rejecting past practices they may resist the introduction of what might be considered old fashioned practices. So aligning it to the latest models of SAFe, the framing of the reasons to change and language used in the initiative is likely to be vey important to its success
 
As many SAFe organizations have spent considerable time and energy rejecting past practices they may resist the introduction of what might be considered old fashioned practices. So aligning it to the latest models of SAFe, the framing of the reasons to change and language used in the initiative is likely to be vey important to its success
  
−
=== Addressing the culture issue ===
+
Another important consideration is Addressing the culture issue
  
−
For a number of different reasons Project Management as a practice was challenged during these early SAFe transformations. Some of these issues are still live despite the model change to SAFe incorporating an APMO. These should consdered during the Reintroduction of the APMO  
+
For a number of different reasons Project Management as a practice was challenged during these early SAFe transformations. Some of these issues are still live despite the model change to SAFe incorporating an APMO. These should considered as part of the Reintroduction of the APMO  
  
 
Culture Change within the development organization
 
Culture Change within the development organization
Line 205: Line 246:
  
 
Lean Agile Consultants were the new change agents
 
Lean Agile Consultants were the new change agents
−
As the companies original PMO made way for SAFe consultancy support acting as “Lean Agile Change Agents" planning was replaced by Kanban boards and backlogs. The consultants or their replacements in the Lean centre of excellence can be challenged by competitors leading and organizing change in the form of the APMO.
+
As the companies original PMO made way for SAFe consultancy support acting as “Lean Agile Change Agents" planning was replaced by Kanban boards and backlogs. The consultants or their replacements in the Lean center of excellence can be challenged by competitors leading and organizing change in the form of the APMO.
  
 
==Annotated Bibliography==
 
==Annotated Bibliography==
Line 224: Line 265:
 
Background to Agile adoption and key trends in Agile by one of the larger dedicated Agile Systems vendors. Circa 1500 respondents across industries and at varying organizational sizes. Covers everything from motivations to adopting Agile through to to perceptions of success and specific techniques used. Solid general background to Agile in practice
 
Background to Agile adoption and key trends in Agile by one of the larger dedicated Agile Systems vendors. Circa 1500 respondents across industries and at varying organizational sizes. Covers everything from motivations to adopting Agile through to to perceptions of success and specific techniques used. Solid general background to Agile in practice
  
−
==Quotes==
+
−
 
+
'''The Principles of Product Development Flow'''
−
Article on Medium.com
+
Second Generation Lean Product Development Hardcover – 1 May 2009, by Donald G Reinertsen 
−
- On of the 15 reasons to choose SAFe over waterfall was give as "2. Enhancing the Role of Project and Program Managers". <ref name ="MEDIUM">https://medium.com/scaled-agile-framework/15-reasons-why-safe-is-essential-for-agile-teams-494ddd264518</ref>
+
One of the core texts in Agile. Covers Queues, Batch, sizes, WIP Decentralized control all bought into one guide to being Agile.
  
 
== Suggestions for further reading ==
 
== Suggestions for further reading ==

Latest revision as of 23:35, 28 February 2021

By Ben Blackburn

Prior to 2017 Scaled Agile Framework (SAFe) had no concept of a PMO. With SAFe versions 4,5 the model begins to re-introduce the functions of a PMO. Companies that implemented the earlier versions of SAFe could benefit from (re)introducing a PMO. This article addresses issues experienced with SAFe Implementations and with not having a PMO as well as best practice for (Re)introducing a PMO. It is intended for SAFe practitioners, Project, Program and Portfolio Managers and Executives that lead Agile organizations.

Contents

[edit] Background

Traditionally Software development has utilized Project, Program and Portfolio Management to support waterfall delivery. In response to long times to market and inefficient bureaucratic practices, new 'Agile' approaches to software development emerged:

1986 Scrum (1986 Hirotaka Takeuchi and Ikujiro Nonaka / 1990's Jeff Sutherland, Ken Scwaber, John Scumniotales and Jeff McKenn),

1990's Design Thinking (but originally created in the 1960's for product management)

1996 Extreme programming (Kent Beck),

1996 Lean (Womacjk & Jones)

2001 The Agile manifesto

2008 DevOps (late 1990's crystalizing in Pätrick Debois 2008/9) & LAterly DevSecOps


The Agile practices gave significant advantage to the companies utilizing them and grew rapidly in popularity and adoption. As large enterprises discovered the value of the Agile practices, demand for deploying these approaches at scale grew. In response new Agile methods at scale emerged such as:

2005 Large Scale Scum (LeSS)

2011 Scaled Agile Framework (SAFe)

2015 Disciplined Agile Delivery (DAD)


From the mid 2010's Agile practices grew in recognition and were regularly featured in popular business literature such as Forbes and Harvard Business Review.[1] [2]. Those companies that adopted these practices gained significant success with results such as "98% experiencing success with Agile practices" and "75% saying that more than half of their Agile projects were successful" [1] Competition created an imperative for most software organizations to change and adopt these practices.


During the period 2011-2017 Early versions of SAFe took many traditional Project, Program & Portfolio Management (PPPM) responsibilities and moved them into the new SAFe's roles such as Product Owners, Scrum Masters, RTE, Epic and Business Owners. With the most popular Enterprise scale Agile model in the world [3] Scaled Agile Framework (SAFe), effectively advocating removing Project Management from development organizations PPPM within many software development Organizations literally had no place. This is important because as of 2017 the SAFe methodology was used by 45% [3] of those firms using an Agile methodology at scale. [3] Cprime.PNG


As a consequence many companies have had to contend with a variety of issues caused by both the Agile Transformation and the removal of PPPM practices and would benefit from (Re)-introducing a (A)PMO. This wiki looks at 3 groups of Issues:


- General issues with Agile Frameworks

- Conceptual Issues with SAFe specifically

- Personal observations on SAFe implementations


Note: Due to the relatively new and evolving nature of SAFe there is limited empirical data around specific “Implementation issues in Large Scale Agile transformations” [4]. As a consequence this article is more reliant more on Anecdotes, Personal Experience and other literature in this space.

[edit] Scaled Agile Framework (SAFe)

[edit] What is SAFe?

According to ScaledAgileFramework.com[5]:


“SAFe® for Lean Enterprises is a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps.” “It “…is built around the Seven Core Competencies of the Lean Enterprise that are critical to achieving and sustaining a competitive advantage in an increasingly digital age” Dean Leffingwell (the creator and chief methodologist of SAFe) [5]

ScaledAgileFramework.com makes this framework and support material available to all along with an extensive library of resources that can be used for free to support implementing and running SAFe in practice

Scaledagile.PNG

[edit] The seven core competencies:

SAFe is based on these 7 Competencies: [5]

- Lean-Agile Leadership – Advancing and applying Lean-Agile leadership skills that drive and sustain organizational change by empowering individuals and teams to reach their highest potential

- Team and Technical Agility – Driving team Agile behaviors as well as sound technical practices including Built-in Quality, Behavior-Driven Development (BDD), Agile testing, Test-Driven Development (TDD), and more

- Agile Product Delivery – Building high-performing teams-of-teams that use design thinking and customer-centricity to provide a continuous flow of valuable products using DevOps, the

- Continuous Delivery Pipeline, and Release on Demand Enterprise Solution Delivery – Building and sustaining the world’s largest software applications, networks, and cyber-physical solutions

- Lean Portfolio Management – Executing portfolio vision and strategy formulation, chartering portfolios, creating the Vision, Lean budgets and Guardrails, as well as portfolio prioritization, and road mapping

- Organizational Agility – Aligning strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance

- Continuous Learning Culture – Continually increasing knowledge, competence, and performance by becoming a learning organization committed to relentless improvement and innovation"

[edit] Levels & Objectives

SAFe's model aims to create an optimized "continuous delivery pipeline" via one or many Agile Release Trains (ARTs). There are 4 levels of SAFe suggested - "Essential", "Large Solution", "Portfolio" and a "Full" SAFe. All of ARTs should deliver improvements in delivery efficiency but at the Portfolio and Full levels the suggested organization changes to focus organization around the delivery of value with a more strategic portfolio emphasis relevant to larger companies that may have significant numbers of people working in a wide range of different business areas or providing a wide range of services

[edit] Introduction of Project, Program and Portfolio management into SAFe

From SAFe 4,5 onwards we start to see the introduction of formal portfolio management processes as historically defined. First with Lean Budgets in V4,5 and then more features in each version until SAFe V5.0 which effectively introduces full portfolio management and portfolio optimization capabilities in the traditional PPPM sense.

In particular the APMO's roles facilitating 1) generation and changes to the Portfolio level Kanbans & Backlogs, 2) supporting Lean Budgets as well as 3) monitoring Portfolio Value, 4) project and program budget "Guardrails", combined with 5) aligning with the Lean Center of Excellence all seem very well aligned with a P3O descriptions of the roles of a traditional program or portfolio office.

[edit] What are the benefits of SAFE?

As advertised on ScaleAgileFramework.com:

20 – 50% increase in productivity

25 – 75% improvements in quality

30 – 75% faster time-to-market

10 – 50% increase in employee engagement and job satisfaction

While Quality improvements and Employee engagement and satisfaction can be pretty straightforward to report and compare, productivity and time to market are much harder to compare directly before and after an agile transformation. Increases in productivity are often very difficult to quantify when the basis changes (I.e from hours to stories) how do you compare these apples and oranges? Likewise with Time to market - if estimation comparisons are flawed so is time to market.

That said - and working back from quality metrics with some basic assumption (like the bugs that didn't need fixing after release are now available for new development) INSERT IBM COST OF BUGS TO FIX it seems logical that organizations gain significant efficiency improvements through SAFe


My personal experience at a Mid Sized software firm was introducing basic Agile practices such as cross functional team Scrum to a traditionally Waterfall organization raised productivity from 70-80% of estimated scope per to circa 104% within 12 months. In the case I mention we had the rare situation of 3 Agile teams having the old waterfall estimation process running throughout the period as the main development organizations processes still required the provision of hourly estimates. Therefore the figures are not subject to comparison errors as is usual during an agile transformation. This experience would seem to support the kind of figures SAFe advertise.

[edit] General issues raised with SAFe

The below lists are compiled from Research on these topics supplemented by examples from my experience


[edit] General issues with Agile Frameworks

Conboy and Carroll in their 2019 study : "Implementing Large-Scale Agile Frameworks: Challenges and Recommendations[6] Report issues across implementations of different scaled frameworks but the themes contain challenges that those that have implemented SAFe will recognize.

Issues 1,2,3,4 & 7 in the report are generally related to the implementation but 5.6.8 & 9 can be seen after implementation.


5.Top-down versus Bottom-up Implementation of Large-Scale Agile Frameworks

For example: Bottom up models tend to create large numbers of teams that have fragmented working practices, Tooling, Methods of communicating, Definitions of done etc. This can create additional complexity coordinating amongst teams and getting a clear picture of the organization from the top. Whereas Top down models tend to take the enthusiasm out of the Agile transformation by being seen a prescriptive and unresponsive to the needs to the teams PMO's can support the bottom autonomy while helping deploy best practice and standards that may be needed across ART's and Value Trains to support consolidated business level planning for the top

6.Over-emphasis on 100% Framework Adherence over Value

For example: Maintenance teams that rely on kanban for their workload management being called into PI planning events and 2 weekly sprint cycles despite the practice being wasteful and unnecessary for the team.

8.Maintaining Developer Autonomy in Large-Scale Agile Frameworks

For example: Autonomy and flexibility in choice of tooling is difficult to scale as corporate IT systems and policies are not designed to support unlimited variety in tooling. Tooling often also represents the working behaviors, practices and limits of teams activities and the variety of working practices works against the principles of flexibility of the teams across the whole organization to work together on new challenges. Dependencies across team can also be problematic when there are a wide variety of possible communication channels, prioritization methods and cadences etc PMO's can help manage the complexity of different teams working differently

9.Misalignment between Customer Processes and Large-Scale Agile Frameworks

Agile suggests customer engagement but SAFe stops at the Epic Owner assuming the are a proxy for the customer that is always engaged with and aligned with the customer.

[edit] Conceptual Issues with SAFe

A common theme across articles on SAFe is ultimately that SAFe is not Agile enough [7] [8]it:


c- Focuses on Methodology. So things like Processes and velocity become the focus rather than creation of value


- Lacks of Flexibility & Autonomy. Teams are constrained by ART structures, PI's and processes to support control in a wider organization

- Can hide the real issues. For example by focusing on Co-ordination between teams to manage dependencies it can look over organization as the underlying problem


Although these are not issues that would be resolved by a PPPM or a PMO specifically, they do point to a need for organizations to have a clear idea of what Agile is to their organization. They also need to align everyone in the organization with that vision to ensure everyone is pulling in the same direction. An APMO can support the Lean Agile Center of excellence with this

[edit] Personal observations on SAFe implementations

Below are personal observations based on 2 organizations that have adopted SAFe

- Issues with Epic ownership. Epic owners have influence but not authority to get their initiatives prioritized. Without a PMO escalation of issues can be more difficult for an Epic Owner as they have less access to peers and best practices. If Epics are run from within an ART/Value stream (Usually by Product Management) they have great authority within their ART but are often unable to focus on the Epic as it is only one of very many responsibilities they have, the Product Manager may have factors limited knowledge outside their ART/Value stream and a number of other factors from Politics between Peers to maturity of Dependency management processes can effect their ability to execute

-SAFe is rooted in Scrum which in turn made its biggest successes in Business to Consumer product development and when used inside companies in house IT teams. It is optimized to deliver small packets of work that create value at the end of each sprint. This works very well for delivery of a new feature for an app, or delivery of new feature to a trading desk. But it does not necessarily support delivery of large complex packages of work that are tied into formal contracts or large deliveries. There are issues with A) the conflicts between MVP for a contract and PO's making the customer happy with every feature, B) Very large cross functional things are hard to get prioritized C) Regulatory and Contract penalty dates for Large developments are problematics as estimates based on the last "large thing" can easily be wrong by a significant margin. The approach to solving these problems is not the same as smaller more certain things. Mitigations like Spikes to look into work for the next PI can give an illusion of progress rather than ensure success, in effect more analysis work is required upfront than SAFe suggests.

- Interfaces outside of the SAFe Organization Interfaces with the rest of the organization, Management of customer contracts and 3rd party suppliers etc is very unclear in the model. SAFe pretty much ignores that this may require substantial effort and assumes it can easily be absorbed into other roles. SAFe does not open up to roles that may be needed as part of managing these interfaces


A formal PMO could assit with all of these points.

[edit] (Re) Introducing a SAFe APMO

[edit] What are the benefits from introducing an APMO

Much of the published literature on the subject of "Issues with SAFe Implementation" focuses on abstract concepts that relate to Agile principles.

But some issues from the literature and my personal experiences provide concrete issues that (A)PMO's can address.

(Re)Introducing a APMO: 1) Will add significant additional budget control to most large organizations. 2) It will ensure strategy is defined and executed throughout the organization in line with Managements expectations 3) It can support at a senior level for cross organization projects and programs that may otherwise have insufficient sponsorship 4) A PMO incorporating a Lean Agile Center of Excellence can support the spread and adoption of new practices across the organization by helping remove impediments throughout the organization

[edit] Why (Re)Introduce an (A)PMO

Successful Agile companies recognize the value of Portfolio Management

Market Research from CA Technologies suggests that "Agility Masters" (defined as the top 18% of respondents in terms of maturity of Agile and DevOps practices) are:

1) 3,2 times more likely to strongly agree that portfolio management has a key role to play in organizations

2) 4.1 times more likely to agree the company has the right Vision and strategy [9].

This leads to the conclusion that companies benefit the most from Implementing SAFe with a strong PMO supporting strategy formation and execution regardless of any specific direction or lack of direction about this from SAFe.


Dean Leffingwell says so... Dean Leffingwell (the creator and chief methodologist at SAFe) advocates having an APMO in recent versions of the model. His support for this appears to have been longstanding as all the way back in 2010 Dean Leffingwell in his 2010 book "Agile Software Requirements"[10] he suggested "Re-tasking your project managers as Agile Project Managers." Both then and now Dean Leffingwell appears to be recognizing that PPPM was more than just the tasks handed out to Scrum Masters and Product Owners but it has other responsibilities such as stewardship of value, facilitating strategy execution.


The introduction of the APMO into SAFe suggest an active role for a PMO to both support execution and to act as a Center of Excellence(CoE). Many would recognize this as two of the key aspects of a Portfolio planning function in line with P3O best practice.

[edit] Preparing for (Re)Introducing a (A)PMO

Can be broken down into 2 areas.

1) Maturity Assessment

2) Change Management

[edit] Maturity Assessment

Best practice would suggest implementing a P3M3 maturity assessment. This is used to identify the state of the organization prior to identifying the organizations aspiration and then the relevant best practice implementation approach. Its advisable for any Assessment to be run by someone who is also used to the SAFe model to ensure alignment of language and full awareness of the practices that already exist in the SAFe organization.

The P3M3 model below shows the factors considered in the maturity model at each level, Prohject, Program & Portfolio. (Resource management, financial management etc.) these for a standard 5 phase maturity model from processes in each area starting at Aware and moving up from reoeatable to defined to managed to optimized.

P3m3.PNG

[edit] Change Management

Best practice suggests use of a formal change management model such as ADKAR to guide the introduction of these changes.

As many SAFe organizations have spent considerable time and energy rejecting past practices they may resist the introduction of what might be considered old fashioned practices. So aligning it to the latest models of SAFe, the framing of the reasons to change and language used in the initiative is likely to be vey important to its success

Another important consideration is Addressing the culture issue

For a number of different reasons Project Management as a practice was challenged during these early SAFe transformations. Some of these issues are still live despite the model change to SAFe incorporating an APMO. These should considered as part of the Reintroduction of the APMO

Culture Change within the development organization In ADKAR [11]. The A stands for Awareness of the need for change, absorbing this best practice the SAFe implementation model suggests creating “A burning platform”" [12]. as part of motivating people towards the change. This “Burning platform” created a momentum away from old waterfall practices and the roles and responsibilities of the past and seeks to motivate people towards the new Organizational model. Where the SAFe implementation creates this motivation and the model excludes project management it is only natural that those practicing SAFe rejected Project Management. They may need new reasons to adopt the practices while staying true to their new ideas of work organization

Culture of the wider Agile Community The Agile community (coming out of Scrum and finding itself having scaled up into management layers is permeated with a sentiment that old school project management is not relevant any more. For example: "When it comes to agile project management roles, most agile processes - Scrum in particular - do not include a project manager. Agile “project manager” roles and responsibilities are shared among others on the project, namely the team, Scrum Master and product owner" [13]. By dismissing project management as a practice the culture also discredits their more senior colleagues in Program and Portfolio management even though that is the area in the SAFe model furthest away from SAF’e scrum roots and the most immature part of the model.

Lean Agile Consultants were the new change agents As the companies original PMO made way for SAFe consultancy support acting as “Lean Agile Change Agents" planning was replaced by Kanban boards and backlogs. The consultants or their replacements in the Lean center of excellence can be challenged by competitors leading and organizing change in the form of the APMO.

[edit] Annotated Bibliography

Broadcom https://docs.broadcom.com/doc/how-agile-and-devops-enable-digital-readiness-and-transformation

Research on the state of Adoption of Agile principles, DevOps and interestingly on the impacts of Agile practices on the wider organization. Agility and business performance opinions and statistics.

Researchgate https://www.researchgate.net/publication/336899351_Identifying_and_Documenting_Recurring_Concerns_and_Best_Practices_of_Agile_Coaches_and_Scrum_Masters_in_Large-Scale_Agile_Development

Researchgate has several useful (but small scale) studies on issues with Large Scale Agile implementations. One of the most relevant was this one. It Investigates the types of issues experienced by Practitioners of large scale agile frameworks and provides the best practice options to resolve them. Including most importantly the finding not to treat the frameworks as gospel.

VersionOne State of Agile Annual reports. https://stateofagile.com/#. Background to Agile adoption and key trends in Agile by one of the larger dedicated Agile Systems vendors. Circa 1500 respondents across industries and at varying organizational sizes. Covers everything from motivations to adopting Agile through to to perceptions of success and specific techniques used. Solid general background to Agile in practice


The Principles of Product Development Flow Second Generation Lean Product Development Hardcover – 1 May 2009, by Donald G Reinertsen One of the core texts in Agile. Covers Queues, Batch, sizes, WIP Decentralized control all bought into one guide to being Agile.

[edit] Suggestions for further reading

Scaledagileframework https://www.scaledagileframework.com/

The Agile Manifesto: https://agilemanifesto.org/

Agile Alliance: https://www.agilealliance.org/resources

Disciplined Agile https://www.pmi.org/disciplined-agile/start-here

HotPMO: https://www.hotpmo.com/


© SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc

  1. ↑ 1.0 1.1 https://hbr.org/2016/05/embracing-agile , https://hbr.org/2018/05/agile-at-scale, May 2018
  2. ↑ 'https://www.forbes.com/sites/lbsbusinessstrategyreview/2020/03/28/the-new-boardroom-imperative-from-agility-to-resilience/?sh=66e52fbc3867, Forbes March 2029'.
  3. ↑ 3.0 3.1 3.2 C-Prime, https://www.cprime.com/wp-content/uploads/woocommerce_uploads/2017/09/cPrime-Scaling-Agile-Survey-17-Digital.pdf, (NC-Prime, 2017), p14.
  4. ↑ '[Dikert et al. 2016; Alsaqaf et al. 2019;Uludag et al. 2018].
  5. ↑ 5.0 5.1 5.2 https://www.scaledagileframework.com/about/
  6. ↑ https://arxiv.org/ftp/arxiv/papers/1901/1901.08130.pdf, Conboy,K. and Carroll, N.(2019). Implementing Large-Scale Agile Frameworks: Challenges and Recommendations. IEEE Software. March/April 2019. DOI: 10.1109/MS.2018.2884865
  7. ↑ https://productcoalition.com/the-major-problems-with-safe-1e797f7e48f8
  8. ↑ https://blog.projectmanagementacademy.net/common-problems-with-safe#:~:text=%20Common%20Problems%20When%20Using%20Scaled%20Agile%20(SAFe),approaches,%20the%20word%20%E2%80%9Cepic%E2%80%9D%20refers%20to...%20More
  9. ↑ https://docs.broadcom.com/doc/how-agile-and-devops-enable-digital-readiness-and-transformation /Page 12
  10. ↑ Dean Leffingwell, Agile Software Requirements, (Wesley, 2010),
  11. ↑ https://www.prosci.com/adkar/adkar-model/
  12. ↑ https://www.scaledagileframework.com/implementation-roadmap/
  13. ↑ https://www.mountaingoatsoftware.com/agile/agile-project-management
Retrieved from "http://wiki.doing-projects.org/index.php?title=(Re)Introducing_Project_Management_in_a_SAFe_world&oldid=101597"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox