Teaching agility, not Agile™
The first principle of the Agile Manifesto states that “our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. As with many universities, over recent years we at Imperial College London have developed and evolved modules that aim to teach agile software development, with student teams working to deliver a system to meet a customer’s requirements. However, we realised that the students’ focus was often on the technical complexity of the software produced, regardless of how well it met the users’ needs. At the same time, a common theme in student feedback from end-of-course surveys was that agile practices felt to them like baggage and distraction.
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™.
