Where is the Project Manager in SAFe®? Is a question that I always get asked when delivering Implementing SAFe or indeed Leading SAFe; it is at this point I pause, sit down and have a discussion with the class.
The first question I ask is "Can someone define a Project for me?"
Answer: "It has a start and a finish i.e. it is a temporary organisation".
Increasingly we are moving from a project world to a product world in order to survive in the age of digital disruption; Mik Kersten’s book ‘Project to Product’ is a good read on the subject.
“The problem is that the principles of modern software delivery approaches are not translating to the business. Enterprises are still managing IT as a set of projects or a cost centre … these managerial frameworks are no longer sufficient to successfully direct and protect a business in the Age of Software”
SAFe creates long lived stable teams aligned around Value Streams. Value Streams are the end to end activities performed to deliver value to a customer through a product or service.
Therefore, it should come as no surprise that SAFe has Product Managers not Project Managers. Does that mean that we don’t need Project Management? NO! We still need to manage risks, issues, dependencies etc.
The skills and capabilities of existing Project and Program Managers are still required and relevant but applied in different roles and with a different behaviours. Before we look at the roles let’s explore the behaviour first.
There is a fundamental mindset change for Project or Program Managers from traditional leadership to being a Servant Leader.
Servant leadership is a leadership philosophy in which the main goal of the leader is to serve. A Servant Leader shares power, puts the needs of the employees first and helps people develop and perform as highly as possible. Servant leadership inverts the norm, which puts the employees as a main priority. Instead of the people working to serve the leader, the leader exists to serve the people.
Now let’s have a look at some of these roles:
Release Train Engineer (RTE)
The Release Train Engineer is a servant leader and coach for the Agile Release Train (ART).
The RTE’s major responsibilities are to facilitate the ART events and processes, and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement – sound familiar!
For more details about the responsibilities of a RTE have a look <here>
When I run my public SAFe RTE classes I always do a ‘hand-up’ poll. ‘How many of you that are already a RTE was previously a project or program manager?
90% of the hands go up. The remaining 10% are either Scrum Masters (see later), Development Managers and sometimes Business Analysts.
Scrum Masters are servant leaders and coaches for an Agile Team. They help educate the team in Scrum, Extreme Programming (XP), Kanban, and SAFe, ensuring that the agreed Agile process is being followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.
Again, for more details on a Scrum Masters responsibility click <here>
If I am honest, I have seen some Project Managers make great Scrum Masters but I have also seen some become really awful Scrum Masters as they are unable to make the mindset shift from project overload, centralised planning, work breakdown structures to demand management, continuous flow of value and agile estimating and planning.
Product Management is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle.
To do this, they collaborate with a wide range of people to identify and define customer needs, understand the Solution Context, and develop the Program Vision, Roadmap, and Features required to meet these needs.
The primary responsibilities of product management fall into four main areas:
- Meet business goals – Products and solutions must meet the economic business goals established by the portfolio
- Get it built – Product Managers collaborate with Agile Release Trains (ARTs) to build the required functionality
- Get it off the shelf – Internally, Product Managers collaborate with IT to ensure solutions are deployed to internal customers and users; externally, Product Managers collaborate with an even larger set of business stakeholders to deliver products to the market
- Leverage support – Product Managers ensure their offerings are supported and enhanced to create a continuous flow of value
So, this might feel more like a left field suggestion however I have known many Project and Program Managers that have a good understanding of the product or solution, how it meets the goals of the business and are very adept at leveraging support from key stakeholders. Project Managers transitioning to a Product Management role, is an option that should not be discounted.
Epic Owners are responsible for coordinating portfolio Epics through the Portfolio Kanban system. They collaboratively define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved, facilitate implementation.
Until recently I would have never thought of this as an option but a conversation with Mark Richards (SAFe Fellow) made me reconsider.
The Epic Owner in SAFe is a role assumed by an individual; it is not a job title.
Preparing the Epic - The Epic Owner’s responsibilities begin early in the epic’s life cycle. They include:
- Working with stakeholders and subject matter experts to define an epic using the ‘epic hypothesis statement’
- Working with development teams to size the epic and provide input for economic prioritization based on Weighted Shortest Job First (WSJF), the Lean business case, and other relevant factors
- Shepherding epics through the portfolio Kanban system and creating the Lean business case
- Preparing to present the Lean business case to LPM for a go/no-go decision
Presenting the Epic - The Epic Owner has the primary responsibility for introducing the merits of the epic to Lean Portfolio Management
If the Epic is approved then the Epic Owner will follow through with implementation and may follow the epic downstream through the continuous delivery pipeline and release on demand.
Epic Owner is an ideal activity for Project or Program Manager that has worked at a Portfolio Level.
Not quite a ‘do nothing’ option but if your organisation is moving down a product transformation and away from project delivery and you still want to run projects or programs then I am sure there are still other organisations that will value your skills for now.
However a final warning from Mik Kersten:
“The winners and losers of the Age of Software will have gained enough market share that those applying management techniques of a previous age will find it difficult or impossible to catch up.”