In the previous post, related to my ICSE’19 paper on Dual-Track Agile in Software Engineering Education [1], I focussed on the question: Why do we need to teach Interaction Design to Software Engineering students?
This post addresses the next question: How could we teach Interaction Design while staying away from “Big-Design-Up-Front”?
The proposed answer is situated in the context of a course aimed at enabling students (who are doing a Master of Science in Software Engineering at Carnegie Mellon University in Silicon Valley) to design and implement software systems that at once useful, usable, and enjoyable to use, while making a unique contribution to society. This is done by introducing Interaction design (IxD) and Software Product Management (PM) in the context of dual-track agile.
Note that I am referring to Software Product Management (PM) versus Requirement Engineering (RE) simply because nowadays product managers are often the ones who write and prioritize requirements (like user stories), with a goal of organizing the work to support development.
Introducing New Practices
Teaching IxD requires introducing new practices, including for instance Contextual Inquiry, Affinity Mapping, Persona Modeling, Storyboarding, Design Walkthrough, Brainstorming, Ideation, How-Might-We, Sketching, Prototyping, Think-Aloud Usability Testing, Usability Testing, Heuristic Evaluation, Style Guide, and so on.
For students, like mine, who have some experience in software development but no experience with IxD, learning those practices could be challenging and time consuming (specially when they involve collaborating with stakeholders). So leaning to apply the practices effectively is going to take most of the semester, with limited time for implementation and iterations. Given that situation, the challenge is: How do we stay away from teaching “Big-Design-Up-Front”?
Staying Away from “Big-Design-Up-Front”
When I first joined Carnegie Mellon University in 2012, I taught an existing course on Requirements Engineering that introduced some IxD practices with no implementation. As a result, and even though no specific software development process was mentioned, the students’ perception was that we were talking about “Big-Design-Up-Front”.
To address the problem, when asked to create my own new course in 2015, I decided to add the implementation of a Minimum Viable Product (MVP) and to frame the work in the context of an iterative process. I called this process the Double-Wheel, as it was my adaptation of the Wheel from the UX Book [2], with IxD practices covered in the first wheel and the implementation of the MVP in the second wheel. However, because the new IxD practices and MVP implementation were done sequentially during the course project, the perception was still “Big-Design-Up-Front” for some students.
Finally, last semester, following an empirical study at a company called Pivotal Software [3], I replaced the Double-Wheel with Dual-Track Agile, to better reflect what we observed in industry, and I introduced some concurrency between the IxD practices and the MVP implementation. Even though the concurrency was only minimum, these changes managed to eventually shift the perception away from“Big-Design-Up-Front”.
Introducing Dual-track Agile
To introduce dual-track agile in the classroom I came-up with a model that simplifies the messy reality for students, as illustrated in Figure 1.
Fig.1: A simple model of Dual-Track Agile for students
The model includes two tracks. The first track is about discovering what functionality to build. The second track is about delivering those functionalities. The two tracks run continuously and in parallel. This is about continuous product discovery and delivery.
The red activities are led by interaction designers, the green ones by product managers, and the blue ones by developers. The colors do not represent silos but one team with multi-disciplinary skills. Any team member could be involved in any activity.
Dual-track agile is introduced during a semester-long project. The students propose their own projects by identifying product opportunities with unique contribution to society (the domains covered by students so far include education, food waste, homelessness, medicine, natural disaster relief, recycling, traffic congestion, and the elderly). Students auto-form their teams of 4 to 5 based on project interest. They recruit their own stakeholders.
Starting with their own opportunity, and working closely with stakeholders, each team performs five tasks during the semester. The tasks are presented below.
Needs Elicitation
First, students do some research and analysis to understand the stakeholder’s needs (as illustrated in Figure 2).
Fig.2: Needs Elicitation
Conceptual Design
Second, students start to apply design thinking to generate solution concepts and validate the concepts with stakeholders (as illustrated in Figure 3).
Fig.3: Conceptual Design
Solution Envisioning
Third, based on the best concepts, students define a long-term vision for the product and a MVP for implementation. They also validate their vision with stakeholders (as illustrated in Figure 4).
Fig.4: Solution Envisioning
Prototyping & Backlog Preparation
Next, students create a prototype for their MVP, validate the prototype with stakeholders, and prepare a backlog by creating and prioritizing stories (as illustrated in Figure 5).
Fig.5: Prototyping & Backlog Preparation
Continuous Product Discovery and Delivery
Finally, students do not only build the MVP that is reviewed by stakeholders, but they also go back to Discovery to identify the next valuable product increment, prototype the increment, and create the corresponding stories (as illustrated in Figure 6).
Fig.6: Continuous Product Discovery and Delivery
That way, the team knows what valuable product increment should be implemented next and gets a taste of the continuous and concurrent nature of product discovery and delivery.
Limitations
One of the limitations of the course is its reliance on a pre-requisite course, called Foundations of Software Engineering (FSE) [4]. FSE focuses on “traditional” agile development and the related development practices and technology.
This pre-requisite allows me to teach dual-track agile without having to worry about continuous delivery and while allocating enough time to teach the new practices related to product discovery.
References
- [1] Cécile Péraire. “Dual-Track Agile in Software Engineering Education”, 41st International Conference on Software Engineering: Software Engineering and Education Track, ICSE-SEET (2019). Available online.
- [2] Rex Hartson and Pardha Pyla. “The UX Book: Process and Guidelines for Ensuring a Quality User Experience”, 1st ed. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc. (2012).
- [3] Todd Sedano, Paul Ralph and Cécile Péraire. “The Product Backlog”, 41st International Conference on Software Engineering, ICSE (2019). Available online.
- [4] Hakan Erdogmus and Cécile Péraire. “Flipping a Graduate-Level Software Engineering Foundations Course”, 39th International Conference on Software Engineering: Software Engineering and Education Track, ICSE-SEET (2017). Available online.
