safe 5 Certified SAFe 5 Agilist 1.0.0

SAFe 5.0 can be previewed on a preview section of the Scaled Agile For Enterprise website. The suggested changes takes several steps forward towards a lean organization type of frame work. With that comes challenges for companies who see SAFe as a development framework and not an organization one. Will this make it easier or harder to have organizations adapt to SAFe?
In SAFe for Lean Enterprises 5.0 comes with two new competencies and updated to five competencies. It also pushes pretty hard towards the business side with new business agility and SAFe for business teams. The biggest change is probably the merge of the teams level and the program level into one single level called Essential. While it is good to involve business more and I agree with the arguments for merging team and program levels I fear that this will make SAFe less attractive. That is because now it require a complete transformation of the company, while before you could have it living along side other frameworks.
 

 
New Focus on Business Agility
"Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative business solutions. It requires that everyone involved in delivering solutions—business and technology leaders, development, IT operations, legal, marketing, finance, support, compliance, security, and others—use Lean and Agile practices to continually deliver innovative, high-quality products and services faster than the competition."
This sounds amazing, but I would say that less than 1% of all enterprise companies are even close to having a lean approach to their organization. Almost all companies have some areas, but as a whole I would say almost every enterprise company still have a waterfall and project based approach to their organization.

 
Continuous Learning Culture New
"The Continuous Learning Culture competency describes a set of values and practices that encourage individuals—and the enterprise as a whole—to continually increase knowledge, competence, performance, and innovation. This culture is achieved by becoming a learning organization, committing to relentless improvement, and promoting a culture of innovation."
This is where I think many organizations dedicated to implement SAFe will get uncomfortable. Continuous learning cost a lot of money. We are talking several millions a year and a dedicated workforce for coaching and educating the organization. In most of the companies I have see this is very uncommon. Most if the time there is a small central team and then a multitude of initiatives throughout the organization that is not very structured or large enough to support everyone.
I would love to see this implemented, but the cost for it will surely give a lot of resistance.

 
Organizational Agility New
"The Organizational Agility competency describes how Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities."
This makes sense, unless you consider that most enterprise companies are not Lean-thinking in their mindset and the sheer complexity of their operations makes Lean-thinking difficult. Again most companies still struggle with Agile where it mostly become an Ad-hoc stress trap due to poor adaptation and support.
Again this require a huge commitment with an almost total organization transformation. The cost alone is monumental and the effort to move your entire organization, as well as changing the tool set, towards this goal makes it a big obstacle towards a SAFe implementation for many companies. If they can afford the cost and can see the change management through however this would be very interesting indeed. I know of no company today that works this way on an organization level and I am not sure it is even possible at an enterprise company.

 
Team and Technical Agility Restructured
"The Team and Technical Agility competency describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and Teams of Agile teams use to create high-quality solutions for their customers. The result is increased productivity, better quality, faster time-to-market, and predictable delivery of value."
This description has been updated, but unfortunately it still does not define teams as product based. It also does not give any focus towards work satisfaction or team health, which is important factors to consider as some teams should not use an Agile methodology as it is damaging to their health. Not really much news here other than some updates to to the merge of team and program level.

 
Agile Product Delivery   Restructured
"The Agile Product Delivery competency is a customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users. This competency enables the organization to provide solutions that delight customers, lower development costs, reduce risk, and outmaneuver the competition. The DevOps and Release on Demand competency has been renamed to Agile Product Delivery."
Again not much news here. Some additional emphasis on customer centric design thinking, which is a bit amusing as most organizations are very far from customer centric in general and still very new to the concept of design thinking. Hopefully this will increase the demand for UX and CRO as user testing and A/B testing is a rather rare occurrence in today's enterprises. On the DevOps side I still do not see this working, even after 10 years of "implementation" on many organizations. In fact the trend is to separate dev and ops more than uniting them...

 
Lean Portfolio Management   Restructured
"The Lean Portfolio Management competency aligns strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance. These collaborations give the enterprise the ability to align strategy to execution, to meet existing commitments reliably, and to better enable innovation."
This is the one thing I wish every enterprise organization would focus on right now. In to many organizations there are barely any strategic portfolios and contracts are all written as fixed price engagements that kill any chance of agility. There are few, if any, enterprise architects and overall the structure and control on portfolio levels are pretty bad. Not much news here, but an improved description and a slight alignment towards organization agility.

 
Enterprise Solution Delivery   Restructured
"The Enterprise Solution Delivery competency describes how to apply Lean-Agile principles and practices to the specification, development, deployment, operation, and evolution of the world’s largest and most sophisticated software applications, networks, and cyber-physical systems. The Business Solutions and Lean Systems Engineering competency has been renamed to Agile Product Delivery"
This section has been rewritten and again aligned a bit with the merge of teams and program. It still promote a microservices solution and continuous deliver system that is not really aligned with the complexity of large scale system development with multiple teams of different cadence. Despite that this is a good section with many good descriptions that would make life easier if followed.

 
 
