Category: Meetings

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.

The project

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.

 

The coaches

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.

Looking back

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.

Thank you UCL computer science department, Marc Lainez and Octo Technology for making this project possible. Thank you to the students for their feedback on agile and their warm welcome.

Agile Games?

Some participants at the Agile Belgium Drinkup wanted to try out some Agile Games they had been talking about. As a pub is not the best place to play most of the games, Touring Assurances gracefully offered the use of their remarkable office in Brussels.

We started the evening by listing agile games we knew and dot voting to see which games interested participants most. Unfortunately, we couldn’t play many of the favourite games because they take too long or require props that we didn’t have available.

Play!

The best way to learn about Agile Games is to play them and debrief afterwards. This evening we played three games:

• Alan Cyment’s Multitasking Game to show the detrimental effects of task switching (facilitated by Yves)
• A version of the Matchstick Game (with pennies instead of matches because no one smokes any more) to illustrate the idea of bottlenecks and dependencies (facilitated by Pascal)
• Non-musical chairs to show team-organisation and improvement with retrospectives (facilitated by Bruno)

Participants were very serious and committed to play the Multitasking Game but soon broke down in laughter.

Looking back. Looking Forward.

The evening ended with a short retrospective to gather “What did you like?” and “What can we improve?”

There will certainly be a followup session where we can play some of the larger games. Watch this space, the Meetup group  or subscribe to the mailing list.

Want to know more?

Yves Hanoulle has also written a report about the event.

You can find more games and simulations at the following excellent sites:

• Tasty Cupcakes
• Agile Coach
• Agile Fairytales
• Innovation Games
• Lego Serious Play
• Agile Games Google group

Thanks to all participants. Hope to see you at the next Games Night.

Please, try this at home!