Why I Quit the Scrum Alliance

this is not a rejection of scrum or agile methodologies every one of the original authors of the agile Manifesto wrote code and wanted to help others write code more effectively I think it's time we return to agile's Roots hello world I'm David Scott Bernstein until recently I was a certified scrum developer and a trainer of scrum developers introduced in the mid 19 1990s scrum really changed the landscape of software development and made it far more sustainable it promised and delivered a more a more reasonable pace for development scrum also defined new roles such as the scrum master who wasn't an overseer but rather a servant leader dedicated to nurturing the team's health and removing obstacles so that the team could be far more productive the scrum master was meant to Shield the team from interruptions and managerial pressures and not act as a traditional boss this radical shift was groundbreaking it centered around empowering developers rather than trying to manage them the introduction of the product owner role was equally transformative it replaced extensive requirement documents with a single approachable individual someone who would be accountable for the Project's vision and be available to answer questions to this personification of the project project requirements humanized the entire development process making it more flexible and responsive it encouraged experimentation and collaboration over following a plan breaking down large tasks into smaller manageable pieces was also a key thing that scrum introduced quite brilliantly to the software development Movement by organizing development into time box Sprints developers focused their attention on a small piece of software that they could build in 1 to four weeks scrums iterative approach with regular small releases supports continuous feedback and course Corrections which is really vital for the Adaptive projects of today's environment the role of the product owner although not technical became crucial in nearly every successful software development project that I observed or participated in it brought a focus to software development that seemed to be missing previously directly impacting the quality and relevance of the code that we were developing but the product owner role could also lead to pitfalls I witnessed projects where product owners despite their best intentions drove development into the ground scrum tries to address this by having a robust definition for what done means so that everyone can get on the same page with an increment of value and when it is completed the Cal Manifesto emphasizes customer satisfaction through early and continuous delivery of valuable software however the reality of achieving this ideal can be very complex and you can't rely just on the scrum framework to make this happen this is where the need to incorporate agile technical practices becomes evident this brings us to one of scum's most significant paradoxes the expectation of delivering tested functional soft software at the end of each Sprint where the reality often falls short for most teams teams might end up passing unfinished code to a QA Department contradicting one of the core agile principles of maintaining potentially shippable product at all times the disconnect grows when bugs found later in the development cycle lead to significant delays developers need to switch contexts from working on new development to bugging which not only slows down productivity but also affects overall quality lean principles tell us that any work that is not completed and by completed I mean fully integrated and tested into the system is considered essentially waste moreover the nature of software development where everything must work in order for anything to work exacerbates these issues scrum was supposed to mitigate these risks by advocating for continuous integration and testing yet many teams struggle to implement these practices time boxing while effective for focusing A team's effort could inadvertently lead to Quality being compromised in the rush to meet deadlines this can create scenarios where Sprints end with potentially shippable increments of value but these increments often lack the robust testing necessary for a truly stable release this is where teams need to incorporate agile technical practices the heart of the problem was simple yet profound scrum as practiced by many teams had drifted from its roots originally designed to support agile technical practices like test driven development and continuous integration it gradually became more of a management process then about fostering technical Excellence this shift was really subtle at first but it has significant implications for the quality of software and the effectiveness of team my role as a trainer allowed me to interact with countless developers and teams I could see firsthand the challenges that teams faced when trying to implement the scrum framework without strong technical practices many teams struggled to produce truly shippable products at the end of each Sprint it wasn't because they lack skills it was because they had a process that boxed them in this challenge wasn't theoretical it manifest in projects that were technically fragile prone to bugs and difficult to maintain and that's the problem it's a slow kill process in software development everything looks like it's going to be fine and slowly technical debt accumulates and it can eat up projects it is the number one thing that eats up successful projects so we have to be really Vigilant against it scrum doesn't address any of this and that's one of the reasons why I left the gap between what scrum promised which was a responsive adaptive development process and the reality on the ground that I saw in company after company became increasingly difficult for me to ignore the emphasis on certification over real world capabilities began to overshadow core values of agile in my opinion this dissonance ultimately led to my decision to step away faced with these realities and my commit commment to True principles of agile focusing on individuals in interaction over processes and tools and customer collaboration over contract negotiation I felt increasingly compromised I found myself at a Crossroads needing to decide whether to continue in this changing landscape or seek A New Path that aligns more closely to my principles and values I sought an environment that not only preached agile values but also practiced them rigorously especially in terms of technical excellence and continuous Improvement as I step into this new chapter my commitment to Foster an environment that Bridges the gap between agile methodologies and Technical practices remains steadfast I want to help teams be truly agile not just in name but also in their ability to respond to and even thrive in an everchanging landscape

Channel: The Passionate Programmer

Views: 11,360

Keywords: Advanced Agile Techniques, Scrum vs Extreme Programming, Agile for experienced developers, Agile software development, Sustainable software practices, Agile best practices, Scrum pitfalls, Scrum limitations, Agile innovation, Technical excellence in Agile, David Scott Bernstein, Beyond Legacy Code, Software development challenges, Effective software methodologies, Extreme Programming benefits, Scrum, Agile

Id: 3cmY-OFuuCw

Length: 7min 58sec (478 seconds)

Published: Mon May 06 2024