Agile processes and aspect oriented programming used to be my main interest - but I'll blog about just anything that comes up :-)

Sunday, July 12, 2015

Scrum-But or Inspect and Adapt?

For a couple of years now I have heard people condemning projects as “Scrum-But”, mostly without even looking at the projects. And sometimes even without any reference to what they consider to be a scrum-but.

“but” what?

As you probably can imagine after my last two posts, I am especially suspicious if people do that without looking into the scrum guide. I keep experiencing people proclaiming something is a scrum-but because of all kinds of misconceptions. Sometimes “they don't have 2 week iterations” (the scrum guide calls for “a time-box of one month or less”) or because “they don't use Unit-Tests” (the scrum-guide states that “Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.”)

While it might be preferable to have shorter timeboxes (as the agile manifesto clearly states: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” [emphasis added] ) and that it is much easier to have a thoroughly tested product if one does have automated tests including unit tests, this is more about common sense (or agile experience) – but definitely not part of scrum.

Apart from the fact that more often than not, the same people carry the battle cry of the agile credo inspect and adapt as a default answer to most everything, there is a certain irony in the fact that nowadays we seem to have a kind of method police around scrum while the first value pair of the preamble to the agile manifesto reads “Individuals and interactions over processes and tools.”