I am a fan of Scrum. So much so that we use it across all our product development teams. Well almost. We use a form of it. Actually, technically according to Scrum, we don’t use Scrum at all, we use “Scrum But”. Therefore according to the industry we are scum, not scrum:). I jest a little, but what does ‘Scrum But’ mean? On the scrum.org website it is defined as follows:
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum. Every Scrum role, rule, and timebox is designed to provide the desired benefits and address predictable recurring problems. ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.
I have mostly heard this term replayed to me by some Scrum Coaches in response to a line like - “We use scrum for the most part, but…” Ah, Ah, Ah comes the interjection, “You are using Scrum but, You are not following Scrum”. At this point, I am supposed to be ashamed, I am supposed to feel stupid, but funnily enough, that’s not how I feel & I usually end up asking if I can please finish my sentence.
Some aspects of Scrum are very core to the way we build software products. Planning meetings, daily scrums and the definition of done are non negotiable. These are critical and help use the resources of the team as efficiently as possible. But other things, well, they don’t really matter to us.
So, what do we do wrong? Well firstly we don’t force the idea that everything in an iteration is done at the end of the iteration #scrumfail. Funnily, I don’t consider this a failure. Planning, even if you are using story points, which I do believe help make estimation better, is by its very nature an inaccurate science. We write as good a story as we possibly can, we use story points and we try to estimate as accurately as we can, but we will have situations where there are unknown issues, or an aspect of a story is incomplete. We strive to have better stories and even try to have a good idea of the technical solution prior to planning, but it is still difficult to estimate accurately prior to starting development. So with this in mind, we don’t go around calling our iterations a failure if something is not done at the end of the iteration. And more importantly, since we don’t consider it a failure, we don’t really try to fix it. Why not? Well, we pretty much go to production every day, so missing a date is not such a big deal if we can just push it live the next day. Now, we don’t just sit around and not care about dates. Obviously if business critical functionality needs to ship, we do everything we need to do to ship it, but this has nothing to do with Scrum, this has to do with the culture of our organization, which is driven by delivering high quality code to our end users. What we do consider critical, is that everything that is shipped to production is done, using the strong scrum definition of the word done.
People might say that teams are not reaching their full velocity? I firmly believe that great engineers build great software faster not a framework such as Scrum. Scrum may at a certain level help them stay focused and out of unnecessary meetings etc., but I have seen the “velocity” of SDLC teams that are working together over a period of months dramatically increase over time, purely based on the fact that they had great engineers on the team that just wanted to build great product. When first putting a team together, it takes time for the team to gel - once a team has gelled, productivity naturally increases whether you are using Scrum or not. In of itself, having everything done at the end of an iteration does not increase velocity. So given this view point, we don’t really value velocity, to us, it is as unscientific as counting lines of code.
What else don’t we do? Well we hold retrospectives every other iteration. Our iterations are every 2 weeks and people were finding them of sufficient frequency if we did them every other iteration. So shoot me – that’s what we did. Sometimes managers attend scrum meetings - they can actually help, and enable the team to deliver product faster. But we certainly don’t allow the scrum to take longer than 15 minutes.
But my main objection today is the use of the phrase “scrum but”. It gives ammunition to people who are ignorant, yet able to digest sound bites. It insinuates that the founding fathers of scrum were able to anticipate every use case of scrum and every environment that scrum is used in and every edge case. It insinuates that people can’t think for themselves, that other people know better. Honestly I find it a little obnoxious. I do give the benefit of doubt that the term “scrum but” was developed with good intentions, primarily to keep new adopters on the straight and narrow. But I do have a fundamental problem with the concept of Infallibility - the idea that one human being or organization knows everything and other peoples opinions don’t matter, well, it bugs me.