Blame the Tester

An example of ScrumBut

  • When a Scrum project fails, you always blame the tester! But surely you are missing the point?…

    So you’ve sent your team leaders on a training course to learn all about Scrum and to maybe even obtain their certifications too. Your newly certified in-house Agile “mentors” have been tasked with bringing the rest of the development team up to speed with Scrum.

  • A few months later…

    A few months have since passed and things just haven’t worked out as you expected. The development team are far from content as they have mixed feelings about this “new way of reporting”, with “Sprint” being just a fancy new word for “4 weeks of work” and Burn Down charts, which seem to be burning up rather than down.

    Obey Thy Scrum Master!!

    There’s a growing mountain of unfinished work to do, in fact more than you had before you “went Agile”. Your new Scrum Masters are perplexed as to why the rest of the team doesn’t do as they are told and work on the tasks that they are given. It certainly wasn’t as difficult as this when they were on their training course several months ago.

    Bugs? What bugs?

    Worst of all, the business cannot understand why you keep delivering buggy software with features that they weren’t expecting and without the features that they claim to have been promised.

    There’s a lot to discuss

    Could it have something to do with the hour-long Daily Scrum meetings that the Scrum Team have been having whilst they block the corridor and argue about who is at fault?

    Blame the Tester!

    Without doubt, it must be the software tester who is to blame because he never tests the software thoroughly enough before you need to release it at the end of each sprint. But the tester insists that it’s the developers’ fault because they don’t give him the software to test until mid-morning on the last day of the sprint. At which time, the IT Manager is stamping his foot, reminding the team “We go live at 2pm, bugs or no bugs”.

  • Go Live!

    By 2:30pm the phones are ringing off the hook and the Service Desk Manager has made you well aware of her anger after running out of expletives (and she has many)!

    The Stakeholders are less than delighted with your latest “bugware”, especially as none of last month’s reported bugs have been fixed and the anticipated new features of the application are missing.

    Tablets for the CEO

    But your biggest headache is the CEO, who will be hopping mad when she finds out that the app will not run on her tablet device. This was a change to the software that she stipulated 3 weeks ago whilst trying to squeeze past the Daily Scrum crowd in the corridor.

    What Product Backlog?

    After the dust has settled, you will add all the new bugs to the bug list. After all, there’s no point in putting them on the Product Backlog because the Product Owner has been too busy to look at it since he first created it 3 months ago. But that’s okay because you know what he wants anyway!

    Sack the Tester!

    Never mind, you’ll fix the Burn Down chart in the next sprint by removing the tester from the process. He won’t be missed as he doesn’t contribute that much anyway – just 2 hours on a Friday morning, once a month.

    Besides, he’s worse than the Stakeholders – always moaning about bugs and blaming the software developers!

    The above is a ScrumBut case study, based upon our own customers’ experiences, of how NOT to do Scrum!

If this tale of woe sounds all too familiar, then Agilistix can put you back on track

  • Do Scrum the right way with Agilistix

    We can help you to work smarter, faster and cheaper than ever before.

  • Call Us Today