(Re)Introducing Project Management in a SAFe world
This wiki focusses on (Re)Introducing Project Program and Portfolio Management to firms that have introduced SAFe but do not have a functioning PMO. This article is intended for both SAFe practitioners and Project, Program and Portfolio Managers and the Executives that lead them.
Contents |
Background
Traditionally Software development has utilized Project, Program and Portfolio Management to support delivery. However with the creation of more effective small scale software development new approaches like Scrum (late 1980's / early 1990's), Extreme programming (1996), DevOps (late 1990's) the Agile manifesto (2001) and Design Thinking (2000's) made there way into Software development.
These practices gave the organizations that adopted them significant success with results such as 98% of respondents saying they experienced success with Agile practices and 75% saying that more than half of their Agile projects were successful [1]
Methods such as SAFe, DAD and LeSS emerged in response to the demand from companies to be able to scale the advantages these practices gave the companies that used them. From the mid 2010's these practices were regularly featured in popular business literature such as Forbes and Harvard Business Review.[1] [2]
Then with the introduction of the Scaled Agile Framework (SAFe), into development organizations (released 2011), the most popular Enterprise scale Agile model in the world [3] effectively advocated removing Project Managers from development organizations.
The early SAFe versions advocacy of a new organization with new roles took traditional project, program and portfolio manager responsibilities and moved them into the new SAFe's roles such as Product Owners, Scrum Masters, RTE, Epic and Business Owners. Coming from its roots in team scrum the model initially.
This led many organizations to "throw out the baby with the bathwater" as they implemented SAFe as the model did not account for the value that project, program and portfolio management roles & their practices Without recognizing the in the incorporated or clearly articulated in these early versions of SAFe. During the period 2011-2017 Project management as a separate formal practice within many software development Organizations literally had no place in those organizations that deployed SAFe as written. This is important because as of 2017 the SAFe methodology was used by 45% [3] of those firms using an Agile methodology at scale. Many of these firms have had to contend with a number of issues that this caused up until the acceptance of Project Management through its "(Re)introduction" in the form of an Agile Project Management Office (APMO) in the 2017 release of SAFe version 4,5. This new version implicitly accepted the role PMO's (and by extension Project Managers) play in strategy formation, Project and Program execution as well as owning and disseminating best practices (in this case represented in the SAFe model by the "Lean Centre of Excellence"). In this article we look at the issues that have arisen in many firms during their SAFe implementations and how implementing an APMO solves these issues. The article is intended for practitioners who are working in or with organizations that have deployed early versions of SAFe as part of the support for establishing an APMO along the lines now advocated by SAFe. It is also relevant or those organizations that are implementing SAFe but have not had an effective PMO in place before 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.
Scaled Agile Framework (SAFe)
According to the extensive "Scaling Agile Report 2017" by C-Prime .[3] SAFe is the most popular Scaling Agile methodology by far. It is more than twice as popular as its nearest competitor Scrum of Scrums (or Scrum @ Scale) and more than 3 times as the 3rd most popular choice "Custom" (representing an in house patchwork of approaches)
What is SAFe?
According to ScaledAgileFramework.com[5]:
Quoting Dean Leffingwell (the creator and chief methodologist of SAFe) [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”
ScaledAgileFramework.com illustrates the overall framework below. It 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
The seven core competencies:
From the Sacledagileframework.com[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"
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
Introduction of Project, Program and Portfolio management
From SAFe 4,5 onwards we start to see the introduction of formal portfolio management processes as historically defined . First with Lean Budgets and then more features in each version until SAFe V5.0 which effectively introduces full portfolio management and portfolio optimization capabilities in the traditional project management sense with Portfolio Kanbans and Backlogs, Lean Budgets and project & program budget "Guardrails". By also introducing an APMO working with the Lean Center of Excellence it seems the model has created P3O's definition of program or portfolio offices
Roles and responsibilities
Developer and tester roles remain very similarly defined to the past but have new practices such as daily stand-ups, regular demo's & retrospectives but the roles responsibilities remain broadly the same but SAFe defines new roles in its organizations such as Scrum Master, Product Owner, Product Manager, Release Train Engineer and Solution Train Engineer, System Engineer & Solution Architects. This means may of the higher level expert and managerial positions change change substantially - having different relationships, responsibilities and reporting lines than.
What are the benefits of SAFE?
As advertised on ScaleAgileFramewrok.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
Results like these sound very impressive. 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.
Issues raised with SAFe
file:///C:/Users/ben_b/Downloads/Barroca2019_Chapter_AgileTransformationASummaryAnd.pdf
Epics Epic owners as PM's without a home pmo and with weakend authoity and budget control. Epics at scale larger irganizations may have multiple Epicowners outside of the business but have no PMO to help organize them
Difficulty managing Value
Only some of the advantages of flexibility with none of the advantages of standardization. Stories across team mean estimation is a mess. COP but without mandates to adopt best practices & paradoxically A standard one size fits all - but PI planning may be a waste for Maintenance teams, team Kanban is most appropriate
Synchronizing work. Dependencies and prioiritization. ART's over Cross function al epics - who may have
Standards
Long term planning and dealing with the big things. In order to optimize value SAFe advocates focus on completing small things that have value now, large and complex deliveries with payouts that may not come for a long time are very difficult to deal with with. WSJF is not always the right tool in these cases. When large difficult developments come along the ART is not designed to deal with them . Spikes for the next PI are all very well but for businesses with Commitments to 3rd parties this can be very hard to handle
Everyone outside the SAFe bubble. 3rd party suppliers, Projects with the rest of the organization,
Keeping agile at abstract levels of responsibility Team level has very clear roles and responsibilities but by the time you scale up to the Epic Owners and Business Owners of 100 person ARTs the responsibilities start to get more abstract and the structures and organizations that may be needed to function optimally are missing
What is an Epic owner - often in practice a senior Product Manager delivering some work or a dedicated person to handle cross ART work that requires significant co-ordination making up for weaknesses or absence of formal standardised processes across the organization with a weakened escalation path and due to missing PMO
Sold as bottom up but actually top down In reality teams "pick the work the organization needs them to.
SAFe still contains some process theatre. Team scrum is flexible and practices can esasily be adapted (so retrospectives likley to be able to be resolved quickly in the scrum team itself. In larger organizations a teams after a few "Retrospective" sessions the team have a back log of issues that have been escalated but management are unable to resolve. This cam create disillusion in practices
Project Management as a practice is challenged
For a number of different reasons Project Management as a practice is challenged during an Agile transformation
Culture Change within the development organization
In ADKAR (Prosci’s ADKAR model for best practice for Change Management) [6]. The A stands for Awareness of the need for change, absorbing this best practice the SAFe implementation model suggests creating “A burning platform”" [7]. as part of motivating people towards the change. This “Burning platform” creates 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 will reject Project Management
Culture of the wider Agile Community
The Agile community coming out of Scrum and finding itself newly empowered with extra roles and responsibilities and its practices being recognized and 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" [8]. Although these are natural responses in this context the agile communities history and background in devleopment shows here by ignoring or discounting all of the other befits of project management. 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 parts of the model. Dean Leffingwell the creator of SAFe while introducing the APMO even tries to differentiate it from traditional PMO’s implying that old PMO’s were in some way not of equal value
Change in responsibilities in the organization
The responsibilities from most development organizations business as usual roles such as Team and department managers, tech leads and team leads can easily become Srum Masters, RTE’s or Architects. The majority of roles in a company fall into these categories but project management does not.
Consultants become the change agents for SAFe implementations
Traditionally most companies would look to their own PMO to source Program Management resources for initiatives of this size and would still retain ownership and accountability even where consultants or third parties were bought in to manage the execution. But while implementing SAFe most companies seek external SAFe consultancy support to act as early “Lean Agile Change Agents (before the organization establishes its lean center of Excellence). Even where Project managers start these programs with all of the traditional tools like long term multi workstream projects and plans the ownership of the execution tends to move to the Consultants. As soon as the transformation starts long term planning is replaced by Kanban boards and backlogs. The chnage projects original Governance and organization are disrupted. As are the roles of everyone involved in the change from scrum masters to Business owners. In this landscape it is common for control of the Project management to slip. Early successes with culture change as represented by new and higher levels of employee engagement and satisfaction INSERT CITATION demonstrate the value of the new working practices validating decisions to
General criticisms of SAFe
I practice most organizations find work arounds to solve these issues as they mature, but as common problems experienced during implementation and early adoption they could be either incorporated more explicitly into the model or resolved by addressing them formally as part of the implementation.
Delegated Authority & Budgets Historical versions of SAFe moved many traditional project and program manager responsibilities to lower levels in the organization. For example Product Owners might be given scope and therefore de-facto budget responsibility for delivery. Profitability for deals can easily be eroded where product owners manage scope and client satisfaction without regard to the bigger picture. This problem is particularly pronounced at the Epic level when multiple teams and ART’s are involved. Each team and ART aims to do the best job they can and the potential for additional work to gold plate and futureproof solutions can lead to new unnecessary scope/costs
Dependency management
In the absence of standards for prioritization and value agreed across Teams and ART’s deliveries - in particular larger "Epics" - can have issues synchronizing work. Even in teams with standards for agreeing value and having shared estimation basis, it is common that one team 1s blocking issue is not prioritized by team 2 due to higher value work in their backlog or the imperative to stick to their own sprints commitments. This can lead to delays and lost productivity that a traditional project manager would have resolved
Dependency management processes across teams and ART’s need to be very advanced and flexible to optimize delivery. This is hard to do in practice. Otherwise delegated authority to make these decisions needs to be delegated sufficiently to optimize for whole deliverable performance.
- Hard to prioritize large and difficult things
SAFe implementations introduce lots of new working practices such as Business Kanbans
(Re) Introducing a SAFe APMO
Motivation for (Re)Introducing an (A)PMO
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:
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].
PMO's address many of the problems raised with SAFe
In the study "Recurring Concerns and Best Practices of Agile Coaches and Scrum Masters" [10] Analyzes the issues raised by Scrum Masters and Agile coaches. As the Agile coach operates at all levels of the organization the issues raised can be seen as general issues rather than specific to any one role. 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
This list of Mediating actions fits very well with many activities performed by a formal PMO along the lines of the those recommended by Axelos or the PMI (through its P3O methodology). Point 5 of the concussions very explicitly states that Companies should incorporate best practices regardless of its inclusion in the SAFe model formally or not.
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.
Dean Leffingwell says so...
As Dean Leffingwell (the creator and chief methodologist at SAFe) himself said in his 2010 book "Agile Software Requirements"[11] "Project Managers should be re-tasked as Agile Project Managers." This new role was specifically intended to address managing the types of issues 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. 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). As much as the CoE is defined in SAFe as a Lean CoE it is likley that the role would expand- help manage issues thag can happen at Epic level and to support Business owners in organizsations with multiple release trains.
in 2017 also addresses issues such as Budget control through "Budget Guardrails"
Although this was published a year before the release of SAFe the thought appears to have finally emerged in the SAFe framework by 2017.
How to (Re)Introduce a (A)PMO
Best practice would suggest implementing a P3M3 maturity assessment to identify the state of the organization prior to identifying the organizations aspiration for the function.
and then implementing the most appropriate form of PMO and next steps to implementing or re-invogorating whatever functions fulfilling these roles .
Considering the specific issues of Budget/Value control
Addressing the culture issue
Issues with Implementing a PMO
- Cultural resistance - Organizational maturity and ability to absorb change
Beyond SAF'e V5.0's APMO
Current SAFe model 4.5 addresses many issues by providing a flexible new function - the APMO but it does not address all of the issues raised in XXXX.
For instance: By not clarifying the scope of the manate of the new LACE/APMO it does not clarify as the scope necessarily have a mandate to address issues with Communities of practice not rolling out best practices efficiently
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 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
Quotes
Article on Medium.com - On of the 15 reasons to choose SAFe over waterfall was give as "2. Enhancing the Role of Project and Program Managers". [12]
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.0 1.1 https://hbr.org/2016/05/embracing-agile , https://hbr.org/2018/05/agile-at-scale, May 2018
- ↑ 'https://www.forbes.com/sites/lbsbusinessstrategyreview/2020/03/28/the-new-boardroom-imperative-from-agility-to-resilience/?sh=66e52fbc3867, Forbes March 2029'.
- ↑ 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.
- ↑ '[Dikert et al. 2016; Alsaqaf et al. 2019;Uludag et al. 2018].
- ↑ 5.0 5.1 5.2 https://www.scaledagileframework.com/about/
- ↑ https://www.prosci.com/adkar/adkar-model/
- ↑ https://www.scaledagileframework.com/implementation-roadmap/
- ↑ https://www.mountaingoatsoftware.com/agile/agile-project-management
- ↑ https://docs.broadcom.com/doc/how-agile-and-devops-enable-digital-readiness-and-transformation /Page 12
- ↑ Recurring_Concerns_and_Best_Practices_of_Agile_Coaches_and_Scrum_Masters, Oct 2019
- ↑ Dean Leffingwell, Agile Software Requirements, (Wesley, 2010),
- ↑ https://medium.com/scaled-agile-framework/15-reasons-why-safe-is-essential-for-agile-teams-494ddd264518