Lean-Agile Leadership  Restructured
"The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain organizational change by empowering individuals and teams to reach their highest potential. They do this through leading by example, adopting a Lean-Agile mindset, and lead the change to a new way of working. The result is more engaged employees, increased productivity and innovation, and successful organizational change."
This section is updated and rewritten a bit. The SAFe implementation roadmap has been updated a bit as well with 2 new courses. One for Lean Portfolio Management and one for Agile Product and Solution Management (APSM)

 
Overall these are good changes, but I fear that the extent of the new changes can make organizations feel that SAFe is becoming increasingly difficult to implement. On the other hand it can also be the leverage certain part of the organization need to push the change that they see is necessary. It also makes it more attractive from a strategic perspective to have a framework that will actually transform all aspects of the organization.
So there are some good things and some, potentially, bad things in SAFe 5.0.
I like it, how about you?
 

View full blog article

SAFe 5.0 can be previewed on a preview section of the Scaled Agile For Enterprise website. The suggested changes takes several steps forward towards a lean organization type of frame work. With that comes challenges for companies who see SAFe as a development framework and not an organization one. Will this make it easier or harder to have organizations adapt to SAFe?
In SAFe for Lean Enterprises 5.0 comes with two new competencies and updated to five competencies. It also pushes pretty hard towards the business side with new business agility and SAFe for business teams. The biggest change is probably the merge of the teams level and the program level into one single level called Essential. While it is good to involve business more and I agree with the arguments for merging team and program levels I fear that this will make SAFe less attractive. That is because now it require a complete transformation of the company, while before you could have it living along side other frameworks.
 

 
New Focus on Business Agility
"Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative business solutions. It requires that everyone involved in delivering solutions—business and technology leaders, development, IT operations, legal, marketing, finance, support, compliance, security, and others—use Lean and Agile practices to continually deliver innovative, high-quality products and services faster than the competition."
This sounds amazing, but I would say that less than 1% of all enterprise companies are even close to having a lean approach to their organization. Almost all companies have some areas, but as a whole I would say almost every enterprise company still have a waterfall and project based approach to their organization.

 
Continuous Learning Culture New
"The Continuous Learning Culture competency describes a set of values and practices that encourage individuals—and the enterprise as a whole—to continually increase knowledge, competence, performance, and innovation. This culture is achieved by becoming a learning organization, committing to relentless improvement, and promoting a culture of innovation."
This is where I think many organizations dedicated to implement SAFe will get uncomfortable. Continuous learning cost a lot of money. We are talking several millions a year and a dedicated workforce for coaching and educating the organization. In most of the companies I have see this is very uncommon. Most if the time there is a small central team and then a multitude of initiatives throughout the organization that is not very structured or large enough to support everyone.
I would love to see this implemented, but the cost for it will surely give a lot of resistance.

 
Organizational Agility New
"The Organizational Agility competency describes how Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities."
This makes sense, unless you consider that most enterprise companies are not Lean-thinking in their mindset and the sheer complexity of their operations makes Lean-thinking difficult. Again most companies still struggle with Agile where it mostly become an Ad-hoc stress trap due to poor adaptation and support.
Again this require a huge commitment with an almost total organization transformation. The cost alone is monumental and the effort to move your entire organization, as well as changing the tool set, towards this goal makes it a big obstacle towards a SAFe implementation for many companies. If they can afford the cost and can see the change management through however this would be very interesting indeed. I know of no company today that works this way on an organization level and I am not sure it is even possible at an enterprise company.

 
Team and Technical Agility Restructured
"The Team and Technical Agility competency describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and Teams of Agile teams use to create high-quality solutions for their customers. The result is increased productivity, better quality, faster time-to-market, and predictable delivery of value."
This description has been updated, but unfortunately it still does not define teams as product based. It also does not give any focus towards work satisfaction or team health, which is important factors to consider as some teams should not use an Agile methodology as it is damaging to their health. Not really much news here other than some updates to to the merge of team and program level.

 
Agile Product Delivery   Restructured
"The Agile Product Delivery competency is a customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users. This competency enables the organization to provide solutions that delight customers, lower development costs, reduce risk, and outmaneuver the competition. The DevOps and Release on Demand competency has been renamed to Agile Product Delivery."
Again not much news here. Some additional emphasis on customer centric design thinking, which is a bit amusing as most organizations are very far from customer centric in general and still very new to the concept of design thinking. Hopefully this will increase the demand for UX and CRO as user testing and A/B testing is a rather rare occurrence in today's enterprises. On the DevOps side I still do not see this working, even after 10 years of "implementation" on many organizations. In fact the trend is to separate dev and ops more than uniting them...

 
Lean Portfolio Management   Restructured
"The Lean Portfolio Management competency aligns strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance. These collaborations give the enterprise the ability to align strategy to execution, to meet existing commitments reliably, and to better enable innovation."
This is the one thing I wish every enterprise organization would focus on right now. In to many organizations there are barely any strategic portfolios and contracts are all written as fixed price engagements that kill any chance of agility. There are few, if any, enterprise architects and overall the structure and control on portfolio levels are pretty bad. Not much news here, but an improved description and a slight alignment towards organization agility.

 
Enterprise Solution Delivery   Restructured
"The Enterprise Solution Delivery competency describes how to apply Lean-Agile principles and practices to the specification, development, deployment, operation, and evolution of the world’s largest and most sophisticated software applications, networks, and cyber-physical systems. The Business Solutions and Lean Systems Engineering competency has been renamed to Agile Product Delivery"
This section has been rewritten and again aligned a bit with the merge of teams and program. It still promote a microservices solution and continuous deliver system that is not really aligned with the complexity of large scale system development with multiple teams of different cadence. Despite that this is a good section with many good descriptions that would make life easier if followed.

 
 
