Students need to be holistic in their approach to software development.
Software development looks ‘obvious’ to students in software engineering courses. You gather the requirements, decide upon the architecture, and the languages you will use. Then you plan out who will do what in which order, and start. The ‘tricky’ parts are learning how to do things that might not have been covered in previous coursework. Maybe they need to learn authentication, or more complex queries to the database. From this perspective software development is a technical challenge.
This perspective leaves out many important perspectives. There are issues around testing, deployment, product development, as well as team dynamics. Each of them has an impact on how the team develop their application. From my perspective as many of these as possible should also be included in software development. They all come down to people talking to each other.
Gathering and evaluating requirements never ends
We should start with the requirements. Students tend to assume their clients know what they want. This isn’t always the case.
If the students are their own clients, then they will know even less than they think. There are always assumptions that need to be validated as the app is developed. Ideally, these should be clarified before the team starts to build the product, but in their eagerness to start that can be a hard sell.
When students have a real client, then they assume the client has all of the answers. It surprises students to learn that clients know only that they need ‘something different’. Yes, the client has some requirements, but they are also unsure about how the parts will fit together. The students need to ask lots and lots and then some more questions. The students are reluctant to do this, and are surprised too that they need to ask so many questions. Surprised, even when told they will need to ask lots of questions.
They also find it surprising that this is only the first round of requirements. They forget that development is a learning process for them and the client. As they develop the app, they should be validating assumptions, which might mean a change in direction.
To do this well, they also need to be testing their code and deploying their work. Until there are tests for the code, any changes might break the build. Until they deploy their work, they can’t make it available for their client, or customers to use.
Tests speed development through effective and fast feedback. Deployment early makes it easier to deploy as the app grows. The team might also discover ‘surprise!’ that their assumptions about deployment won’t work as expected. Finding this out early reduces risk.
These are also reasons why the team should develop their work in thin vertical slices. If they are small, and wrong, then they are easy to modify. They also haven’t spent too long going in the wrong direction.
The team needs to clarify how it will work
As I’ve mentioned previously, the team can either collaborate, or coordinate its activities. The former is more productive, but the later is the default for many students. Until the team decide to collaborate, the work will drag on slower than they wish.
Coordination means feedback is slower. The team has to wait for team members to report, or check in their code. The team might also be waiting for the client too.
Collaboration speeds up this process. People are sharing their work more quickly, and are also talking to each other more. Issues are discovered, and fixed, sooner.
Teams that talk more work more effectively. This applies to everything. The solution to all of the challenges above are having the team talk more to each other, and with their clients. If the team are their own client, then they also need to talk to potential customers or people who would use their proposed system. They need to talk to them to validate their assumptions.
Use this in your classroom by having students discuss how they can collaborate
The key to the puzzle presented at the beginning is to have students realise that software development requires more talking to each other and their client than they assumed was required. You can illustrate this with a few exercises.
I like to use James Shore’s ‘Offing the Offsite Customer‘ exercise in one session to show students the challenges of gathering requirements. This also shows them that it works better if they talk directly with their customer and ask lots of questions. I shorten this by skipping the step where a customer writes out the instructions, and start with a separate business analyst, who describes the vision to the developer.
You can also have teams discuss how they want to work together, and then have them review this after a suitable interval. They should know they can change their work patterns as they learn more about what they’re doing. This is part of continuous improvement.
I benefited from teaching two separate courses: one on software engineering, and another on human centred design. The later focused on teasing out assumptions on what the business application would deliver to people. The biggest surprises in that course were the session after each team talked to potential customers/users/etc and discovered their assumptions were wrong. Mostly they also discovered other opportunities they didn’t know about too, so it worked well. Maybe there is a course like this that you could tap into too?
In the end, get them to talk to team members and their clients and things will improve.
This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn
The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration.