How Scrum helps you change what needs to be changed within your organization
Last week, Gunther Verheijen posted a much-needed article showing worrying interpretations of Scrum. Please read it carefully if you care about professional Scrum.\r\n\r\nIn my role as an agile coach, I hear people say awkward things about Scrum on a daily basis. Stuff like Gunther mentions. There’s nothing wrong with that…as long as these people learn, correct themselves, and start making a difference.\r\n\r\nWhat worries me more is that many people advocating Scrum haven’t read the Scrum Guide. Or even the Agile Manifesto. They apparently weren’t curious enough to find out what Scrum truly is. Most of these people thus limit themselves to explaining their interpretations of merely the roles, artifacts, and ceremonies, putting emphasis on how to perform a daily “standup” or what a Scum Master should do and then still faltering at that. How odd!\r\n\r\nScrum, when “applied” well, is extremely powerful. Teams can double, triple, or quadruple their productivity with ease. More importantly: they will actually deliver working, releasable software that truly helps shorten time to market. The core of Scrum, as Gunther explains.\r\n\r\nBut…Scrum is not for free. Far from it. It comes at the cost of your organization’s current structures including your personal work environment, your role, your privileges, and hence your comfort zone.\r\n\r\nDue to the nature of incremental delivery AND the focus on getting the software truly “done” (as in working, releasable), you will need to radically change everything in and around the team.\r\n\r\nYou start your sprint one with a bunch of requirements. Two weeks later, some potentially releasable software is expected. So…the team immediately needs some space to work, tools for development and collaboration, architecture guidelines, access to users, proper environments, privileges, connections to databases, working services from other teams (alignment horror!).\r\n\r\nIt is incremental delivery with the strong requirement to have a potentially shippable increment by the end of every single iteration/sprint that is most disruptive. Alas, without it you are not really doing Scrum according to its makers and most of its knowledgeable supporters.\r\n\r\nNow, do you still want Scrum? Do you want to be part of such a challenge as a team member, chasing organizational impediments like a mad man? Do you, as a manager, want development teams to turn into autonomous productivity monsters at the cost of your span of control?\r\n\r\nThink about it.\r\n\r\nAnd don’t believe that any other agile framework or method will save your ass. ALL of them support incremental delivery. Only the weaker ones (or better: the misinterpreted ones) do not put focus on working, releasable software.\r\n\r\nOf course you can game everything by just pretending you are using Scrum. You could stress the importance of a print zero, put a proxy product owner in place, organize hardening sprints, explain that “done” in your company means something special, stick to steering committees, etc. Just come up with anything that comforts you and puts your mind at ease.\r\n\r\nOr actually…please don’t.\r\n\r\nDo you want to be truly succesful with agile and Scrum or any other framework? Then face your fears, expect radical change and have the people who do the actual work help you through that change in a decent way. There will be pain, but…no gain without pain ;-)\r\n\r\nEnjoy your challenge!