Lean-Agile Leadership  Restructured
"The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain organizational change by empowering individuals and teams to reach their highest potential. They do this through leading by example, adopting a Lean-Agile mindset, and lead the change to a new way of working. The result is more engaged employees, increased productivity and innovation, and successful organizational change."
This section is updated and rewritten a bit. The SAFe implementation roadmap has been updated a bit as well with 2 new courses. One for Lean Portfolio Management and one for Agile Product and Solution Management (APSM)

 
Overall these are good changes, but I fear that the extent of the new changes can make organizations feel that SAFe is becoming increasingly difficult to implement. On the other hand it can also be the leverage certain part of the organization need to push the change that they see is necessary. It also makes it more attractive from a strategic perspective to have a framework that will actually transform all aspects of the organization.
So there are some good things and some, potentially, bad things in SAFe 5.0.
I like it, how about you?
 

Regardless if you work in a continuous delivery flow like Kanban, a sequential delivery flow like waterfall or an iterative delivery flow like Scrum, you will benefit greatly from having portfolio management. Having a dedicated funnel ensures that you get a proper overlook of your incoming request. In this article we will discuss how that can be done by creating a process for it in Jira Software.
Advanced Roadmaps is a very useful tool because it allows us to get the big picture. It also allows us to scale the hierarchies in Jira for issue types. This is important because the standard hierarchies are designed for teams, so they do not scale well. While you can work around this using the sideways approach where you have the higher hierarchies in a separate project and link between them, that is not really a hierarchy. This also works poorly when you wish to display things in Advanced Roadmap.
The first thing we need to do for a proper hierarchy view in Advanced Roadmaps is to define the portfolio levels. We need to accommodate for multiple scenarios as requests, or demands, often come in different forms. The most common types are projects or even programs, or new features. We also want to make sure we can work with the different frameworks out there, so we add a collaboration level as well as defined in SAFe.
To avoid a lot of confusion between different frameworks and other tools, we rename the Epic issue type in Jira Software to Feature. It will not be perfect, but it will have to do until we get the ability to rename it properly when Atlassian makes that change in the future.  We do this by going to Issues -> Issue Types and edit the Epic issue type. We also add two new issue types for Initiative and Capability.
Next we go to Plans -> Settings -> Advanced Roadmaps hierarchy configuration. There we add two new levels called Initiative and Capability and map them with our newly created issue types with the same names. Finally, we rename the Epic to Feature, and we should have our first hierarchy defined. We can go back and adjust this later if we want. The setup should now look like this:

