Keep removing risks to reduce uncertainty in your work
The software engineering textbooks, and the project management ones too that I’ve seen all suggest you do a risk matrix for your project. Set out the risks you can identify internally, and externally, and then rate their likelihood of happening, along with their severity. Combine these in a matrix to see the riskiest parts of your proposal. When you’re done with this, then you explore how you might mitigate or avoid the risks. They make it sound so simple.
It never is that easy. Especially for students. How do they know the difference between “I’ve never built a python web app before”, and “set up web server on AWS”? To some these look equally challenging. Both should appear in the risk matrix.
For the purposes of this post I’m focusing on the various tasks and technologies. I’m ignoring team related risks such as not knowing each other, team members keeping information to themselves, and similar issues. Those are somewhat covered by other posts.
Keep doing the next riskiest thing
I tell my students start with the riskiest thing first and work through the key ones until you’ve deployed your app on an external server. At the start of the project this might be learning a new language, or framework. Everything flows from there: build a thin vertical slice, and then deploy it somewhere.
By doing each of these steps the team learn the language, learn the framework, learn the architecture components, such as database, server, etc, learn how to move the code off their devices onto GitHub, and from GitHub to the external server. All of these are small steps for professionals, but big things for students.
Each step is also a risk for the team and its members. Some will be less comfortable with these steps than others. As the team does them, they also reduce personal risks too. The goal in all of this is to reduce risk now so that they avoid unpleasant surprises later.
Start the work
Depending upon how the team approaches the work, and breaks up the work, they might also add extra risks. For example, if they decide to divide the work into horizontal layers, instead of thin slices, then they add new delays, and possible risks. Now it will take longer for the database part to be connected to the server part, and for that to be connected to the frontend. I know, I know this is wrong, but teams seem to like to give each person one thing to do. I guess it makes sense at the time. The student who explained this to me last week, did realise that it would’ve gone smoother if the database and server person spoke to each other, and did the work together. They’ll know better next time.
Deploy a skeleton
With the basics underway the next normal risk is deployment. This always slows down students. They often shy away from doing it. I suspect it is a mixture of “that’s a big step; we’re not ready”, and “oh, people will see our work”. Fewer students see it as ‘”cool, I pushed something to the cloud that others can see”.
Students often underestimate the work involved in this step. This is why I want them to do it while the app is really small. As a small thing, there are fewer components, and it should be easier to oversee the parts and steps. By doing it now, it is easier, and they build a rhythm too of steps for deployment.
Stakeholder decisions
If the team has to wait for equipment, or decisions by their clients, then they should also start these discussions as soon as possible. The team should have a ‘plan b’ in place. Plan ‘b’ lets the team simulate, or prototype the work until they have the ‘official’ version. This ensures the team can write about their work and decisions in the final report, and also can show ideas, to aid their client, who might also be waiting for other people too.
Add tests – finally
Students seem to dislike adding tests, so I’m always happy when they FINALLY! do. This step alone removes risks and speeds development – as long as they keep adding more tests too. For many it is the risk of “we’re not sure how to add tests to this product” that holds them back. Once they start, they proceed more smoothly.
Rinse and repeat
In each new time box the team can add more features to the application. They can start to rest more easily that it will all come together ok. Students can apply the same concepts to their report too. Start the report early in the term so that notes can be kept all the way through. They can capture important design decisions such as why they picked library x to use instead of library w for generating their mobile CSS, or whatever.
By deploying early the team reduce their biggest risks. By deploying early they can also show their work to their client sooner to gain feedback sooner too. Then they can also start to spread knowledge within the team so that no one person is a single point of failure. This too is a risk, which they don’t like to discuss.
Apply this with your students
Get your students to reduce risks as soon as possible. Teach them to do the next riskiest thing. Get a skeleton deployed and then add more functionality. Get them to help see risks in their way of working. Gently guide them to better approaches. Help them learn to deal with risk so that they avoid unpleasant surprises later.
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.