Scrum@Scale in under 15min

[@scottf9044]

The fact that you can say Scrum of Scrum of Scrums without laughing is quite a testament.

[@corymiglis]

The video is done and I am still laughing at that part... I couldn't focus on the rest of the video. lol

[@RC-vu7ru]

This an excellent video on S@S, comprehensive yet concise. Kudos to Renee for this work, it is not an easy feat!

[@jamesoliver8261]

cant get my head around the Scrum of Scrum of Scrums. Scrum of Scrum of Scrum Scrum Master is a hell of a job title

[@bhart89]

At the 5 min mark I had to check to see if this was a parody video or not.

[@zenrobotninja]

@@bhart89 lol me too. I stopped to check

[@juancarlosabad3298]

it is or should not be a job title but a role.......i just read (paraphrasing) "if you are going to do Agile you should hang your titles and your ego at the door"....

[@rkd80]

@@bhart89 lol, started reading comments exactly at that point in the video. Can't really take this seriously.

[@MischaRamseyer]

Great Stuff Renee. Many thanks !!

[@lyonelscapino6590]

I would love to see/read a business case, a real life implementation.

[@reneetsielepi160]

Loads of real life implementations going back to 1993 when Jeff first implemented Scrum@Scale up till 2021 - have a look at the official scrum@scale youtube channel on kzbin.info

[@TimOttinger]

Informative, but the graphic at :56 bothers me a lot. It follows the "area of the rectangle" thinking -- if we use one team it's 12 weeks, but if there are three teams thn it takes only 4 weeks" straight division. While this is the reasoning many people use when "scaling up" agile, it has not been true. There are a lot of reasons (including learning the code base, tackling infrastructure and version control difficulties, coordination and dependency problems, maintaining alignment, and social dynamics) that this cut-n-dry "divide by three teams to get 1/3 the wait" doesn't work -- and has never worked. I wanted to be sure that this warning is included as people come here to understand the whole "scaling to many teams" idea -- it's not as easy or as mathematically clean as it sounds. Co-creating in groups is a whole different game from working in a single team.

[@reneetsielepi160]

Wow thanks for watching and for the feedback Tim, i'm humbled! Your point is spot on, its very rare that scaling teams ever reach this linear scale-ability. It is one of the core goals of scrum@scale.

[@juancarlosabad3298]

Absolutely! ...it may get worse, according Brook's Law adding more people to a (late) software project will probably delay it even more ...en.wikipedia.org/wiki/Brooks%27s_law

[@zainliam2899]

i know I am kinda off topic but does anyone know a good place to watch newly released movies online ?

[@arisamuel7042]

@Cruz Jefferson thanks, I went there and it seems like they got a lot of movies there :) I appreciate it!!

[@ricardobraylen1014]

@Zain Liam glad I could help =)

[@drewbizdev]

Good video. Love the back ground music. Do you have a link that points to this music?

[@amoghjoshi2091]

This is amazing video. Will make more sense once we complete the CS@ST training or speak to a S@S expert. Connect with us for more details.

[@kingpin-187]

Did Dr. Seuss come up with this terminology?

[@miguelsimoes3170]

sosososos just S.O.S.

[@maurizioborrelli3946]

Scrum@Scale is just a way how to overcomplicate complexity in a very messy way. Jeff S tried to "not replicate" what we have in SAFe @ Essential which is so much easier, clear, practical and has no philosophy. The video itself is excellent, don't get me wrong. The problem is Scrum@Scale which is just a commercial initiative from the creator of SCRUMS. To keep up with the increase in complexity, the only option was to "reinvent the wheel" by messing up practices that were easier and working fine. So Jeff S started from a well-oiled wheel (SAFe and LESS) to present his own "rectangle" to scale complexity. What a mess!

[@motozappa8095]

What is the difference between Product Feedback and Release Feedback?

[@juancarlosabad3298]

12:12 [PRODUCT AND RELEASE FEEDBACK]: "The feedback component is the second point where the Product Owner and Scrum Master Cycles touch; product feedback drive continuous improvement thru adjusting the product backlog while the release feedback gives continuous improvement thru adjusting the deployment mechanisms." ....so, in my understanding, the PRODUCT feedback is a feedback of WHAT we have released.... and the RELEASE feedback is a feedback of HOW we have release it (the product)...

[@digitylconsulting6785]

Citing the Scrum@Scale Guide: "Product feedback is interpreted by the Product Owner organization to drive continuousimprovement of the product through updating the Product Backlog(s). Release feedback is interpreted by the Scrum Master organization to drive continuous improvement of the Delivery mechanisms."

[@CharliesOpus]

wow this is... kind of ridiculous lol. I am not following along at all. Essentially using scrum to implement scrum, right? On another note - the idea of having Scrum of Scrums of Scrums Master on your resume is quite humorous. hahaha

[@yuriyhlushchenko8653]

Backgroung music is annoying, the speed of narration is too high. This makes the process of comprehension of the content in this video so much complicated.😢 Please be mindful of that moving forward.