During every Implementing SAFe class, I create a reading list of the books and white papers that I reference in addition to the various videos that I show throughout the course; it’s quite a list. But then someone ask what would be you Top 3 if you have to prioritise – well that’s like asking which is your favourite child!
During every Implementing SAFe class, I create a reading list of the books and white papers that I reference in addition to the various videos that I show throughout the course; it’s quite a list. But then someone ask what would be you Top 3 if you have to prioritise – well that’s like asking which is your favourite child!
During every Implementing SAFe class, I create a reading list of the books and white papers that I reference in addition to the various videos that I show throughout the course; it’s quite a list. But then someone ask what would be you Top 3 if you have to prioritise – well that’s like asking which is your favourite child!
Either way here goes! So, in a series of 3 blogs let’s start with my top 3 SAFe Books!
Understanding the SAFe model for simple and more complex implementations
Do I need to have completed a Leading SAFe® class before taking an Implementing SAFe® class
This is a question that gets frequently asked and is worthy of a quick article to answer not only for now but for future enquires too 😀
In the first instance, let’s look at the Scaled Agile, Inc pre-requisites:
“All stakeholders in a Lean-Agile transformation are welcome to attend the course, regardless of experience.
However, the following prerequisites are highly recommended for those who intend to take the SAFe® 4 Program Consultant exam and practice as a Certified SAFe® 4 Program Consultant (SPC):
So, you can see that Leading SAFe® is not a pre-requisite to attending an Implementing SAFe® class. In fact, when I took my Implementing SAFe® class I had not previously attended a Leading SAFe® class.
In addition, I tend to find only about a third of Implementing SAFe® class delegates have attended a Leading SAFe® course.
What is more important is that you do have a background and experience in Agile because the Scaled Agile Framework is based on this body of work.
However, there is a BUT!
*This post is part of the series ‘SAFe Practice Tips’, which aims to offer helpful advice to anyone using SAFe.
Here is the final part of the SAFe PI Planning Tips series where I discuss the Planning Retrospective. This is the final activity of the Program Increment (PI) Planning event. If you haven’t checked out our previous Tips of the SAFe Practice series you can check them out here: Part 1 and Part 2
“The RTE leads a brief retrospective for the PI planning event to capture what went well, what didn’t, and what can be done better next time.” - Scaled Agile Framework
My experience with the PI is that, whilst energising and exhilarating, it also exhausting! By the time you get to the final confidence vote, people are ‘done’! They just want to get home.
*This post is part of the series ‘SAFe Practice Tips’, which aims to offer helpful advice to anyone using SAFe.
Here is the 2nd part of the SAFe® Practice Tips series, where I discuss Management Problem Solving, including thoughts from other SAFe practitioners. Also, I explain confidence voting and how the team can do this to help meet their objectives for the PI. If you haven’t checked out the previous parts of the series - read Tip 1 here and Tip 2 here.
As mentioned last time, PI Planning is essential to SAFe. If you are not doing PI Planning, you are not doing SAFe. These tips will enable you to do your PI planning in a better way.
*This post is part of the series ‘SAFe Practice Tips’, which aims to offer helpful advice to anyone using SAFe.
As a SAFe® Program Consultant Trainer (SPCT) I can’t remember how many PI Planning events I facilitated and attended last year. However, what I do know is that this is a seminal event in SAFe, which aims to create alignment with the Teams, the Product Management, the Architects and Business Owners.
“Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision.”
PI Planning is essential to SAFe - If you are not doing PI Planning, you are not doing SAFe.
Over the last 2 years, I have been experimenting with different techniques and practices which I thought I would share with you. The first one is regarding Business Context and Team Space
As a SAFe® Program Consultant Trainer, I have launched many Agile Release Trains (ARTs) over the last two years in a variety of industries and countries. Every time, I look to try something new (an experiment) to see whether there is a better way of doing things.
So, through a series of blogs I am going to share some of those experiments that I have found really useful. Perhaps try them out for yourself and let me know how you get on.
Let’s start by looking at the Inspect and Adapt workshop which, after the PI Planning, is probably the most important event; it is where we remember Principle #12 from the Agile Manifesto:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
Darren Wilmshurst and Radtac had the great chance to run a Q&A session with Dean Leffingwell, creator of the Scaled Agile Framework. Dean’s answers on SAFe updates, implementation advice, challenges, and more are captured in a series of blog posts and short videos.
In the first video of the series, Deans answers questions on the future of the Scaled Agile Framework, and in the second episode Dean talks about the major impediments to implementing SAFe and the Leadership Challenge. In the third episode Darren and Dean talk about projects, project managers, Scrum and Kanban in SAFe environments.
This is the fourth and final part of the series - view the first part here, the second part here, and the third part here.
***
In this fourth and final episode of our ‘10 Questions with Dean Leffingwell’ series, I’m talking to Dean about the appropriateness of using Agile and SAFe for legacy developments, compared to green field developments.
