SAFe 4.0 in 5 minutes

This in an introduction to the Scaled Agile Framework or SAFe 4.0

[@Atozcareer]

Excellent video. Explained the core in few minutes. Lot of content but explained in the smooth way. I am very impressed.

[@theChrisCroft]

Release Train Engineer, Architectural Runway, Solution Architect, - great names, got to admire the creativity of the Agilists

[@bitesizelearning8219]

Amazing! Best video I have seen on the subject! SAFe in under 5 mins is a challenge that you met!!

[@alexanderm4851]

This is the best thing i have ever seen on Safe. thank you from people who learn by visualization.

[@TodayNight1]

Excellent Presentation. Keep up the good work. within 5 min , i am able to understand the SAFe Framework perfectly. Thanks.

[@prngoel]

Great summary video Inbar, it was really nice meeting you and learned SAFe directly from you.

[@MrNixxie]

Every time I hear Inbar talk, I have to think about our training! Great experience!

[@omerhatim4326]

Informative 👍 Thanks

[@saradhip70]

Very nice 👌

[@poojalele5113]

Great overview!

[@ZeljkoTrogrlic]

Short and easy to grasp. I could not find a good introduction on SAFe site, most materials are just b******t bingo. On the other hand, this video is very informative.

[@JerichoLeon]

Very good explanation but wish there were more text of the formal names used in the methodology.

[@kambizmotamedi4751]

This is a very nice and quick overview of 4.0. Thank you!

[@srk1108]

Great Job Inbar. You've summed it up nicely

[@victorchelladurai6405]

Very nice overview. Thank you!!

[@patrickbojko]

Great tour! very well done Inbar. Thanks

[@bharathyaragatti]

very crisply summarised..thanks

[@gurunathchoukekar]

Nice video. Good Knowledge in just 5 mins

[@andybacon522]

Awesome video, Inbar. Thanks for putting it together!

[@AlI-hg3xt]

Excellent summary. Thanks!

[@mattking530]

Good intro. Even with existing Agile knowledge, it's worth watch twice to pick up more nuances.I found myself cross-referencing terms (and related terms) in the ScaleAgileFramework online glossary to check all definitions correlate (hmm). Nb: Scaled Agile site included Value Sets within Portfolio level, not a level on it's own (however, the way this video describes them as 2 individual levels seems to make sense*). *I'm not sure if you can have multiple Portfolios, with discreet set of Value Sets each. Probably you'd just have one really big Portfolio per legal entity of such a huge Enterprise.

[@avijitsur]

Excellent video. I loved it.

[@khajster]

Very nice presentation. Thank you.

[@kavithakannan8492]

Great value delivered in a very short time, Thank you!

[@hotrockv]

Great video. Thanks for posting this video.

[@elkdavid6093]

Excellent video.

[@karimperdreau6854]

Nice Video, Good Knowledge, thanks a lot

[@kevinyao2031]

Great Video, very clear about SAFe, could you share your slides, I wanna use it as my training resource for my teams

[@gainonten4031]

create a post-it bonanza and you are certified!

[@MrSandertheman]

Question: what if one agile team lacks behind due to impediments and doesnt make the demo? What do the other teams do in the mean time? Or does the whole ART train come to a stop?

[@viko799]

The Scrum Master MUST remove all impediments to ensure the team's success. If they lag behind because of an impediment, then he gets the blame. Anyhow, Potentially Releasable Products must be demonstrated at the end (Potentially Releasable doesn't mean it's ready for the market yet, it's just a part of the whole) . Items which could not be delivered on the previous sprint are returned to the PBI for re-prioritization and subsequently included in the following sprint.

[@noahhildebrandt1298]

This is a ridiculous mindset. While a scrum master should do everything they can to remove whatever impediments they can, often those impediments fall beyond the scope of what they themselves can tackle (think legacy code issues) or don't have the time to in an iteration due to scope issues. The truth is, SAFe isn't agile, despite having "agile" in the name. Multiple teams with dependencies on each other isn't agile. Expecting regular releases from every team in a timebox isn't agile. The whole idea of planning 5 iterations ahead to meet a goal rather than iterating on the product as it needs to be iterated on isn't agile. So what actually happens when a team lags behind (and they will)? The management won't realize they've been sold waterfall in a different package and will do what they always do - blame the people that are actually putting value in their product.

[@askingalexandriaaa]

@@noahhildebrandt1298 totally agree

[@108danish]

Very Informative!

[@allysky3658]

Good Video Inbar looking to meet up at our SAFe training courses that we run in London at ALLYSKY.

[@carlosweinas]

So does SAFe 4.0 do away with the Hardening aspect in the 5th PI?

[@rhythmaraina2151]

Thankyou for this excellent video. I wanted to ask what should the PO do if the team informs the PO that they cannot finish committed 5 out of 10 user stories on the 7th day of the sprint? How does a PO expedite this risk?

[@BrendanMaunder]

The PO would talk with the RTE to assess the work over the entire release train backlog. This then allows them to decide on priorities of what all the teams have and make an educated decision on what action to take. Now having said that the teams commitment shouldn't be messed with unless there is a good reason.

[@MrAerospecial80]

Thank you!

[@Glorious_Yell0w]

Hi were are the art implemented in the process? Are the ART inside the PIs?

[@philmcgroin]

Phil McGroin

[@krishnavenimurugaraj5622]

Good video . thanks

[@askingalexandriaaa]

1 Second intro: Shitty Agile for Enterprises

[@WillSeele]

Nice video, but I do hope that at the end of the iteration, the team, including the product owner, demos and reviews the backlog with their stakeholder. Your video states the team demos to the PO, but that would be kind of pointless considering the stories and sprint goal already have been accepted during the sprint by the PO in order to have a valuable review session at the end with the customer.

[@Atozcareer]

PO acts as a customer for one team. That means, Team has to demo their deliverable to the customer (P.O) to ensure customer's acceptance. So it totally make sense the team demo's to PO ( virtual customer)

[@WillSeele]

The PO as customer representative already reviews and accepts items during the sprint to ensure value. The Sprint Review in Scrum is a collaborative session with stakeholders to align the team with them, through reviewing the impact the increment and changing market conditions have on the backlog priorities. You can't do this if the stakeholders aren't there or you're demoing an item for acceptance that should've already been accepted at that point. The PO as a customer representative is important during the sprint to provide feedback and information, but their goal is to ensure direct communication between the team and stakeholders in order for the team to maximize their value.

[@Atozcareer]

I think I understood your question better now. Yes PO receives the demo from team members during the sprint. As per SAFE, PO will demonstrate to all the stake holders including POs from cross teams, PMs, business stake holders. Some cases technical personnel from customer can also be included.

[@Atozcareer]

PO demo is at the end of sprint

[@WillSeele]

Exactly, so the team doesn't demo to the PO. Instead, the PO, together with the team, demo's and reviews to and with the team's stakeholders. (remember, we're after feedback on the backlog, not just showing what we did). Hence my initial feedback on the video.

[@wongssj]

Iaido and Jodo :D, also Kendo?

[@smile9439]

the iteration is not necessary 2 weeks

[@brazencycleworks]

I think you should remove the reference to working with Intel Corporation from your video. Intel is very protective of anyone promoting another business using their brand.

[@uieluck]

So basically; people working on stuff.

[@FudgeYeahLinusLAN]

Explained in one sentence: SAFE is when you want to deliver absolutely nothing of value and ruin your company.