Any Agile methodology (read my post on Agile here) should in theory facilitate the early and frequent delivery of value, but the principle often gets lost.

I like to deliver a lighthouse project first, whether that is a PoC, prototype, or pilot. What is critical is that this deliverable must add business value, allowing you to build trust with stakeholders. In my startup, DeQuantifi, we designed our system to have a spreadsheet interface so that we can deliver a working spreadsheet early on.

It is also important to write a business case with the help of a sponsor for larger investments, making the benefits clear and helping to get buy in for the project.

Again, this should be part of adopting an Agile methodology (read my post on Agile here), but is often dropped in the rush to deliver a project. There are two main areas that should almost always be automated, which are 1) testing and 2) deployment. 

For testing, unless there are already comprehensive unit and functional tests, I advocate a risk-based approach i.e. implement automated tests for critical code and key features, and utilise data from production incidents to identify vulnerable components. At DeQuantifi, we use PyUnit for unit testing and integration testing, and Selenium for functional testing.

For deployment (DevOps), a common problem is the time and hardware taken to build and test the system, especially if these have not been a consideration from the start and the infrastructure is not cloud based. In this situation, I recommend running a reduced set of tests for intraday builds, and running the full set overnight. If hardware is a problem, create a minimal deployment of the system for intraday.

Your team will be loyal and motivated if you can help them with their goals. I do this in two ways.

The first is helping them with their career. I do career coaching with everyone in my teams, and I make sure that I take an interest in their professional and technical development, helping where I can.

The second is to move obstacles out of their way so that they can deliver. Common obstacles are lack of hardware, missing development tools, distractions, and unclear requirements.

Another principle that I adopt is to adjust my management style and level of involvement depending on the level of expertise of a team member in a particular area.

I always give time and cost estimates to stakeholders as a range, with the range reflecting the level of uncertainty. I then explain the range using a list of risks with some estimate of their impact and probability. In some situations, I’ve used a Monte Carlo simulation to model the probability distribution for delivery dates.

Whilst this addresses known risks, some provision must be made for unforeseen issues. I do this by adding on overall contingency for the project.

Many development teams prioritise by going through hundreds of user requests with all their stakeholders in very long meetings. 

I take a different approach. I agree a set of principles around how to prioritise and then we prioritise. We then discuss only the things that we can’t prioritise with the stakeholders. The same goes for risk and issue management of the overall project. Only if budget or timescales exceed the parameters agreed with the stakeholders will we ask them to help.

In a group decision making environment, decisions are often based on who is the most senior or the best at arguing. This is time consuming and doesn’t always lead to the best outcome for the organisation.

It is for this reason that I get decisions made using data where possible. For example, this is one benefit of creating a PoC, prototype or pilot project. It is also a benefit of creating a business case.

I also like to create a balanced scorecard for the systems I am responsible for, which leads to a more objective discussion with stakeholders about how well we are meeting their needs.

This is the single most important thing I think about when writing code. Even if another developer never touches my code, it makes it easier for me to come back to months later. 

The reason I like this principle is because it encapsulates many good practices, such as giving variables meaningful names, creating a clean conceptual design, writing comments, and being consistent.

If your code is easy to read, then you can focus on the conceptual design in code reviews.