Latest information from Radtac
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.
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.
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.
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.
Identifying the Product Owner for the System Team can sometimes be not as straightforward as it can be for other teams in Agile Release Trains (ART). Here we explore what you need to consider to make this a successful role. This is the first of a series of three articles that explores the role of the Product Owner in relation to the System Team and their essential skills. In the later articles, we will explore where you might find candidates for the role and how to plan their personal development to excel, followed by antipatterns to be aware of and some quick wins.
Travelport have seen an increase of predictability in in their system very quickly with the introduction of agile.
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.
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.
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".