Skip to content
Home » Blog Posts » Traditional software engineering is insufficient

Traditional software engineering is insufficient

Teaching students regular software development practices is unhelpful, so teach them to collaborate as a team.

When teaching people how to do software engineering and software development, people follow several approaches. They use the regular project management approach, with an emphasis on software, ie the waterfall approach. Alternatively, they focus on an agile approach, must commonly using scrum.

Both of these approaches offer solutions that you can use in the classroom to teach students how to build a software product. They cover the basics, and have proven track records. Plus there are many text books that can be used too. However, as we’ll see, they leave out some key things.

Photo by Lala Azizli on Unsplash

The project management approach

When you teach students the project management path, then you cover all of the usual things: requirement gathering, designing, planning, building and then maintenance of the work. Focus is on planning, so that everything is accounted for at the beginning.

Software development and engineering is added along the way. We create documentation, which can used to guide each stage of the process. We also aim to estimate everything is detail. Work breakdown structures are organised, and maybe PERT diagrams are used, along with some critical path analysis too.

Some of the general concepts work well enough. It is useful to explore what the plan might be for the development of the work, so that linked components can be identified. Similarly, some notion of estimates is useful to know how long a phase might take as you plan and compare potential approaches to the work.

The parts that don’t work are the transformation of estimates into commitments, and the assumption that people are interchangeable in the work. Similarly, the idea that someone can plan the development work for a person in three-months time, and assume that it will still be viable is wildly optimistic.

The agile software engineering approach

The agile approach in textbooks normally follows a scrum process. The students learn the process, the roles, the ways of work, and the cadence of sprints. This allows for learning about the product to be incorporated into the ongoing work.

This is an improvement on the traditional approach. Students learn to think of the big picture. They also explore how to build this as a series of small potentially shippable components. Now there is space to enable changes to the big picture as the team learn about the potential product as they build it. They are working with smaller batches of work.

This approach still poses problems. Students become fixated on the formalities of scrum, without appreciating its flexibility. They also tend to turn estimates into commitments, which causes undo stress.

Neither addresses how people should work together

Both the project management and scrum approach ignore how the team should work. Yes, they discuss roles within the team. The project management side sees a project manager making decisions, and allocating work to team members. This is command and control.

The scrum approach sees more decisions being made by the team. It is silent on how the team does the work together. Scrum leaves out practices.

As a result, teams do what they did before: People work individually. Then they hand off work to another person. When you do this you discover issues late. Problems are other people’s concern. Each person does their part. The team is surprised when issues arise.

Show students how to collaborate as a team

The part that’s missing in both of these approaches is teaching students how to do the work as a team. They will bring what they know from their own experience, which might not be much. This is probably the first time they are doing a larger piece of work as a team.

Alongside your normal teaching of software development add the collaboration phases, and the collaboration rules to guide your students. This will mean they gain experience in using small batches to build thin vertical slices of work to gain shorter feedback loops.

By doing this you can show them where they can make decisions about how they do the work. They can try different approaches, and gain from the experience. Being able to collaborate in a team is a professional skill. This makes them more prepared for whatever they do after graduation.

How will you teach your students collaboration skills in software development?

You can find out more about this in the my other posts, and in my book Teaching Team Collaboration.


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.

Cookie Consent with Real Cookie Banner