Scrum’s Nature: It Is a Tool; It Is Not About Love or Hate

TL; DR: Scrum’s Nature: It Is a Tool; It Is Not About Love or Hate

Regularly, we find articles from developers detailing why ‘Agile’ in general and Scrum’s nature, in particular, deserve our collective disdain.

What has always struck me in this discussion is its emotionality. Scrum is a tool, useful to accomplish one primary task: delivering value to customers of emergent products in complex environments while mitigating an organization’s exposure to risk at the same time. So, if Scrum is not working in an organization, maybe it is because Scrum is applied to the wrong cause in the first place. Or, that its application has been mechanical, driven by folks who don’t know what they are doing. (Seriously, how hard can Scrum be if the manual comprises of 18 pages, right?)

The question then is: Why would I “hate” a tool unsuited for the intended purpose or applied incompetently? Would I hate a hammer for not being capable of accurately driving a screw into a wooden beam? Probably not, as the hammer wasn’t designed for that purpose, and neither sheer will-power nor stamping with your feet will change the fact.

Scrum’s Nature: It Is a Tool; It Is Not About Love or Hate — Age-of-Product.com
Continue reading Scrum’s Nature: It Is a Tool; It Is Not About Love or Hate

Development Team Anti-Patterns

TL; DR: Development Team Anti-Patterns

After covering the Scrum Master and the Product Owner, this article addresses Development Team anti-patterns, covering all Scrum Events as well as the Product Backlog artifact. Learn more about what to look out for if you want to support your fellow teammates.

Development Team Anti-Patterns — Age-of-Product.com
Continue reading Development Team Anti-Patterns

Scrum Master Engagement Patterns: The Development Team

TL; DR: Scrum Master Engagement Patterns

Last year, I ran a (non-representative) survey on how Scrum Masters are allocating their time when working with a single Scrum Team. Much to the surprise of many readers, the direct Scrum Master engagement with a single Scrum Team of average size and a typical 2-week Sprint turned out to be about 12 hours per week.

This result immediately prompted two additional questions: What is a Scrum Master doing during the rest of the week, and in what way does a Scrum Master’s work manifest itself over time? While answering the above question requires additional research and data collection, the latter can be answered to a certain grade by focusing on a few common scenarios.

The first article of this series will address the Scrum Master engagement with the Development Team.

Scrum Master Engagement Patterns: The Development Team — Age-of-Product.com
Continue reading Scrum Master Engagement Patterns: The Development Team