Possibly the best in Denmark
Ole Højriis Kristensen optimises everything he touches. As an agile project manager, he is a real geek when it comes to automating Scrum processes. Here he tells ConsultantNews about an award-winning intelligent Scrum board he developed in a project for Vodafone.
The Scrum Master’s most important task is to remove impediments for the team. For some, the most bumps in the road lie in the coordination with the business representative, but in my experience, the greatest challenge is much closer at hand. The tools the developers are given to work with are often themselves a barrier to reaching the team’s full potential.
The Scrum board is a good example of a potential impediment. You build a wallboard with stories on cards to give everyone an overview of what has to be done, but the wallboard often becomes outdated and ignored because no one has time to update it. Only the digital project management tool is updated. That does not make the wallboard’s original purpose less important – the big picture is always useful.
We in the IT business are fortunate in that we can create our own tools as part of the job. We can mould and adapt the systems we work with, as we wish, so they fit our working methods perfectly. The problem is that too few of us have realised this.
I was Scrum Master at Vodafone in 2010. We had several different project management tools that we rummaged around in to find the stories we were supposed to be working on. At the same time, we were supposed to make sure our colleagues in England and Ukraine could keep up with what we were doing. I created a large Scrum board to gain an overview.
Every day, I took pictures of the board and sent them to our colleagues abroad.
The effort to keep an eye on what had happened in the digital project management tools and then move the paper cards around soon became a huge chore.
If we were to be able to work efficiently, and if I as the Scrum Master was going to avoid being buried in paperwork and reporting, there was no way around it: We had to build our own tool.
The idea to cobble together a physical/digital Scrum board came when I first set up a webcam and then a projector in front of the board so I would not have to take pictures of it every day. It took a couple of months from the initial thought to the finished tool that could be used daily. But we continued developing it. For example, sitting around drinking a Friday evening pint, it struck us that it would be nice if the system could talk. It was our own tool and we were free to do whatever we wanted with it, whatever worked for us. It did not have to be beautiful, it just had to work – and that fact had a huge impact on creativity.
The result was a tool that could do everything. It could communicate effectively to the members of the team what they were supposed to be working on by means of automatically printed cards on a physical whiteboard. The developers could move the cards around and swipe their avatars to move stories and assign them to themselves in our digital project management tools. The board tweets progress updates in the sprint to our designers in London and our testers in Ukraine. It also took care of producing builds for our test environment as soon as a story was finished. And it read aloud messages from team members who were delayed.
It could do everything we needed. It was an ugly pile of PHP hacks and duct tape, but it worked.
And it has attracted a great deal of interest. I have described the digital Scrum board at conferences and have been interviewed for various blogs. The Board even won the Ultimate Wallboard contest run by Atlassian, which sells the Jira project management tool, among else. But almost every time I talk about the tool, I hear the same question: ’Where can I buy one just like it?’
The answer is you can’t and you never will be able to. Our board worked because we built it ourselves. We saw a problem and we solved it. We thought there was something wrong with the process, so we changed it. To me, that is the essence of agile development. This process is not right for everybody – and if you keep trying to push square pegs into round holes, you end up with a mediocre solution to a far too important challenge.
A typical Scrum team is usually professional and relatively expensive to run. But when companies are happy to splash out on company massage schemes and Artesian spring water in the canteen, developers should also be allowed to take a time-out from the job to build their own tools – tools that are tailor-made and so much more efficient than existing tools. The only problem is this happens far too rarely.
As for me, I drive a car with an automatic transmission. Why is that relevant? Because I look at agile development teams much the way I look at my car. I have no need to micromanage how the gears should move. I assume that a group of highly paid German engineers are better at that than I am. As long as I can control the direction and speed, I have no need to concern myself with the details under the bonnet.
Likewise, I wish more businesses would give their developers the freedom to decide for themselves how they want to work and which tools they want to work with. As long as we can agree on a common goal, it should be up to the individual teams to figure out how they can attain the goal in the best and fastest way.
Intelligent Scrum board time-lapse video.
