Agile at the university
Marc explained previously how the UCL computer science department runs their student project as an agile project: teams of 4 students develop an Android application of their own choosing. Professor Yves Deville acted as the customer of the team, Marc Lainez provided agile coaching and the teaching assistants acted as onsite coaches.
Shortly before the final release of the projects, the university invited Agile Belgium to attend the Show & Tell of the teams.
Professor Deville explained the context, objectives and challenges of the project: this is a one semester project for 60 students in 15 4-person teams. The students are expected to apply cross-disciplinary skills required to design, build and deliver an application. The project is a practical introduction to both mobile computing and agile, which are new to most of the students. Agile is new for the teaching staff too, they’ve only had a few introductory sessions about agile.
Marc Lainez, who had presented agile sessions before at the university, and Agilar helped the teaching team to devise a simple agile process. Every team used the same process and constraints. Octo Technology provided their Appaloosa private app store so that students could publish application updates for their customer, coaches and beta users.
Running this project in the university with little agile experience entailed accepting some compromises:
- Automated testing was recommended but not mandatory. Very few teams had any automated tests, which could pose a problem when the applications are developed further
- Pair programming was recommended, not mandatory. In their retrospectives the students gave feedback on when they would and wouldn’t use pair programming
- Because the project didn’t have a dedicated room for kanban boards and other information radiators, the teams used an online tool to track progress and collaborate
- Although the students came up with the ideas for the products, the professor acted as their customer.
- Because neither students nor teaching staff worked on the products full time, coaching and retrospective time was limited. For example, there were only 30 minutes per team to perform an iteration retrospective and getting ready for the next iteration.
The teams and their product
The first team presented CheckMyBeer, a beer guide and rating application. They liked pair programming and Trello for collaboration and communication and were very motivated as they worked on an application they had chosen. The regular sprints helped them to deliver and avoid “student syndrome”
The second team developed the “Bouboule” game. They also found the project very motivating and liked the prioritisation, estimation techniques and opportunities to change course that agile gave them.
A third team developed “LLNCampus” a friendlier and more integrated view on the existing data on the campus website. This has the potential to become the premier way that students get information about courses, lecture rooms and facilities on the campus.
The next team developed “Safe Area“, a tool that provides different techniques to keep confidential information on the phone (like keys, codes and passwords) safe. Special mention to the value of regular and fast feedback from your clients and users.
The final team presented “Treasure Hunt”, an application that allows you to script small “adventures” so that you can create treasure hunts, touristic information or travelogues. Again, the value of rapid customer feedback allowed them to refine their original idea and take their product into unexpected directions. We often discover what an application is (also) useful for by using it. You may discover a whole new market and then “pivot“, as the cool kids say nowadays.
All the teams have been able to develop and publish an application, using a new methodology and new technology while having only a limited amount of time. There’s never enough time, you discover what your customer needs as you go along, there’s technology churn, tools don’t work as expected, there are team issues… It’s just like real life.
You can find all the applications on the UCL/INGI developer page.
Overall, teachers and students seemed happy with the agile approach:
- Regular customer feedback made it possible to focus on those few features that really add value, instead of trying to force in all the features you’d imagined needing at the start of the project
- The customer and coach roles took a lot of time from the teaching staff, but that investment provided value in steering the project and resolving issues. Having a bit more time for retrospectives and sprint preparation would have been useful. One customer, two onsite coaches and one meta-coach all working part-time on the project is not a lot to follow up 15 product teams.
- Despite the effort required by the process, the structure in two-week sprints clearly helped to focus teams and even out the workload. No more last minute late night hacking sessions. Well… a lot less than usual
- Teams experimented with agile practices. Some teams fully applied pair programming, others only used it in some circumstances. Some teams liked standup meetings, others didn’t need them as they paired and collaborated so much already. The important thing is to know what the techniques are, how they work and why you would use them so that you can decide what to use in your context
- The teams managed to get a product from scratch into the Android marketplace in a few weeks of part-time work. Impressive.
This is a great initiative by the UCL. I wish more schools and universities allowed their students to experience an agile project. I can only dream of students entering the workplace with a successful agile project under their belt and who think this is the “normal” way of creating products. Professor Deville and Marc Lainez will publish their experiences in a paper so that other universities can learn from the experience. We’ll let you know when the paper is available.
If any other universities or schools want to know more about agile, the Agile Belgium community is here to help. Contact us.