Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

Is Leading SAFe® required before taking an Implementing SAFe® class?

A question that the training team and I are often asked is "do I need to have completed a Leading SAFe® class before taking an Implementing SAFe® class". It's so frequently asked in fact that we thought it was a worthy topic for discussion and have put together a short article to answer this burning question!

Read More

How do we use objectives in SAFe?

21-Apr-2020 09:15:00 SAFe SAFe 5.0

Lots of people that we work with struggle with Objectives regardless of their preferred delivery methodology or Framework. In this uncertain world we need to focus on outcomes more than outputs more than ever. The confusion can come from anywhere: too much detail, not enough detail, too many objectives.

Read More

What do I do if someone wants to change a Feature mid Program Increment?

14-Apr-2020 10:15:00 SAFe SAFe 5.0

What do I do if someone wants to change a Feature mid Program Increment?

This question gets asked all the time in my Implementing SAFe class because this will always happen in real life; this is not a theoretical question and as such we need to know how to deal with it. 

Read More

Who is the Product Owner for the System Team? - Part 3

02-Apr-2020 07:26:00 SAFe SAFe 5.0

In the final installment of articles looking at the role of the Product Owner and the System Team, we explore a common antipattern to watch out for and avoid, and closing thoughts with a quick win if you need to fill the role in a hurry. If you’ve missed the earlier versions, Part 1 that explored the System Team, the PO role and essential skills, and Part 2 which looked at where to find them and their development opportunities.

Read More

Who is the Product Owner for the System Team? - Part 2

31-Mar-2020 07:24:00 SAFe SAFe 5.0

Intro

In part 1 of the blog, we discussed what the System Team is, what a PO for the System Team does and the essential skills for this role in relation to the System Team. Now we turn our attention, where you might find the Product Owner for the System Team, and no matter where you find them, that there will be some personal development needed to maximise their potential. 

Read More

Increase predictability - Travelport Blog Part 1

Travelport have seen an increase of predictability in in their system very quickly with the introduction of agile.

Read More

We're expanding into Finland!

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.

Read More

The SAFe IP Iteration: It may be SAFe, but is it Agile? (Part 3)

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.

 

Coming back to the original objections


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.

Read More

The IP Iteration: It may be SAFe but is it Agile? (Part 2)

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:

 

1. Completion of work


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".

 

Read More

The IP Iteration: It may be SAFe but is it Agile? (Part 1)

"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.


The Plan Do Check Adjust/Act (PDCA) Cycle


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).

Read More