YDS: Why Don't Todd and Ryan Talk About Scaling Scrum?

Why Don't Todd and Ryan Talk About Scaling Scrum? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley.

Professional Scrum Trainers Todd Miller and Ryan Ripley built this course to help those interested in Scrum get up and running quickly using the Framework. They've partnered with Daria Bagina from ScrumMastered to bring practical materials and guides to the course.

Todd and Ryan also co-authored a book - Fixing Your Scrum: Practical Solutions to Common Scrum Problems.

For more information about Agile for Humans, visit:

For more information about Daria and ScrumMastered:

#ScrumMasterTraining #Scrum #ScrumFramework #ScrumMaster
#HowToBecomeAScrumMaster #ScrumMasterCertification #AgileForHumans #FreeScrumMasterCourse #FreeScrumTraining

[himadridebnath]

Nice ! Really interesting and important message. Thank You @AFH

[madelinesall]

I agree with your sentiments here - I am curious how you'd answer this same scaling question from the perspective of a services team. I'm currently working within a professional services organization delivering software implementation projects, and I think we not only have to consider the architecture of our SaaS product but also the architecture of our project delivery. How do we consistently and effectively guide our customers to understand our solution, to do change management etc.? In general, I'd like to see more videos about Scrum teams & considering problems that exist when the product being created is not a piece of software! Thanks as always for your videos!

[madzero]

My 2 rules when it comes to scaling:
Rule #1 of scaling: DON’T SCALE !! Don’t scale up your company, scale down your product.
Rule #2 of scaling: Don’t scale it till you nailed it. But first, take another look at rule #1

[paulcasanova]

This is a really good explanation guys 👏
I love the way Jeff describes it "if you can't Scrum, you can't scale", and also questions "why would scale your organisational impediments?" like you've said so well.
So often organisations are eager to increase team size, believing that it will increase delivery capability, but if the fundamentals aren't there, it just makes things worse - like trying to swim in custard (not that I've tried that - I think the Mythbusters did an episode on it though 😅)

[CS-mqgd]

Love it! "Scaling scrum" is just for someone to put a feather on their hat as a part of "Agile Transformation" and call it a "win" to get a promotion!

[TheRyantanner]

a good one, I agree with your assessment. I would take it a step further and add that language like "scaled framework" is just another way of saying... "no longer agile". I think things like SAFe MUST tightens the ropes on process because without making it essentially more waterfall like it couldn't work due to other areas in the existing workflow that haven't been properly addressed

[kensaiyeahyeah]

Todd's and Ryan's transmogrifier!

[vkxcqsn]

I might revise my comment here. Scaling Scrum can look really good on paper. However, I am finding that there are even more impediments to deal with in Scaled frameworks. In some Scaled frameworks people often scale before they get the fundamentals down which seems to exponentially multiply the impediments. This is because they do not fully understand the Scaled framework let alone the basics, and then one has to untangle interesting practices that were implemented. There is so much to learn and master with Scrum, Kanban, and Liberating Structures (let alone XP and DevOps) without having to over-complicate things.

[gregporter]

Comment Most Meaningful to Me: "It's a shame when companies define their product by their architecture, " as it calls for a return to the Agile Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams"

[maddiemay]

This is so interesting, thanks. I have a follow-up question as I'd love more detail: How exactly can a Scrum Master promote architectural excellence?

For us, when looking at root causes of bugs or impediments within our Scrum team, it often comes down to the fact that the architecture wasn't set up to support what we're currently delivering. A couple of reasons: we weren't aware of the complexity of the big picture at the time, we didn't prioritise architecture at the beginning, the person who specialised in architecture was let go during the pandemic and now we're experiencing the cost. This was all before my time and I don't have a technical background myself to dig deeper so what options are available to a non-technical Scrum Master if we don't have the budget to go and hire a load of architecture experts?

[maureenbecker]

I really like the idea of a single product, single scrum team. I do feel like this is an advanced concept for many companies that have operated as "IT as a service". As you mention, they are organized around applications rather than products and have "scaled" their applications with many developers. They operate as a "silo" outside the business product-focused organization. We have tried to form these silos into scrum teams but they are lacking a true product owner and a product focus. What would be the first step, in your opinion, for these large IT organizations to increase their agility? You mention fixing the architecture. How would you identify what needs to be fixed if the teams are not organized around a product? Would you still recommend they adopt Scrum before they are product-focused? Or would the first step be to try to re-align the teams to be product-focused and then fix the architecture?

[veccher]

