0

What is a QR code?



We have chosen to base our Augmented Reality realization on QR codes.

QR codes were invented by Toyota (the car manufacture) in 1994 as an improvement over traditional barcodes. QR codes were developed to have high data density and to be easy readable (by computers).


A QR code consists of 3 corners (4.1. Position in picture to the right) that allow us to find the correct orientation for the QR code. Then the QR code consists of some data with further structure, which I will ignore here. The actually data of the QR code, i.e. the text, is encoded with error correcting codes inside the QR code.

We use the open source project ZXing (Zebra Crossing) to decode our QR codes. The detect-and-decode loop of ZXing first detect the corners of the QR code, then the image is rotated and stretched (if needed) and finally the contents (the text) of the QR code is decoded.

Reading a line of pixels from a corner of a QR code we first encounter a black dot, then a white dot, then 3 black dots, then a white dot and finally a black dot.
This pattern (1-1-3-1-1) is crucial in detecting a corner of a QR code. The pattern is used by ZXing to detect candidates for corners by counting black and white pixels. These candidates are validated by checking that the pattern is found both vertically and horizontally.

In a future blog I will write about how we have adapted the ZXing approach to suite our Scrum Board needs.


See the Vodafone board solution




Finding a way to track changes



Users are key in the development of technical solutions. So having explored the challenges of existing scrum practises, we set out to find a technical solution together with one of our case companies, Mobilethink.

While preparing a workshop with the people from Mobilethink's development team, we stumbled across a similar initiative developed by the Vodafone Web Team in Copenhagen.

They had developed a solution where they used RFID tags to automatically update task changes in Jira. The solution was super cool so we persuaded Ole Højriis Kristensen, the inventor of the board to  participate in the workshop and share with us his experiences with the development of their tool.

One of the things that impressed us with the Vodafone project was how the development of the features had sprung directly form the everyday needs of the developer's and that the board had become a key in the ungoing development of their scrum processes. We liked the idea of a flexible solution could hook up to any scrum tool - be it Jira og Excel, and where it would be easy for the developes to add new features that supported the needs of each specific development team.

However, the Vodaphone solution was based on RFID tags and this meant that they had an ungoing task of coupling the RFID tags to the physical task notes. A process that was laborious for the scrum master.

We det out to find an alternative technical solution and ended up going for the QR tag.


Maintaining the scum tool is a burden!



Our case studies confirmed our prior experience that scrum tools often end up being a burden for the developer rather than a tool for support.

Developers repeatedly stated that they liked the traditional physical scrum board and that they saw maintenance of the scrum tool as an extra burden, that was pulling their attention away from their develoment tasks. Furthermore, we saw that the introduction of the computerized scum tool into meetings tended to remove the dynamics and collaborative spirit from the meetings and reduce them to mundane maintenance sessions.

We also saw how important the physical board was during their daily work activities. The board provided them with an ongoing overview of the project status. An overview they expressed they lacked without the physical board.

So the challenge for us was to find a way to bring the physcial board back into the scrum meetings and find ways of tracking changes on the board.


Defining the challenges



The first thing we did before even thinking of technological solutions was to make two case studies in two different organisations working with agile software development, Mobilethink and Danfoss.

In the Alexandra Institute we have a strong focus on User Driven Innovation and we used the case studies to define the challenges and explore the needs in the organisations.


The case studies were designed as ethnographic studies in a three different development teams. We did not just look at how they used their tools, but made a broad examination of their work and collaboration. We looked at their daily collaboration and studied scrum meetings and sprint planning and review. And by being present in the office environment and attending meetings we got an impression of the atmosphere and the cultural and managerial traits of the company


Understanding the challenges

We did this to get a deeper understanding of the challenges at play in the organisations and it helped us define what challenges to focus on in our work – so we would not end up with the classical failure of trying to make a technological fix to an organisational problem.


Helping organisations develop

An interesting by-product of our studies in the two organisations was that we found out that this kind of ethnographic study is also a strong tool for organisational development. In both organisations we presented our results to managers and employees in the company and facilitated a workshop where we talked about challenges. And while we used this as an input to the design of our solution, it also became an opportunity for the organisation to reflect on the way they worked and collaborated and spurred of new ideas and enthusiasm about how to improve their scrum process. So while we have been developing a new kind of scrum tool, we have also created a new way of helping organisations getting the most out of the adaptation of scrum in their organisation.


The Technical Set-up



As seen in the video, the current setup is pretty bare. The running prototype consists of a old 2009 Macbook Pro, a standard projector, scrounged from a office supply room and a fairly highres webcam (5 Mpixels) from Logitech, more precisely a Logitech C910. We use the projector shows the board as well as feedback on the wall, while we track the tasks using QR-tags. 

The whole setup is running in Java in an Eclipse environment, using JavaCV for image grabbing and handling, while using XZing for reading the QR-tags. These software libraries have been choosen based on the experiments during the startup, where we found these to be the best for our purpose. Though at the moment we are looking at replacing JavaCV with something lighter, as we are only a fraction of the library for our work. Parallel with that development, we are actively working on improving ZXing for our needs, improvements we plan to hand back to the ZXing community.

The reason for choosing the C910 as a camera stems from the earliest experiments, where we tried to use the internal webcam on the Macbook Pro. We wanted to make sure that we could read the QR-tags from a distance, so we choose to invest in a camera with the higher resolution while still keeping the overall cost of the system low. At the moment we are wondering if there is a need for such a highres camera or if we can handle the issue in software.


See how the board works






Project Background



The point of departure for the interactive scrum board project was a shared experience that the existing Scrum tools primarily are designed to support project management and do not sufficiently support the developers’ work processes.

Delta, who are specialized in agile processes and have long experience in helping organisations implement scrum, were the one’s to make the initial proposal. We at the Alexandra Institute did not hesitate to go along. Over the past years our New Ways of Working Lab has made at number of work studies in software companies, and these studies has shown that developers often felt burdened by having to update their scrum tools as well as going to scrum sessions. And that the introduction of a technological scrum tool into the scrum sessions often were having a damaging effect on the dialogue and knowledge sharing between the developers.

The purpose of the project thus became to investigate how to better support the developers and teams and come up with new suggestions to a more suitable solution.

Over the next couple of weeks we will report on the initial results of our investigations. We will also present the technical solution we have come up with and tell the story about decisions we have made and challenges we have met during the past months.





InfinIT er finansieret af en bevilling fra Styrelsen for Forskning og Uddannelse og drives af et konsortium bestående af:
Alexandra Instituttet . BrainsBusiness . CISS . Datalogisk Institut, Københavns Universitet . DELTA . DTU Compute, Danmarks Tekniske Universitet . Institut for Datalogi, Aarhus Universitet . IT-Universitetet . Knowledge Lab, Syddansk Universitet . Væksthus Hovedstadsregionen . Aalborg Universitet