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!
Great news is worth sharing quick, which is why we’re very excited to tell you what we’ve been working on lately: we’re opening a new Radtac location in Finland! The Finland hub is joining our global network, enabling us to further support our Nordics and European customers. Please join us in saying Hei Suomi! [Hi Finland!]
At Radtac, everything we do revolves around our passion to help organisations become more responsive, and we do this through enabling them to adopt, embed and evolve Agile ways of working.
Over the years, we have worked with you, our customers, to support you on your Agile journeys. We’ve been all over the world with you - from Silicon Valley, to New York, Zürich, Berlin, Copenhagen, Helsinki, Amsterdam, Kigali, Dubai, Delhi, Beijing, Singapore - you name it. And while we love travelling, having local hubs close to our customers enables us to support you even better. This is why we’re so excited about the latest Radtac hub in Finland.
What makes consumers decide to buy your product or service over your competitors? How can you be sure that your services are still aligned to the needs of your end-users? Making time for human-centred design and innovation is essential to stay ahead of the curve and win out against your competition.
Agile alone is not enough! Yes of course creating an environment in which teams can work in shorter cycles to deliver a working product more frequently, incorporate fast feedback loops and adapt to changing conditions will inevitably lead to building the ‘thing right’ but are your teams building the ‘right thing’?
The old adage ‘put yourself in your customer’s shoes’ rings as true in the twenty first century as it did when it was first coined. In today’s intensely competitive, rapidly shifting markets, it’s crucial to have a human-centred mindset from the get go and throughout the product lifecycle. The key is to tie together two imperatives: the ‘desirability factor’ and ‘baking in time for innovation’.
This is the last part in the 'SAFe® IP Iteration' series. Read part one here and part two here if you missed them. In part three, Tom goes back to address the original objections to whether the IP Iteration is Agile.
Let's go back to our original objections and deal with them now that we understand why SAFe is constructed the way that it is.
"But this just isn't Agile! Why can't we just keep Sprinting?".
Some people really dislike the "break" from the cycle of Sprints and view the IP Iteration as an ineffective tradeoff that isn't needed because all of the above activities can be worked into each Sprint for each team. This is essentially the single-team Scrum view that life should be an endless series of Sprints.
The normal response to this is to point out that there's a bigger programme picture, that the team is part of a team-of-teams and time needs to be spent on those activities, and that all of this rests on the same PDCA principles that underpin Scrum.
This is the second part in a blog series talking about the IP Iteration that happens as part of the Scaled Agile Framework® (SAFe®). Missed the first part? Read it here.
What's the typical structure of an IP Iteration and why is it like this?
SAFe marks the boundaries of its PIs (Program Increments) through the IP Iteration. This is normally a two-week period during which the following activities are scheduled:
There is some contingency allowed in case that teams are very close to finishing their work in the current PI and can finish. The official guidance is up to one week, in practice less is desirable or this becomes a "buffer" teams will depend on.
There is also an allowance here for release activities - these will depend on whether major releases are aligned with PIs or not (a business decision, not required by SAFe) and the nature of the major release process: whether it is complicated and time-consuming or a simple "button-push".
"But this just isn't Agile! Why can't we just keep Sprinting?".
"We don't have time for this, we've got too much work to do!".
"Planning together is worthless because everything changes soon afterwards."
"It is boring and a waste of my time, I'm here to write code".
These are just some of the things we regularly hear from clients who are learning the Scaled Agile Framework® (SAFe®). The part of SAFe they seem to struggle with most is the IP Iteration (sometimes called the 'bridge') that handles the switch between two adjacent PIs (Program Increments). This is probably the most misunderstood part of SAFe and the one that is abused the most in practice.
Let's start by unpicking why SAFe works like this - because there are good reasons that cannot be trivially dismissed.
First of all, most Agile methods are based on the PDCA cycle. (Note that there are alternatives to PDCA such as John Seddon's Check-Plan-Do. However they are all ultimately variations on the same activities, just with different emphasis.)
PDCA is a basic improvement cycle that can be applied individually, to a team, to a programme or a wider organisation.
Planning - planning work/activity to do.
Doing - doing the work/activity.
Check - evaluating how we did.
Adjust(/Act) - improvement actions to get a better result next time.
Sports work like this. Before the game, we plantactics and strategy. Then we play the game (do). After the game, we review our performance: what went well and badly and why (check). Finally, we take learnings from this review and work to improve for future games (adjust/act).
This is a guest blog from Phil Dexter, Senior Project Manager at Torchbox. Phil recently attended one of our ICAgile courses where he got inspiration for this blog post. You can find Phil’s original article here.
Great coaching leads to great performance.
I’ve been reflecting on the role of coaches and their influence - both in sport, and at work. Specifically, I’ve been considering the difference between coaching and teaching - something focused on at an Agile Coaching course that I recently attended.
As per the course definition, teaching is explaining something to someone. It is the natural reaction that all of us have - someone asks us a question and we give them an answer. Perhaps we go the extra mile, and teach them - “here’s the answer, and here’s how I got to it”. The problem is solved and the knowledge passed on… kind of.
