Scrum at Artory
“Scrum is like chess. You either play it as its rules state, or you don’t.”—Ken Schwaber—coinventor of Scrum
One of the most popular agile methods for Software Development is Scrum. Most developers and product managers have used it at some point in their career, it is even taught in university.
The software development process at Artory is similar to Scrum. However, during more than two years of development, we have fine-tuned the process. This post assumes basic Scrum knowledge (you can find it at ScrumGuides.org) and talks about our modifications, enhancements, and implementation (Scrum — and more so Kanban — are just frameworks, but it leaves room for interpretation) of the process.
If you use Scrum, you have probably heard about the Retrospective. At Artory, we start off by going through the suggested actions from the last retrospective and only check if they have been done. It can be frustrating if you make up your mind looking for improvements during a retrospective and then they are forgotten. After this, we collect and present Do’s, Don’ts, and Try’s with post-its on the whiteboard. We cluster them and pick out the topics that were mentioned by multiple people or seem to be really important. While discussing them, we decide on the actions that will be noted. Once in a while you can run a fun retrospective (e.g., this Futurespective).
In addition to the main meetings of Scrum’s classic Sprint Planning, Sprint Review, and Sprint Retrospective, we also make use of the Backlog Grooming. During our two-week sprint, this usually takes place the week without the Sprint Planning. Ideally, this meeting is really about going through the backlog (starting from top or bottom). We don’t discuss details or implementation in very much detail. These topics are moved to the “parking lot” to be tackled later.
We also have other types of meetings — one of them I guess you could call a “Pre-Planning” meeting. A user story or Epic is not defined yet, but the product owner needs input from the development team. Usually there are two or three developers (interested/experienced in the topic) who participate in this meeting. Since they consider various options on how to shape a certain feature, they discuss several alternatives. That’s why we separated this encounter from the Sprint Planning meeting — it just doesn’t make sense to have the entire development team present for that.
Spikes are enabler stories. They mostly contain research, investigation, and prototyping competing solutions. After a spike, we typically have a spike presentation meeting which the product owner, as well as interested engineers attend. Those presentations are quite popular, because there is often something to learn, take away, or discuss.
With having all these meetings, we try to keep them as short as possible. How is this done? We already mentioned that some meetings only require a part of the Scrum team.
There are other measures though: It easily happens that the discussion shifts focus. While this may lead to interesting conversations it often distracts from the actual topic at hand and therefore prolongs the meeting. If anyone realizes this happening, he can use the magic word (ours is “Schnitzel” because what else should you pick?). He doesn’t have to explain why he feels the discussion went off-topic, because that would take more time. Mostly, everyone will realize that it happened.
There is one more rule we have: If you can’t contribute anything to a meeting anymore or you are very exhausted, it doesn’t make sense to sit in the meeting. Therefore, you can leave! Maybe it is an exception if you are running the meeting.
What do you do differently or similar in your Scrum? Feel free to share your thoughts!
