A few lessons that Dev(and Ops) can learn from project management

Software development gives you a lot of flexibility. Scrum created independent, self-sufficient teams that strive to reach company’s goals. Yet, there are things, that scrum teams could learn from non-agile project managers. I also needed to perform department-wide project management tasks, such as feasibility studies, cost analysis and software purchase recommendations. I believe that every developer can learn something from those experiences as well.

If you’re just starting your development career, the chances are, you won’t be interested in what project management has to offer. However, please bear in mind that at some point, cost and feasibility of your development project might affect you. It is my personal opinion that project management knowledge contributes to better development practices and efficiency of scrum teams.

Prioritizing tasks

Prioritizing tasks falls under the responsibility of a Product Owner (most of the times). However, there are tasks that cannot be prioritized by Product Owner or any business stakeholder for that matter. In the case of a scrum team, it is a shared responsibility of everyone in the team to assess priority of each refactoring. And not every refactoring is worth the effort when the business pressures for results. It is therefore important to be able to reasonably assess the value of the refactoring versus the effort. For me, refactoring is a development technique that doesn’t produce a new feature, but instead reorganizes code in such a way, that future changes might be implemented faster (or at least not slower). Developers should prioritize refactoring effort in such a way, that the further development is not hindered by technical debt, but also should not fall into spiral of refactoring for the sake of refactoring. This also applies to other technical tasks that cannot be easily prioritized by Product Owners.

Choose software based on the costs

There are times, when the only factor to consider is the cost. As an example I can tell you about the cost analysis that I did between Jira Server, Jira Cloud and Azure DevOps (formerly Visual Studio Team Services). All of those services provide comparable features that would satisfy most of the scrum teams in the world. Initially we were leaning towards Atlassian Cloud, as we used to have Atlassian suite installed on-premise. However, after doing my part of research, it came as a surprise to everyone that Azure DevOps (formerly Visual Studio Team Services) might actually be three times cheaper than Atlassian Cloud and that’s including the potential migration cost.

This history should teach you that it is always worth to run through some numbers before you make a final decision. Numbers not always give you a full picture of a situation, but they always help with orientation.

Let’s see another example on how simple cost calculations might lead to cost savings in a surprising way for your company. We had been doing backups of our services that were running on Virtual Machines on Azure on a daily basis. Someone in the past has decided that the backups would be transferred to on-premise storage, because it is cheaper to store the data there. Unfortunately, the backup size has grown significantly over the last few years. Having calculated the daily data transfer cost between Azure and on-premise servers, it turned out that the transfer cost was 10x more expensive that storing the data directly on Azure. Azure offers so-called archive storage, that is much cheaper if you don’t query the data very often.

There are three lessons from the stories:

• Always challenge the status quo

• You should know the offering of your cloud platform in order to make informed decisions about the infrastructure

• It is always worth to run through some numbers, you might be surprised what numbers can tell you

Managing project risk

When starting a new development project, it is very important to eliminate or decrease potential risk. One of the ways you can tackle this issue, is by looking at the biggest questions and development/architectural challenges that might put the project at risk. Examples of such questions involve:

• Can we integrate with the external service easily?

• Is the scope of the project (the number and complexity of the features) feasible to implement within the timeline?

• Are there technical difficulties that might stop us from finishing the project?

Order them from the most risky to least risky. Then for each point on that list, try to answer the question as fully as you can. Sometimes to answer the question you need a Proof of Concept app. Sometimes it is enough to call a Cloud consultant in order to get information about Azure Storage communication protocols. The point is - you decrease the risk of a project by answering the questions that might put a project in danger of failure. After you have covered most of the points, you are ready for an implementation.

Divide and conquer

The common development practice teaches to split the problem into small chunks, that you can develop independently. The same applies to whole projects. Whenever possible, try to split a project into smaller pieces that can be delivered and tracked independently. Remember that the longer the project takes to complete, the bigger the risk the project can fail. The smaller the chunks, the more granularly you can track your progress and show it to your Product Owner or other business stakeholders.

Base your decisions on data (or at least support them with it)

You should support the software decisions that you make with data. For one, this makes easier to convince business stakeholders about software decisions. Putting basic metrics into place before you start a project, can also help you measuring the progress that we discussed in the previous point. By regularly measuring key data points, you can have more confidence in the project trajectory.

Don’t forget implementation and maintenance cost

Don’t forget to include labour and maintenance cost in your calculations. Developers are quite expensive. It might turn out that the migration you have planned is not so viable after you include peoples' salaries (work hours) into consideration.

Calculate total cost of ownership

Calculate total cost of ownership for a relevant period of time. E.g. when calculating the cost of CI/CD software, take into the account maintenance cost and infrastructure cost over the next few years. This might be especially important if you are calculating the cost of a subscription service. The subscription model characteristic makes it very dependent on the expected lifetime of the subscription. In that case, calculating the cost over a certain period of time is very important. It will enable you to see the incremental cost of the service over years.

Summary

It is not only a responsibility of a manager to assess cost and project feasibility. Scrum teams nowadays need to be self-sufficient and independent. As part of the independence, the team needs to responsible for assessing viability of a project. The combination of our technical knowledge with project management practices gives developers and software architects an unique opportunity on the job market. Being aware of those practices and exercising them will make you a better engineer, developer and an architect.