AKA Worrying interpretations of Scrum, pt.2 – This week I had the pleasure to facilitate two days of learning. One day was all about working towards the Scrum.org PSMI certification with a Dash of Scrum (master) practice. The other was more about Scrum & Agile basics.
Then as I was skimming through linkedin today, I saw an interesting link: Top Answers to Agile Interview Questions
Curious as I am, I clicked the link to read and hopefully learn from seeing examples of good agile themed interview questions (for example when looking for scrum masters, product owners, etc).
Then it happened. Upon reading the questions and answers, I got sad. Maybe even a little mad. I was hoping for practical tools and ideas for interview questions, where the interviewee can truly flex their Agile mindset by discussing Scrum situations from practice. But sadly the page comprised of a long list of ‘basic’ and ‘advanced’ questions and answers of facts. And I believe that you shouldn’t ask lots of theoretical questions in interviews, but rather invest in finding someone with the right mindset, who understands the underlying principles and ideas behind Agile and Scrum.
But that is not the worst part. Having another take on Scrum theory can be a great tool to refresh. But only if the contents are correct. And as you might guess, they were not quite. Let’s look at an example of an ‘advanced’(??) interview question:
5. What are the artifacts of Scrum process?
The answer listed contains four artifacts, not including those I had expected. The answer described Sprint Backlog, Product Backlog, Velocity Chart & Burndown Chart. The last two charts are not a part of the artifacts in Scrum – at least not mandatory – and simply an often used way to visualize progress (as a way to support transparency).
While it is excellent to focus on theory and knowing Scrum by heart, but taking the naïve stance, I’m assuming you want to help people with useful information… Then at least get that shit right. Come on!
Disclaimer: I use scrumguides.org as a guide for the theory of Scrum. This is the official location where the Guide is kept up to date by Scrum’s creators.
In the official Scrum resource at Scrumguides.org the three artifacts of Scrum are very clearly listed:
Made transparent by the Definition of “Done” (thanks Gunther for helping getting this straight via twitter!).
Side note: I would be very happy to help you learn why these artifacts ended up being part of Scrum, while others (like the burn down charts) are optional, although often used, just like the practice of planning poker etc. But that is maybe for another post.
For now, I’d like to offer this as a potentially dangerous example where using the wrong source can backfire. When you prepare for an exam or interview based on information from a ‘random’ Scrum site, you risk getting it wrong. And losing the job or certification. On top of that, you risk the dangers of incorrect interpretations of Scrum that Gunther Verheyen wrote about a while a go. I’m not saying you can never add to the Scrum basics to improve on how it works for you. By all means, when playing the game of Scrum, Inspect and Adapt to keep that continuous improvement going. But when you’re new to Scrum and want to prepare for a Scrum job interview or exam…
Go to the source!
Peruse the scrum.org site, go to scrumguides.org and check out a guide in your favorite language. The Scrum theory is free to read and there’s a lot to learn from this material. If you really want to know more about the practice of Scrum, read a few of the suggested Scrum.org books (Gunther’s Pocket Guide is quite awesome) or attend a good Scrum training to get a handle on this lightweight framework.
I guess seeing these things makes me mad and sad because I care passionately about the ideas and principles behing Scrum (and the broader Agile Manifesto). I truly believe in creating better ways of working with mutual benefits for organizations and professionals alike. So go out, learn, improve & remember to have FUN. But do it based on the correct information, please. It’s not hard!
PS Here’s a drawing the students and me collaborated on during a Scrum Training I facilitated this week. I used it to collect all the stuff they already knew or heard about, and subsequently used the image to put the stuff we were learning about in a visual perspective of the process. In my experience, this works especially well with a group of students that have already heard things here and there, so you can separate out the optional stuff (i.e. burn charts, planning poker) from the core…
Final disclaimers: Image Previously published on Instagram. Don’t fall into the trap of using this sketch as the Scrum truth. I tried my best to visualize the core of Scrum. Please reach out if you see anything to improve! 🙂