A YouTube viewer sent in a question asking about what to do when a Developer does not commit. This question had a little context with it. The scenario was when a Developer won't focus during a Scrum Event or meeting. Check out what Todd and Ryan had to say about this situation!


// Want to learn more about Scrum?
Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3b96j0A


// Join Ryan and Todd in a Professional Scrum Master course: 
Visit https://agileforhumans.com/ for a list of upcoming courses.


And make sure you subscribe to the channel!


DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide I may receive a small commission. There is no additional charge to you! Thank you for supporting the channel so we can continue to provide you with free content each week!


FTC DISCLAIMER: This video is not sponsored by anyone.


Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems.
See omny.fm/listener for privacy information.
Learn more about your ad choices. Visit megaphone.fm/adchoices

Episode 124: YDS - What Happens When A Scrum Developer Doesn't Commit?

Agile for Humans™ is a weekly podcast dedicated to the individuals and interactions that make agile work. The goal is to help create safe and collaborative working environments where people are empowered to do their best work.

Technology

Tech News

Podcasting

Gadgets

Software How-To

Business

Investing

Careers

Management & Marketing

Business News

Shopping

News

Management

Ryan and Todd look back at a 2006 post by Ken Schwaber, which covers 15 ways Scrum is both hard and disruptive.

The twelfth statement from Ken:

"Managing a release or project to deliver only the highest value functionality and not deliver the rest optimizes value [and] is the job of product management and customers."

The 12th episode of "Scrum is Hard and Disruptive" discusses the importance of delivering only high-value functionality in project management, emphasizing the role of product management and customer input.

The hosts, Todd and Ryan, stress the need for product owners to say "no" to unnecessary features, highlighting the importance of avoiding waste and focusing on what's truly needed.

They discuss using Evidence-Based Management (EBM) to validate the usefulness of features in production and advocate for objective decision-making in product development.

The episode touches on the customer's responsibility in the development process, encouraging their involvement and accountability in deciding the essential features.

The conversation also covers the importance of being ruthless in backlog management, akin to Steve Jobs with the iPhone, and the value of saying "not yet" to lower-priority items to maximize return on investment.



Scrum is Hard and  Disruptive 12 - Maximize Value

Jenny Tarwater's Journey to Scrum Mastery | Expert Insights & Tips

Ryan and Todd look back at a 2006 post by Ken Schwaber, which covers 15 ways Scrum is both hard and disruptive.

The eleventh statement from Ken:

"Iterative, incremental development is much harder than waterfall development; everything that was hard in waterfall engineering practices now has to be done every iteration, which is incredibly hard. It is not impossible, but has to be worked toward over time."

Iterative and incremental development in Scrum is more challenging than traditional waterfall development, requiring constant attention to engineering practices and frequent iterations.

Extensive upfront design and architecture planning in waterfall development is believed to reduce future risks. However, software development often leads to outdated designs as customer needs and market conditions change over time.

Scrum emphasizes quick decision-making on basic architecture, like frameworks and databases, while building the product incrementally. It demands disciplined, professional attention to ongoing architectural and design decisions in response to evolving customer demands.

The Scrum approach challenges traditional development models like waterfall, where work often expands to fill the allotted time, leading to over-engineered solutions. Scrum requires a shift in mindset, focusing more on doing and building features rather than extensive planning and discussion.

Adopting Scrum effectively requires gradual, sustained effort to improve engineering practices and architecture. Teams and organizations need to develop this skill set over time, including a solid understanding of their definition of "done" to reflect the maturity of their Scrum implementation.



Scrum is Hard and Disruptive 11 - Scrum is Harder than Waterfall

Ryan and Todd look back at a 2006 post by Ken Schwaber, which covers 15 ways Scrum is both hard and disruptive.

The tenth statement from Ken:

"Scrum is not a methodology that needs enhancing. That is how we got into trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centers on the changes in the enterprise that is needed."

Scrum's Nature and Misunderstandings: The discussion emphasizes that Scrum is not a methodology needing enhancement, as attempting to perfect it led to initial troubles. It’s highlighted that Scrum is a framework, not a methodology, and should not be altered excessively.

Scrum's Simplicity and Accessibility: When Compared to more complex methodologies and frameworks, Scrum’s guide is concise (13 pages), making it easily understandable without the need for extensive training, unlike more elaborate methods that require significant learning and interpretation.

Adaptability and Contextual Use of Scrum: The speakers discuss the importance of adapting Scrum practices based on specific team and project contexts. They share personal experiences where certain practices were effective in one situation but not in another, illustrating Scrum’s flexibility and the need for situational awareness.

Evolution of the Scrum Framework: The evolution of Scrum is discussed, noting that over time, the framework has become more streamlined, with a focus on removing unnecessary elements rather than adding new ones. This evolution aims to prevent dogmatic adherence to processes and encourage teams to focus on the intent of each Scrum event.

Focus on Organizational Change Over Scrum Modification: The conversation shifts to the idea that efforts should be directed toward changing organizational structures and practices that hinder agility, rather than trying to improve Scrum itself. Emphasis is placed on overcoming organizational impediments to enhance the delivery of value to customers and gain competitive advantages.



Scrum is Hard and Disruptive 10 - Leave Scrum Along

Unlocking Business Agility with EBM - CHECK OUT OUR NEW BOOK!

Agile for Humans with Ryan Ripley and Todd Miller

Episode 124: YDS - What Happens When A Scrum Developer Doesn't Commit?

Download our free app to listen on your phone