How to keep management out of our development process

development-processmanagement

I'm a software engineer in an software development team. The last 3 years we worked for an internal customer on a new product. Now this product is finished we're going to work on major new features for existing products. For a particular feature, product management have guessed it takes 150 hours to develop. Together with our project manager we have created a very detailed plan and we come to an effort of 300 hours. Yesterday we discussed this and they think we have grossly overestimated things.

In our planning we estimated hours for writing unit tests, their idea is to dump them to save time. The decision has not been made yet and I will defend this planning and the unit tests if needed. But what I really don't like here is that management is interfering with our development process. How do I keep them out of our development process? And what arguments could I use to keep the unit testing in place (besides quality and long term time saving)?

As a side note our company has 3 engineering teams and the team I'm in delivers their software on time (give or take a 10% margin). While the other teams always deliver late, mostly due to underestimation in planning. They only plan the coding and not the management, testing and handling around it.

Best Answer

First, let me say I completely sympathize with your position. It can be frustrating when you have a lack of understanding or a communication breakdown between different parts of the business. Having said that, I don't think you should try to keep them out. Instead you should show them the numbers about why this is a good idea. What facts do you have that justify unit testing is worth the effort you put into it? If you don't have any, then you should start to gather those figures, or show some research to back up your claims.

I have had to deal with similar scenarios myself and I answered this question on a similar topic. I also blogged about how I dealt with it here:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

In case you don't feel like link chasing, I'll repeat my summary from the related question:

To summarize, I compared our estimated hours against actual hours for the project and then compared our defect rate against other teams' defect rate. In our case these numbers compared favourably and there were no more concerns.

My conclusion based on this experience is:

...the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.

If your management team don't agree to investing what they see as an additional 150 hours on unit testing, perhaps you can convince them to invest in one small area of the product (or even agree to suck the hours up yourselves to provide some data). Do unit testing in that one area of the product then gather data about the defect rates in that area of the product and the cost to find and fix those defects compared to the defect rates in other areas of the product. Hopefully you'll gather some data to back up your case and this will be a non-issue for your next project.

Related Topic