(Re)Introducing Project Management in a SAFe world

From apppm
Revision as of 10:29, 26 February 2021 by S206391 (Talk | contribs)

Jump to: navigation, search

Traditionally Software development has utilized Project Managers and Project Management. But With the introduction of the Scaled Agile Framework (SAFe) into development organizations from its release in 2011, the most popular Enterprise scale Agile model in the world [1] effectively advocated removing Project Managers from development organizations. The early SAFe versions advocacy of a new organization with new roles took traditional project manager responsibilities and moved them (partially) into the new SAFe's roles such as Product Owners, Scrum Masters and RTE’s. This led many organizations to "throw out the baby with the bathwater" by ignoring the value of those project, program and portfolio management practices that were not 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% [1] 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” [2] . As a consequence this article is more reliant more on Anecdotes, Personal Experience and other literature in this space.


Contents

Scaled Agile Framework (SAFe)

According to the extensive "Scaling Agile Report 2017" by C-Prime .[1] 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)

Cprime.PNG

What is SAFe?

According to ScaledAgileFramework.com[3]:

Quoting Dean Leffingwell (the creator and chief methodologist of SAFe) [3]

“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

Scaledagile.PNG

The seven core competencies from the Sacledagileframework.com[3]:

"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"

Objectives and levels SAFe's model aims to create an optimized "continuous delivery pipeline" via one or many Agile Release Trains (ARTs). Depending on the size of the organization there are 4 levels of SAFe suggested. These are "Essential", "Large Solution", "Portfolio" and a "Full" SAFe.These trains are organized around the delivery of value.

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) it seems clear that organizations gain significant efficiency improvements through SAFe


My personal experience at a Mid Sized software firm in 2016/7 where introducing cross functional team scrum to a traditionally Waterfall team raised delivery from 70-80% of estimated scope per delivery period to 104% within 12 months of introducing the working practices. In this case I mention we had the rare situation of 3 Agile teams having the old waterfall estimation process running before and after the teams went Agile as part of the main organizations processes so the figures are not subject to comparison errors. This experience would seem to support the kind of figures SAFe advertise.

Issues raised with SAFe

Here we look at the the Issues raised with SAFe's early versions through the lens of the standard 10 knowledge areas from the PMI's "Project Management Body of Knowledge" 6th edition


- PM’s and Agile coaches "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" https://www.mountaingoatsoftware.com/agile/agile-project-management

- Hard to prioritize large and difficult things

- Interfaces with the rest of the organization & Customers

- Changes in roles and responsibilities – PO’s, - overloading of some roles - PO's

- Dependency management

- Budgets

- Tooling changes



SAFe Implementation methodology

What is the new SAFe APMO ?

Creating a new SAFe APMO

Does the new SAFe APMO address the issues raised in previous versions of SAFe?

How to create a SAFe APMO

P3O maturity assessment Practical steps

Assessment

Aproaches

Objectives

Beyond SAF'e V5.0's APMO

Current SAFe model adresses many issues by providing a flexible new function - the APMO but it does not address all issues LACE/APMO doe not yet address issues with Communities of practice not rolling out best practices efficiently


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". [4]

As Dean Leffingwell himself says in his 2010 book "Agile Software Requirements"[5] "Project Managers should be re-tasked as Agile Project Managers." This thought published before the release of SAFe appears to have taken some time to emerge in the SAFe framework

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 1.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.
  2. '[Dikert et al. 2016; Alsaqaf et al. 2019;Uludag et al ˘ . 2018].
  3. 3.0 3.1 3.2 https://www.scaledagileframework.com/about/
  4. https://medium.com/scaled-agile-framework/15-reasons-why-safe-is-essential-for-agile-teams-494ddd264518
  5. Dean Leffingwell, Agile Software Requirements, (Wesley, 2010),
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox