Once upon a time, I worked at a software company building products for oil rigs. One of the freelance developers working there, Ibrahim ben Salah, introduced Scrum to the organisation. This was my first encounter with Scrum too.
What’s interesting, when I look back, I feel kinda embarrassed by all the weird Scrum interpretations I’ve witnessed over the years at different companies.
Here are some of the crazy things I have witnessed on the Scrum Teams I worked with.
- We used the Spotify model, even though nobody knew why, nor did anybody understand Scrum, Agile or Kanban. But the Spotify model was great, just look at the awesome explainer video on YouTube!
- We had a bug month, during which we were only allowed to fill our Sprints with bugs. The bug month was extended with another month because we had too many bugs. We did not address the root cause of all those issues, so the actual problems were swept under the rug.
- A deadline for a new product that was decided by the C-level, even though nobody knew what the product should do, the market it would serve, nor the underlying technology we would use to build it. Regardless this uncertainty, it was communicated with absolute certainty when our new product would be live, together with the scope. Needless to say, we never met that deadline and nobody felt particularly compelled to meet it.
- We hired an extra development team to speed up the delivery of a new project. All the communication and coordination of the new team cost our existing development team so much time, that basically we were paying three times as much to go at the same pace as before.
- Teams were expected to increase their velocity, as otherwise why would we pay extra for hiring a Scrum Master? We needed to make sure the Scrum Masters were worth their money.
- Once the Sprint started, it was locked tighter that Fort Knox. No changes were allowed during the Sprint, at all. The Sprint was our precious temple which nobody was allowed to touch but us.
- Developers did not like testing, and I was a QA, so at the end of the Sprint I would always work like crazy to make sure we would still be able to complete the Sprint. I would receive no help, in favor of developers coding even more functionality, even though we all know any speed improvement not made at the bottleneck is an illusion.
- Nobody was allowed to talk to the team and all communication must go through the Scrum Master.
- Only QA’s were allowed to test, even though it was the biggest bottle-neck in our development process.
- We sat in Sprint Planning for 3–4 hours for a two week Sprint. We broke down all the work in sub-tasks and estimated them in hours. We felt we were doing a great job, but in retrospect I now think: what a giant waste of time!
- We didn’t use Sprint Goals, the Sprint Backlog was the goal. Needless to say, most of our Sprints failed.
- Story Points were introduced to the Scrum Team as a measure of value. We never Story Pointed bugs as they did not represent value. I didn’t understand the reasoning at the time, but we had an Agile Coach who ruled all Scrum Teams with an iron fist. We just followed her blindly.
- All Backlog Items discussed during refinement were treated as a contract. We’d only give them an estimate if every single detail was spot-on. It took many weeks to refine a single issue.
- Everything we did was a User Story, even if it made no sense to use a User Story.
- We had a Definition of Ready that was more complicated than our Definition of Done. Our Product Owner would already start sweating before refinement started. It was considered a sport to poke holes and figuring out missed details in presented issues.
- Development Teams that spent 50% of their times on Spikes, because their Product Owner didn’t have enough time to explain everything to them.
- During the Daily Scrum a lot of people participated who were not part of the Development Team. The event became a big mess, instead these powerful stakeholders could have just been listening in, or not attend at all.
- Daily Scrum was a status report and nobody talked about the Sprint Goal. The three questions, minus the Sprint Goal, were key. Kinda missing the whole point of the event.
- The main purpose of the Sprint Review was to demo features and get people excited about all the stuff we had delivered, except most of the features weren’t even done and just running on a development environment. Anything to keep up the appearance that we were moving fast. In the short-run, it relieved some pressure. In the long-run, the expectations and pressure was increased massively.
- Sprint Review was regularly moved because certain VIPs were not able to attend. Having a Sprint Review for the previous Sprint while your next one has already started doesn’t make a lot of sense.
- Product Owners who needed to be on call to help troubleshoot technical issues, because the company didn’t trust their developers to be responsible enough to handle fixing and communicating the resolution of issues on their own. The job of the Product Owner was literally to pick up the phone, wake up a Developer, stay awake, and then check if the issue had been resolved.
- The Product Owner role was split between a Product Manager and a Product Owner. Both roles did not think the split of responsibilities worked and the plug was pulled after having a retrospective with the whole Product team.
- The Product Owner held the role of Scrum Master as well. Like the Product Owner role wasn’t complicated and overwhelming enough. The Scrum Master role was seen as overhead and we want our developers to focus on coding.
These are some of the craziest things I have encountered. How long have you been doing Scrum and what are the craziest things you’ve witnessed? Please share your wild stories!
Here’s to another 7 years of doing Scrum, and I’m curious to find out all the crazy things I’ll have witnessed by then.