Teach people to reduce risk

Keep reducing risk to remove ambiguity and shrink the cone of uncertainty

Software product development risks come in many shapes and sizes. You can teach them to reduce and mitigate most of them with a number of simple approaches.

I find it frustrating that teams keep ignoring them. They don’t deploy early because “it’s not ready yet”. They build their application in layers, because “it’s easier to divide the work”. They will research the new technology “a little longer and add it later”. You have probably heard all of these too from the people you teach.

Photo by Thom Reijnders on Unsplash

There are other technical risks, that will be individual to each product, such as which provider to use for hosting, and how you’ll manage third party licences, or other issues, which might be decided by others. We’ll ignore those and focus on the common things of many team collaborations that are easily within the team’s control.

Let’s start with the obvious tech related ones, before we explore the risks teams ignore within their working practices.

Deploy early while the app is small

Teams like to save deployment until ‘later’. The team waits for a sizeable version to be ready to show to the client, and then they start to consider where and how they will do this. At this point there is normally a deadline for the ‘review’, which adds to the stress, along with the size of the application too.

A better approach is to teach them to deploy something as soon as possible. I always walk through an exercise where they deploy something to an external server, so they know the basics. Then they know how to deploy, and just need a push to do it.

The team might only deploy a single page, or screen at first. There might be no functionality. Nonetheless, this is still a good achievement. The team now have a deployable version, which runs ‘on someone else’s server’, or mobile. The team know how to bundle the libraries and other components for deployment. They did this while the application was small, so there is less overhead in thinking, and talking about it at this point too.

Deploying early removes the ambiguity of deployment, and helps build a shared understanding of what’s involved as the application grows.

Explore and apply new technology sooner

Teams working with a new technology, framework, or library often hesitate, and “do one more tutorial, or watch another video”. This postpones the uncertainty of knowing if it will fulfil its intended role in the application. It also often slows down the development of everything, while people wait to see if this component will work.

Teach people to create a sample example as they learn. This lets them stop as soon as they realise it will not work as expected. It will save them time compared to doing yet another tutorial that doesn’t address their scenario. Teach them that the sooner they apply the ‘new’ thing to their context, then the sooner they can share what they learn sooner with the team, and thus reduce the ambiguity around this component.

An alternative would be to remind or teach them the XP ‘spike’ (or maybe spiral approach), where the whole team build a small version of something together to see how, or if, the parts work together. Build it, learn it, and then throw it away and build the real version that you need. In any case, the goal is to confirm assumptions.

Address the biggest outstanding risk each sprint

Teams focus on the features of their application. This makes sense, as these are the parts that help the users. It doesn’t make sense if there are other unknowns waiting to be addressed.

Teach your people to look ahead as they plan each sprint, or time box, so that they remove ambiguity in the application as soon as possible. They don’t need to address the whole feature that uses this unknown library, third party software, or whatever. They just need to ensure they explore it enough to reduce the risk it represents.

That’s how you should teach people to handle the technical side of products. We should now look at the risks that are often ignored in the team itself. This is where so much can be improved upon, as effort is sadly wasted.

Share your code earlier rather than later

I often see people holding onto code on their device, because “it’s not done yet”. This means no one else in the team can see their work. No one can use what they’ve done so far. By not sharing their code they also run the risk of losing it if/when their drive fails due to water, coffee, or other intervention, which means they no longer have the device.

Teach people that code needs to be committed to the repository regularly so that it is off their device. If it’s in the cloud, then they don’t lose your work when they spill coffee on the laptop.

Remind them to that code needs to be shared with their team via commits to the remote repository so that they can use it sooner rather than later. This means they can provide feedback on variable and method names, and signatures, so that they can improve their code to work better with the other code they’re working on. Collaboration requires communication and cooperation. Sharing code aids shared understanding of the whole.

Merge code regularly to the main branch

Individuals on the team sometime like to work in a separate branch in the repository. It is good that their work is safe on the remote server. It is bad that it hasn’t been merged into the main branch yet. The longer it sits in a separate branch the more stale and dangerous it becomes.

Keeping the integration meetings infrequent also slows down the learning that comes from integrating each others work. These teams seem to feel that if it hurts we should do it less frequently. Actually, if integration, or testing, or deploying is painful, then the team should do it more frequently so that it becomes less painful, and easier to do.

Teach people to regularly merge their code into the main branch. It is only when code is merged to the main branch that the team discovers issues. The person might’ve used the wrong method names, or forgotten to include a parameter in a method, which they only discover when they merge their code and find it doesn’t work as expected.

Teach teams need to merge their code regularly, daily at the very least. Make daily merges to keep merge conflicts to a minimum. This also means the rest of the team see the code sooner.

Teach them to build their application in small slices.

Test early and keep adding tests

Students prefer to add tests later. Students think adding tests will slow down their work. They think that by writing another feature, instead of tests for the code they just wrote, that this will speed up their work. They don’t realise that they now have more code to watch than before. They check everything works by manually going through things. This is so slow.

Teach teams to test early so that they have an early warning system to validate new code works and hasn’t broken the old code. Remind them that tests confirm that merged code hasn’t broken anything. If they automate the tests, then this goes quickly, and saves time.

Part of this is also the related issue of code refactoring. With tests in place it is safe to refactor the code to remove technical debt and know that everything still works fine as they make their code better.

I often read later in the team report that the team wishes they’d started testing earlier. Always. I also keep reminding them of this.

Share knowledge within the team

I sadly find teams like to work individually on tasks within the team. They might talk to each other daily, but they work on their own. They think this is a good way to work. Teams that work like this also seem to integrate their code infrequently too. This slows down the feedback loop within the team as already mentioned.

Working individually produces individual experts on parts of the application. As the application grows each expert finds it harder to help the others as they become unfamiliar with the code outside their area. If the person leaves, or has an accident and can’t contribute, then the team needs to learn that part of the code.

Teach people that it is better to work in pairs. In pairs they are not on their own so they can share ideas with another person if stuck. It means another person sees their work immediately, so feedback is instant. Working with a partner keeps you focused too. You now have two people who understand this part of the code too.

Changing partners for pairing is a good addition to this practice as it spreads knowledge and shared understanding across the whole of the team.

It is even better if you work as an ensemble, or mob for your work. Now everyone is helping each other as you focus on the most important component at the time. This brings all of the best ideas and thoughts to the challenge. Plus everyone knows this part of the code too.

Teach people to reduce external and internal risks

As you can see there are lots of risks within the team’s circle of influence. They can address these to improve their work. They will reduce risks, and improve the quality of their work too. They can keep reviewing how to improve them during sprint planning, and team retrospectives too.

Teach your people to do these things:

First, deploy early.

Second, try new tech early.

Third, keep addressing remaining risks.

Fourth, share code and knowledge within the team.

By doing these things they will keep reducing risks as they build their application.

---