i believe it's a lot of times a problem with focus and value, they can't focus on the most valuable things so they want to do anything as a "feature fabric" and start hiring more and more people. I agree there are times where you need more, but most products will have not much difference in value delireved going from 5 to 50 devs.

[tomaszniemiec]

Difficult for me to answer first from myself, so I need to guess here: my thoughts go immediately to that scaled Scrum is just Scrum with additional things to care. If we talk about two Scrum teams working together, this is pretty easy to do as you just do Scrum. The dependencies are easy to track, meetings are still manageable, integrating a working increment is still doable and so on. If we are talking more, this is where is becomes tricky as the dependencies and integration issues arise more often. Here you need to look at Scrum of Scrums or Nexus for guidance.

[ThomasOwens]

I agree that scaling, by itself, won't solve problems and that if you don't have a good base, you are only scaling the bad practices. However, there are a lot of cases where multiple teams will work on a single product and need to coordinate. Scaling frameworks like LeSS and Nexus, give a Scrum-based foundation for scaling. Any discussions of scaling would need to include the prerequisites, like technical excellence. But not talking about scaling isn't helpful to organizations who are already in a multi-team context.

[XGSPaBeRZz]

A question I would like to see discussed in the next episode if possible: Is the Scrum Master Market Oversaturated? When I look at job postings in comparison to a scrum master, there is always a minimum of 200 people who have applied for that job. As someone who has an interest in becoming a Scrum Master, am I better investigating my time into another career path? Love the content keep it up!

[vkxcqsn]

Regarding scaling - I honestly think people need to get the basics down first. The organization really needs to do the hard thinking of re-aligning roles so that they know who the PO is, who the ScrumMaster will be, and how they are re-aligning the roles of their Project Managers. The next part is that I think the organization really needs to practice embodying the Scrum values. If the senior and middle managers don’t embody the Scrum values, I suspect that an Agile transformation will be limited or the organizational will be practicing Scrum in name only.

I have an adamant dislike of LeSS, but that is due to going through a really bad organizational Agile transformation where the developers effectively took over the Portfolio and middle management was sidelined. In retrospect, we really didn’t need to scale. Re-building my trust in LeSS would take time, and I would have to be assured (with actions to back it) that developers would not take over and the processes required for delivery (due to compliance requirements) were not going to be broken.

I did study SAFe because the Agile coaches couldn’t answer my questions. I found SAFe trainers were more effective in answering my questions. I also liked the more business oriented feel of SAFe. If we weren’t going to scale, then I would want to know how one would prioritize work across projects or products. That was a major problem for us - that is, projects were constantly fighting over people and resources. I am not clear on how project work was prioritized except maybe by which ones had the most problems vs. which ones were going to deliver the most business value. Interestingly, I see this as an opportunity for development in a current organization using SAFe but at least there is guidance in how to prioritize work at the higher levels that have not been covered in basic Scrum classes.

I also like that training is embedded in the conversation about SAFe. I have encountered too many teams that operated where people were not trained in their roles.

While my preference is SAFe and I really dislike LeSS, I will agree with you that SAFe is the kitchen sink of Agile. I think you unintentionally hit a nerve. :)

[peacenformi]

Hi pls help with tips pls... anyone can help...

I have a 5th round interview with the Senior Director and l don't know what to expect from this interview. It's a 45 mins interview and l don't know what to prepare for. I am new to Scrum. Thanks

[timwendt]

I like you guys, but wow, this is a bad take.

First, I agree that fixing things at the team level are an important first step and any transformation is going to go better if the teams are already living and breathing agile. But scaling agile is not about scaling existing bad practice; that is untrue. Please show me where SAFe directs you to scale crappy practices. SAFe is about raising agile-lean principles up to every level in the organization and replacing systems that work against agility with systems that applying lean-agile principles. Scaling brings lean-agile thinking to product and portfolio management. It seeks to get rid of existing PMO practices, eliminating cost center accounting, moving to participatory budgeting, and limiting WIP at the highest levels. Great agile teams are weighted down by traditional PMO practices. Teams alone can't remove those systems as they don't YET have the power - scaling practices gives them that power.

I feel that people who crap on scaling methods have never worked in an organization that builds things at scale or are just ignorant about scaling models - because if they did, they would see the value in applying lean and agile principles outside of team scrum. Take a Leading SAFe class. Go visit a company that is exceling with LeSS. Go watch a Big Room Planning event. My favorite agile author, Lyssa Adkins, did this and found that SAFe WAS agile and she talks about the energy around SAFe done right; go read her blog about this experience. Visit the SAFe Summit conference and challenge your thinking.