How I Learned to Manage Software Projects Better
Every developer knows that it does not matter if you work in Agile, Scrum, Lean, Kanban or Waterfall methodologies, when it comes to software projects — something always gets out of control. Requirements tend to change frequently, time estimations are a wild guess, coordination with other teams is not perfect, and every person in the release chain can easily fail the deployment. How can software engineers deliver under these conditions?
During my work as a backend team leader, I got to manage a few of the complexed software projects of the company. Most projects were challenging technically since we had to replace backend components of a live system which handles millions of agents but they were no less challenging socially, since I needed the cooperation of many people in the organization in order to push the code to production.
The main principle I learned from managing these projects is anticipating problems and adjusting the methodology to work with it — call it “issues driven development” if you like. In the following paragraphs I’ll explain how I implemented this principle.
Starting with the Project's Biggest Problem
The first thing I do when I start to work on a new project is identify the project’s biggest problem. This problem might be a technical issue: a technical part you’re not sure is going to work, and it can also be a social concern: a person or a group that might delay the project. Starting with the project's biggest problem first means I’m able to give it my full attention and have enough time for trial and error to find a solution.
Lately, I worked on an urgent hotfix which was simple technically but challenging socially - the Operations group was not thrilled about releasing a particular feature and thought it was too risky. Before I started writing any code, I approached the Operation’s group representative and worked with them to get the project approved for release. I explained that there are some mitigations we can use to lower the project’s risk: We can start the deployment on a single server, make sure there are no errors and then deploy to the entire cluster; I explained that I am going to test the code thoroughly; I explained that the change will be minimal and only affects certain requests types. Once I noticed progress, I started writing the code. Eliminating the project's biggest obstacle at the begging allowed the code to be released within a few hours.
Raising Potential Issues Before They Become Real Issues
Raising potential issues before they become real issues gives me a real chance to avoid them.
In one of my projects I thought the QA group’s time estimations were too short — I couldn’t understand how they would be able to test it and finish on time. I could easily ignore it since there was no problem in the tests so far, and as a backend team leader the QA group is not under my direct responsibility. Nevertheless, I raised this concern with their boss. He required that we fully understand the test plan. We understood that some features were not included in the test plan, and practically will not be tested. If I hadn’t handled it on time, we might have released a faulty version to production and damaged clients’ data, a much bigger problem to handle.
Potential issues may also be personal: you think you’re spending too much time doing X, there’s a distraction preventing you from focusing on the project, or you need technical help to solve Y. In the places I’ve worked, raising these concerns before they become real issues is much appreciated. Letting my managers know in advance allows them to find a solution: provide guidance regarding X; drop less important features from the project; or letting me work from home to finish the project to avoid distractions.How I Learned to Manage Software Projects BetterClick To Tweet
Recruiting Stakeholders for the Project’s Success
The project stakeholders (Operations, Product, QA, team members, R&D managers) can make or break the success of a project. Many times, project stakeholders have conflicting interests. In order to have a successful software project, my challenge is to recruit the key stakeholders early on to ensure the project’s success.
Before I start working on a project, I make sure the QA TL, Operations representative and team members are updated. I let them know that “In the upcoming days I will start implementing feature X. This feature will be a part of release Y”. I like doing this type of communication orally rather than in writing. By doing so, they feel involved and they know that their feedback matters, what helps making them feel positive about the project.
Getting feedback early on may also save a lot of time. One time, my manager and I decided to perform an incremental deployment of a system in order to lower the deployment’s risk. Once I notified the Operations group that I was going to work on enabling this type of deployment, they replied there was no need and that they preferred to do it all at once. Getting them involved ahead of time, even before I started the project, result in a feedback which saved a lot of time.
In conclusion, by starting with the most difficult part of the project first I give myself enough time for trial and error; by raising potential issues before they become real issues I give myself a chance to avoid them; and by recruiting the key stakeholders early on I increase the odds of the project to be released to production.
Have additional lessons to follow? What works best for you? Let me know in the comments below.