How do we handle Scope Changes in a SAFe Program Increment?
A question about handling scope changes in SAFe was posed recently on a forum I’m participating in (The SAFe Community Forum). This is a question posed regularly in training and on ARTs I’m coaching so I thought I’d provide my thoughts here.
Comparing Nexus and SAFe – Similarities, Differences, Ideas.
I’ve been asked several times now about Nexus and SAFe – what are the similarities, differences, etc. If you’re not familiar with either Nexus or SAFe I recommend taking a look at the Nexus Guide and the SAFe whitepaper first.
After more than 20 years working in the software industry, 10 of which coaching engineering organizations on their Agile and DevOps journey, Yael Rabinovich, a SAFe (Scaled Agile Framework) Program Consultant and Partner at AgileSparks, will share her experience and present a number of ways that accelerate value delivery at scale. While these ways may look simple at first, they are not easy to implement. Yael will discuss challenges organizations face and the way to overcome them while sharing stories and case studies from international organizations such as Intel, Alcatel Lucent, Motorola and more.
Learning from the SAFe Program Dependency Board
The SAFe Program Board or Program Dependency Board is a key artifact used in PI Planning and Execution. The ART Teams and Stakeholders used it to align, anticipate risks, and adapt the plan accordingly.
This “inspection and adaptation” of the plan based on insights from the Program Dependency Board is “first loop learning” – making changes in the plan based on what we see.
SAFe™ (The Scaled Agile Framework) uses Story Points throughout the various levels as its estimation currency. This is covered in the “Story” article on the SAFe site. This is a pretty standard practice in organizations scaling agile these days. If you dive a bit deeper into how this is done in SAFe you will see that actually the story points used in SAFe are quite similar to “Ideal Developer Day” as this helps the teams align to a common baseline and support a rational economic ROI discussion at the level of Features/Capabilities that require effort from more than one team or haven’t even been mapped to a specific team yet.
The Premise
A year ago Scrum.org, in collaboration with Daniel Vacanti and myself, published the Kanban Guide For Scrum Teams, a guide that is aimed at helping Scrum Teams take advantage of Kanban/Flow principles and practices. (I wrote an earlier blog post about understanding the guide)
SAFe™ has included Kanban at all levels since version 4.0. Some basic guidance about Kanban is included in most if not all SAFe curriculums. Can a SAFe practitioner learn anything from the Kanban Guide For Scrum Teams?
In this blog post, I’ll explore some of the flow metrics from the guide with an emphasis on those that aren’t covered in SAFe.
In the last couple of years, I’ve been writing about SAFe on the AgileSparks Blog, providing guidance articles for the SAI, and creating some complementary approaches and services in the SAFe context. All are based on experiences in the trenches helping AgileSparks clients achieve agility at scale. I recently completed a curated collection of some of my favorites and started to provide copies of this book to participants of my Implementing SAFe and RTE classes.
SAFe includes Scrum – so how come many Scrum practitioners and thought leaders consider it unsafe?
The Scaled Agile Framework (SAFe™) is one of the most popular approaches to applying agile at scale out there. SAFe’s perspective is that “Nothing beats an Agile Team” and it doesn’t try to reinvent the wheel or even innovate too much when it comes to the Team level. It takes advantage of established frameworks and techniques that work well – Scrum being the first and foremost of those.
We’ve all heard it before – “Talented technology team builds amazing product!” That… doesn’t create the impact that they wanted, not enough customers end up buying or the users aren’t happy with it or
This is an especially common problem with companies that have a “brilliant” idea or technology that someone goes developing in their garage (if startup) / innovation product development group (if enterprise). This could be a new product or just a new feature of an existing product. Typically, the Product Owner or Product Manager in the organization specifies what to build. If they’re somewhat Agile, they even work closely with the organization to build it incrementally and hopefully deliver it continuously. But still, even then, too often the product or features don’t provide the expected impact/benefits. Overcoming this challenge is a common theme that is discussed by attendees at our SAFe POPM Course.
Actual is a relative term when it comes to business value delivered by a SAFe PI Objective. We had a discussion about this a couple of weeks ago in an Implementing SAFe class and I promised a blog post about this. Here it goes.
Planned Business Value – Making sure Business Owners and the Agile Team are on the same page
Let’s start from the basics though. PI (Program Increment) Objectives are used as a “back briefing” mechanism by Agile Teams on an Agile Release Train to share their plan for the PI and validate that they are indeed focusing on the highest priorities and are planning to deliver objectives that will be valuable for the business.
Request for additional information and prices
