WTF: physical scrum boards


On every scrum project I have the same discussions with the scrum master. Why on earth would we want to use a physical scrum board? I then hear some cultish praises of awesomeness in favour of the physical scrum board and total neglectance of any arguments against it. That goes so far that the scrum masters seems to be experts on office supply brands and field tested ripping-off techniques for post-its. People start writing information (about two words from a 200 word description) from a ticketsystem on a post-it and making photos of the physical scrumboard to re-digitize it.

  • But, …. Haptic Feedback!!!!
    Unless we start building software solemnly using lego-bricks I think programmers can handle the abstractness of data on a screen. There even are f….in touch screen TVs in most office’s
  • But, …. the big picture!!!!
    Nothing easier to see what you planned to do as to dive into a sea of two word 10x10cm paper pieces written in bad handwriting
  • But, …. everyone can see it!!!!
    Unless there is a wall in between or the atlantic ocean
  • But, …. you shouldn’t define stuff upfront anyway, speak with people!!!!
    Yes, it is always the biggest problem, that specifications are too clear and it is not at all a problem, that most people have the long term memory of a goldfish.
  • But, …. SCRUM!!!!
    When it comes to SCRUM people act like in the german tale “The Emperor’s New Clothes” . Noone speaks ill of SCRUM because questioning it makes you the village idiot who just does not understand. There is an unexplainable fear of throwing away stupid stuff and keeping the good stuff.

In all companies I worked the companies had ticketing systems (Jira, Redmine, etc.) where bugs were tracked and the feature backlog was maintained. Detailed bug reports or feature requests resided in these systems. Ok, not detailed from the start, but after some clarifications which were all visible in the ticket history the topics were quite clear. Now instead of using perfectly fine digital scrum boards like the Jira agile plugin or redmine-backlogs which have the classical swimlane views and automatically generate all kinds of statistics out-of-the-box some coked up scrum masters start writing down ticketnumbers (if you are lucky) and parts of the ticket title (most times not even the whole title fits) on little yellow paper snippets and glue them to a wall. Then after every sprint meeting they have to note the current progress, do the sprint calculations and publish them somewhere. As this step is extremly unnerving most scrum masters I worked with just didn’t do it. As a developer you have to frequently update ticket contents and of course read them to know what you are doing. So what you are doing now is writing down the ticket numbers from the post-its and looking them up in the ticket system.

So the question is, why would a sane person suggest doing stuff like that. I have several explanations:dawn_of_man

  • no paper trail: (paper trail as in “documented state”, because ironically you will have lot’s of paper 😉 )
    Battles with upper management may cost a lot of time and decrease developer happiness. So having some overcontrolling boss crawling through the tickets of the last couple of months and arguing about estimation points, etc. is an obstacle for good software development. Post-its are like snowflakes, everyone is different and they melt when you hold them in your hands (or let’s say after a sprint). No paper trail, no discussions. Countering bad management, with bad project documentation is not a good plan. The scrum masters should put take one for the team and keep these discussions away from the developers, without obfuscating the whole development process.
  • perceived transparency: Anytime someone asks about the development state, you can say: look it’s all here, just see our beautiful loom on that wall. The asking person will see colorful papers and a wall, things they understand, but not the meaning behind them. For the developers who have to work with that it’s the same, but they consult the ticket system. Just explain the digital scrum board on a beamer to a non-digital person or give them a percentage value (60% done, this is something everyone understands).
  • lots of manual non-computer-action for the scrum master: Sometimes I have the feeling scrum masters need something to do between the meetings. To show they are really doing something ideally that thing should be visible. What would be better than having some non automated artwork which you glue to the office wall? Noone else wants to do that anyway. The real job of getting familiar with a complex ticketing system and tuning it perfectly to the team’s needs sounds like a harder job.
  • cult like devotion to the word of the lord: As the pattern I encountered is always the same: physical-scrumboard, no discussion about that, showing the correct rip-off technique for post-its, etc.. I assume that is something they get teached at scrum-master-school and feel the need to follow these rules without questioning.

So what I propose:  If you already have a ticket-system which supports digital-scrum boards. Start with a digital scrum-board, do your standups in a conference room with a beamer. Be honest about what a physical board just can’t deliver. If more than 50% of the people think it is a good idea to switch to a physical scrumboard, then switch back.

I would like to invite anyone to discuss in the comments section. Especially die hard physical board lovers, I would love to see some good arguments (backed by real life stories) for physical scrum boards.

Digital Scrum-Boards

If you know other good digital scrum boards, please add a comment and I will add the link.

Jira Agile


Redmine Backlogs

Plugin for the redmine ticket system


Integrates with github


Integrates with github


pixelstats trackingpixel

Leave a comment

Your comment

Time limit is exhausted. Please reload the CAPTCHA.