Keep the development flowing to see product progress.
When developing products there is often a focus by students on the technical aspects, and a neglect of the human centred side of the work. Partially this is due to the work being done as a software engineering and not ‘startup entrepreneur’ course. Yes, students sometimes have to explain where the income would come from, but this isn’t always the case.
While this is a useful approach for teaching, it leaves students less capable after graduation, as they have the wrong impression of the drivers in product development. For computing students it seems to be about the technology and their development of the product. This means they don’t always understand that there are lots of assumptions being made about who will use the product, what the alternatives are, if they have the right balance between features, and how those features will actually make their customers/users lives better than the alternatives.
Development is a series of experiments
In practice product development is a series of assumptions and their validation. As each assumption is validated, or not, the team learns more. This feedback tells them to change direction, or keep going as they are. I’ve seen this happen in some of the software engineering teams: they’ve talked to potential users, validated assumptions. Sometimes they even change direction.
Being able to test these assumptions is only possible if and when the team is working with small slices of work. They can’t be too big of a slice, or they might do too much, and maybe throw the work away if an assumption is wrong. Small slices make assumptions easier to test. If it is wrong, then you can refactor it into the desired direction.
The flow of assumption testing is the goal
The team will learn most when it can develop a regular stream of assumptions to test as part of the development process. This means each deployable slice includes one assumption to test, however small it might be. In order for this to happen the team needs to be able to deploy their work so that people can use it, and provide feedback.
The longer the team goes without testing its assumptions, the more potential there is that they are going in the wrong direction. This is the scary side of development: developing work, and hoping that it is correct.
Teach people to deploy early to test assumptions
This is always a hard lesson to teach people. They worry it might be wrong, but don’t always do the right thing to deploy early. Some are arrogant and assume they are going the right way in development, even when they have no evidence for this.
Getting them to deploy, and validate their work, and then take relevant action to change direction, or keep going is important. Look for ways that you can teach your people to test their assumptions with early deployment.
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. Also available via Kindle.