Students reported having to commit a lot of time to meetings and points of process (and documenting these for assessment) which they felt was taking time away from “actually getting on with the project” by which they meant “writing the software”. Our teaching had begun to centre on the mechanics of agile methods and the software engineering process rather than the
underlying principles. By requiring students to complete the rituals and ceremonies associated with a process like Scrum, and assessing them on how they were doing these, we had diverted from the original spirit of agile development. While we still believe that agile methods are vital for modern software projects, our mistake was to focus on students completing the process “correctly” rather than on satisfying the customer or delivering early and continuously.

The feeling that a focus on how agile practices are carried out can be an obstacle to completing a project effectively is not unique to the classroom. The use of “agile” in industrial software development continues to grow, but the practices and processes adopted by many teams can be far away from what the authors of the Agile Manifesto originally envisaged.
As Allen Holub put it: “The word Agile has taken on a meaning
that the folks who coined the term at Snowbird wouldn’t recognize … You can implement Scrum perfectly, and not be in the least bit agile. What’s important, then, is agility, not Agile™.”

We felt the need to take a step back and redesign our course. While we do want to encourage the use of an iterative design process, and we do want the students to develop software, we want to shift their mindset away from the process and the technology, to focus on finding the right problem to solve, following user feedback. Coming back to the first principle of the Agile Manifesto, we want students to use the continuous delivery of valuable software to satisfy customer needs.

Working together with colleagues from the Royal College of Art, and particularly the department of Service Design, we have created a project-based course that combines user-research and design thinking with iterative software delivery. We call this course “Designing for Real People”.

Full details of how the course runs can be found in the paper Designing for Real People: Teaching Agility through User-Centric Service Design recently published at the International Conference on Software Engineering.

Here we will summarise some of our key points:

• At the scale of a university project, requiring teams to perform some of the ceremonies associated with common agile methods can feel like overhead to students. This can give the impression that agile methods get in the way of delivering a software project, rather than helping.

• Assessment based around process and ceremony may be easy for educators to implement, but it can send the wrong message, and can lead to students completing certain rituals just to tick a box, rather than helping and encouraging them to deliver better software.

• We changed our assessment structure to focus on whether improvements to the software are delivered iteratively and, crucially, how the product has evolved in response to feedback gathered from real users.

• At the end of each iteration we ask students for a set of video clips showing feedback sessions with their target end users. To produce these clips, they need a deployed, integrated, version of their software with new user needs addressed. We use the need to show feedback as a forcing function for the rest of the agile process. We don’t make practices and ceremonies themselves necessary to pass the assessment — we just recommend whatever seems useful to help the students deliver.

• We have found that collaboration between Software Engineers and experts in Service Design helped to focus students on meeting user needs, rather than pure technical achievement, but computer scientists naturally like their technology. Paired tutoring, where experts from both disciplines work together as equal partners, helped us to ensure that students paid equal respect to both the enabling technology and user needs.

Overall we are pleased with how this project has changed students’ focus, and allowed them to see the effects of iterating on a product in response to user feedback in order to maximise the value of what they deliver, and the impact that they can create in solving a problem.

Throughout the project students experience working in an agile way, but we don’t talk about named practices, or enforce elements of process. Our aim is to teach the principles of agility, rather than Agile™.

I gave a talk and facilitated a discussion on Education for Engineers, talking about how we at Imperial have been trying to create a curriculum for university students that teaches modern software engineering practices, and how we have used some techniques familiar from agile software development to iteratively improve our courses, and to try to increase the value of the time the students spend learning, for example by decreasing the batch sizes in which content is taught, and reducing the time to feedback.

It was good to talk to people working commercially in software development about what they would look for in developers coming out of higher or further education, as long with educators of various different types. There were people at the conference teaching in schools, in further education colleges, and working on professional development and training of engineers — so it was an interesting cross-section. One person I talked to had set up university student group projects with high school pupils as customers. Apparently they were quite demanding in their interactions with the developers, just like some real customers! I’m quite tempted to try and replicate that…

I will be working to ensure that the content being taught across all modules in the Computing curriculum keeps pace with the rapidly changing state of industrial practice, trying to make sure that the courses taught in the department cover the issues, practices, tools and techniques that students will find in industry when they graduate.

In doing this, I want to maintain and extend my professional network, discussing issues and problems of the day, looking at how work gets done in practice, what’s new, what works, and distill this back into the educational curriculum. I hope I can visit lots of teams working in different companies to see what they are doing. I’m thinking about it as field work to research the state of practice, and aiming to build bridges and create opportunities and links between the academic and the commercial world. Please get in touch if you would be interested in collaborating.

I’ll also be attending various conferences through the year, to find out about more new developments, talk about education, and discuss the state of practice with friends and colleagues.

I’m looking forward to it being a good and busy year!