- And what method are you using on your project?
- Oh, it’s Scrum. But we’ve improved it a bit …
Sounds familiar? Yea, I believe everyone has met “scrumming project” at least once. Shamefully in 90% of cases, people just use “Scrum” as a label. They’ve just started an underestimated project and they’re struggling to get rid of activities they find time-consuming and non-critical to project delivery ("screw the quality, we have to deliver whatsoever!").
So, as Scrum is the way to get rid of documentation, they happily announce that they follow Scrum. They just tend to forget a thing - as removing documentation increases project’s risk, Scrum compensates it with some techniques - direct cooperation of co-located business and tech people, automated unit tests, sometimes even ATDD / BDD, brief and simple stories. But that’s not something Scrum-liars think about, they just want to get rid of a burden (creating docs).
Another common Scrum-liars’ technique is ignoring that sprints are (by definition) meant to deliver working software that’s supposedly shippable. Majority of “Scrum” projects I’ve dealt with (as an external!) did "integration tests sprints" and / or "user acceptance tests sprints". Can you believe that? This pretty much means that sprint after sprint they were creating _something_ unmeasurable that can’t mean any reasonable Definiotion of Done and in the end they have to check if it meets the needs and works well with the rest of IT landscape.
In truly waterfall project the risk (in theory) is quite limited as there are some specifications / documentation to verify products against. But in such scrum-like endeavors They’ve just spent two months on development and now they’re going to find out whether their guts feeling was right and it will work or not.
Don’t use word “agile” or “Scrum” to justify your lack of skills nor wrong estimations. It’s a lie. Just a lie.