We can now add this to our projects by adding the issue types to our Issue Type Schemas. Depending on your setup you may want the new issue types for Initiative and Capability to exist in a separate Issue Type Schema, or you will add them to the standard schema. Either way we still need to give the new issue type a workflow that match their purpose. So we head over to Issues -> Workflows and create a new workflow.
Again we want to consider what the purpose of these issue types is and who will actually work with them. Initiative, Capability and Feature are all used by management and requirement analysts to provide information on how to realize demands. That means that we do not have the same transfer of responsibility as for User Stories. Instead, we need to consider what we actually do in the portfolio and what we need to track in terms of activities.
SAFe have a pretty good example of this for their Portfolio Kanban. Their first step is Funnel and for us that is pretty much everything that comes into our workflow, and we define this as new. Anything that comes in to the portfolio needs to be reviewed to see what we should focus on next. Since we will not review everything we add two steps for the review process: Ready for Review and In Review. This allows us to only pick things that we want to review by moving them from new to Ready for Review, and then we have an active status to indicate that we are working on this.
We do the same for Analysis, which is the step where we involve Business Analysts and Requirement Analysts to define the need in more detail. For this we add Ready for Analysis for when the Review process lead to us spending time to break down the need in a requirement process. We also add the In Analysis to indicate that it has entered the Requirement process.
Before we close this workflow we add the Implementation process as well. Ready for Implementation indicate that the requirement process has led to a decision to implement and In Implementation indicate that the need is being fulfilled. We do not fracture this further as we can easily drill down to individual tasks in Advanced Roadmaps, and it is not really useful to have for example test and release part of this workflow. That is because each issue type will have many issue types below it, and you can only transition on the last sub-task, making it misleading and feeling stagnant.
Finally, we add a status for Blocked/Pending to allow us to track when things are preventing this activity from being fulfilled. This can be external or internal dependencies or financial reasons for example.
As always we go for an open workflow to allow for free transitions. We add a close screen to the Close status to set a resolution and then add a post function to remove resolution on all other statuses. This workflow should now look like this:

The final step is now to go to our workflow scheme and add this new workflow. We do this by going to Issues -> Workflow Schemes and click edit on the workflows scheme we have Initiative, Capability and Feature added to. We click add Workflow and add the new workflow we just created. Then we select that this workflow will be applied to Initiative, Capability and Feature before hitting save.
This should now allow you to work inside Advanced Roadmaps using Initiatives, Capabilities and Features in a proper portfolio management process that allow for larger projects and programs as well as manage smaller feature or even user stories.
I hope you found this useful and as always, if you have any questions just write a comment and I will do my best to help you.

Regardless if you work in a continuous delivery flow like Kanban, a sequential delivery flow like waterfall or an iterative delivery flow like Scrum, you will benefit greatly from having portfolio management. Having a dedicated funnel ensures that you get a proper overlook of your incoming request. In this article we will discuss how that can be done by creating a process for it in Jira Software.
Advanced Roadmaps is a very useful tool because it allows us to get the big picture. It also allows us to scale the hierarchies in Jira for issue types. This is important because the standard hierarchies are designed for teams, so they do not scale well. While you can work around this using the sideways approach where you have the higher hierarchies in a separate project and link between them, that is not really a hierarchy. This also works poorly when you wish to display things in Advanced Roadmap.
The first thing we need to do for a proper hierarchy view in Advanced Roadmaps is to define the portfolio levels. We need to accommodate for multiple scenarios as requests, or demands, often come in different forms. The most common types are projects or even programs, or new features. We also want to make sure we can work with the different frameworks out there, so we add a collaboration level as well as defined in SAFe.
To avoid a lot of confusion between different frameworks and other tools, we rename the Epic issue type in Jira Software to Feature. It will not be perfect, but it will have to do until we get the ability to rename it properly when Atlassian makes that change in the future.  We do this by going to Issues -> Issue Types and edit the Epic issue type. We also add two new issue types for Initiative and Capability.
Next we go to Plans -> Settings -> Advanced Roadmaps hierarchy configuration. There we add two new levels called Initiative and Capability and map them with our newly created issue types with the same names. Finally, we rename the Epic to Feature, and we should have our first hierarchy defined. We can go back and adjust this later if we want. The setup should now look like this:

We can now add this to our projects by adding the issue types to our Issue Type Schemas. Depending on your setup you may want the new issue types for Initiative and Capability to exist in a separate Issue Type Schema, or you will add them to the standard schema. Either way we still need to give the new issue type a workflow that match their purpose. So we head over to Issues -> Workflows and create a new workflow.
Again we want to consider what the purpose of these issue types is and who will actually work with them. Initiative, Capability and Feature are all used by management and requirement analysts to provide information on how to realize demands. That means that we do not have the same transfer of responsibility as for User Stories. Instead, we need to consider what we actually do in the portfolio and what we need to track in terms of activities.
SAFe have a pretty good example of this for their Portfolio Kanban. Their first step is Funnel and for us that is pretty much everything that comes into our workflow, and we define this as new. Anything that comes in to the portfolio needs to be reviewed to see what we should focus on next. Since we will not review everything we add two steps for the review process: Ready for Review and In Review. This allows us to only pick things that we want to review by moving them from new to Ready for Review, and then we have an active status to indicate that we are working on this.
We do the same for Analysis, which is the step where we involve Business Analysts and Requirement Analysts to define the need in more detail. For this we add Ready for Analysis for when the Review process lead to us spending time to break down the need in a requirement process. We also add the In Analysis to indicate that it has entered the Requirement process.
Before we close this workflow we add the Implementation process as well. Ready for Implementation indicate that the requirement process has led to a decision to implement and In Implementation indicate that the need is being fulfilled. We do not fracture this further as we can easily drill down to individual tasks in Advanced Roadmaps, and it is not really useful to have for example test and release part of this workflow. That is because each issue type will have many issue types below it, and you can only transition on the last sub-task, making it misleading and feeling stagnant.
Finally, we add a status for Blocked/Pending to allow us to track when things are preventing this activity from being fulfilled. This can be external or internal dependencies or financial reasons for example.
As always we go for an open workflow to allow for free transitions. We add a close screen to the Close status to set a resolution and then add a post function to remove resolution on all other statuses. This workflow should now look like this:

The final step is now to go to our workflow scheme and add this new workflow. We do this by going to Issues -> Workflow Schemes and click edit on the workflows scheme we have Initiative, Capability and Feature added to. We click add Workflow and add the new workflow we just created. Then we select that this workflow will be applied to Initiative, Capability and Feature before hitting save.
This should now allow you to work inside Advanced Roadmaps using Initiatives, Capabilities and Features in a proper portfolio management process that allow for larger projects and programs as well as manage smaller feature or even user stories.
I hope you found this useful and as always, if you have any questions just write a comment and I will do my best to help you.

View full blog article

IREB certified requirements analyst with a passion for processes.