Mixing
How to introduce better software development practices/processes in the workplace? [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
12
down vote
favorite
This question already has an answer here:
How to make young software engineers improve the quality of their output?
2 answers
I'm a developer in a small software team that works on fairly large software systems. There is a lot of room for improvement in our software development process. The software lead sees the need for it, but the management does not.
For example, we do not follow software developments like code reviews, software design meetings, creating UML diagrams before writing code, or unit testing. In addition, most projects copy-paste code from a previous version of the project and make modifications as needed rather than using a library of reusable software components, or something similar.
What is the best approach to gradually integrate better software development practices? Should I take the initiative to do this, or just leave it to the lead?
software-industry management communication
edited Oct 13 '17 at 14:19
Masked Man♦
43.6k25114163
asked Apr 30 '15 at 0:53
JD.B
1667
marked as duplicate by gnat, carrdelling, dwizum, Michael Grubey, DarkCygnus May 8 at 22:34
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
 |Â
show 1 more comment
up vote
12
down vote
favorite
This question already has an answer here:
How to make young software engineers improve the quality of their output?
2 answers
I'm a developer in a small software team that works on fairly large software systems. There is a lot of room for improvement in our software development process. The software lead sees the need for it, but the management does not.
For example, we do not follow software developments like code reviews, software design meetings, creating UML diagrams before writing code, or unit testing. In addition, most projects copy-paste code from a previous version of the project and make modifications as needed rather than using a library of reusable software components, or something similar.
What is the best approach to gradually integrate better software development practices? Should I take the initiative to do this, or just leave it to the lead?
software-industry management communication
edited Oct 13 '17 at 14:19
Masked Man♦
43.6k25114163
asked Apr 30 '15 at 0:53
JD.B
1667
marked as duplicate by gnat, carrdelling, dwizum, Michael Grubey, DarkCygnus May 8 at 22:34
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
6
Have a read of this: joelonsoftware.com/articles/fog0000000332.html
– DJClayworth
Apr 30 '15 at 0:59
@DJClayworth, that is a really good article/point, thank you. Looks like we're just going to start implementing these processes one at a time. We just have to make sure that management trusts that we know what we are doing.
– JD.B
Apr 30 '15 at 1:08
Yes, if your team lead sees the need for improvement, then they should lead.
– Telastyn
Apr 30 '15 at 3:27
1
What ever you do, go slow . trust me you wont be happy with events if you look for speedy results.
– amar
Apr 30 '15 at 6:33
1
There are probably 20 questions that already deal with this issue on the site. Perhaps you could improve your question to focus on the specific problem you are having getting management to improve these standards
– IDrinkandIKnowThings
Oct 12 '17 at 20:30
 |Â
show 1 more comment
up vote
12
down vote
favorite
up vote
12
down vote
favorite
This question already has an answer here:
How to make young software engineers improve the quality of their output?
2 answers
I'm a developer in a small software team that works on fairly large software systems. There is a lot of room for improvement in our software development process. The software lead sees the need for it, but the management does not.
For example, we do not follow software developments like code reviews, software design meetings, creating UML diagrams before writing code, or unit testing. In addition, most projects copy-paste code from a previous version of the project and make modifications as needed rather than using a library of reusable software components, or something similar.
What is the best approach to gradually integrate better software development practices? Should I take the initiative to do this, or just leave it to the lead?
software-industry management communication
edited Oct 13 '17 at 14:19
Masked Man♦
43.6k25114163
asked Apr 30 '15 at 0:53
JD.B
1667
This question already has an answer here:
How to make young software engineers improve the quality of their output?
2 answers
I'm a developer in a small software team that works on fairly large software systems. There is a lot of room for improvement in our software development process. The software lead sees the need for it, but the management does not.
For example, we do not follow software developments like code reviews, software design meetings, creating UML diagrams before writing code, or unit testing. In addition, most projects copy-paste code from a previous version of the project and make modifications as needed rather than using a library of reusable software components, or something similar.
What is the best approach to gradually integrate better software development practices? Should I take the initiative to do this, or just leave it to the lead?
This question already has an answer here:
How to make young software engineers improve the quality of their output?
2 answers
software-industry management communication
edited Oct 13 '17 at 14:19
Masked Man♦
43.6k25114163
asked Apr 30 '15 at 0:53
JD.B
1667
edited Oct 13 '17 at 14:19
Masked Man♦
43.6k25114163
edited Oct 13 '17 at 14:19
Masked Man♦
43.6k25114163
edited Oct 13 '17 at 14:19
Masked Man♦
43.6k25114163
43.6k25114163
asked Apr 30 '15 at 0:53
JD.B
1667
asked Apr 30 '15 at 0:53
JD.B
1667
asked Apr 30 '15 at 0:53
JD.B
1667
1667
marked as duplicate by gnat, carrdelling, dwizum, Michael Grubey, DarkCygnus May 8 at 22:34
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by gnat, carrdelling, dwizum, Michael Grubey, DarkCygnus May 8 at 22:34
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
6
Have a read of this: joelonsoftware.com/articles/fog0000000332.html
– DJClayworth
Apr 30 '15 at 0:59
@DJClayworth, that is a really good article/point, thank you. Looks like we're just going to start implementing these processes one at a time. We just have to make sure that management trusts that we know what we are doing.
– JD.B
Apr 30 '15 at 1:08
Yes, if your team lead sees the need for improvement, then they should lead.
– Telastyn
Apr 30 '15 at 3:27
1
What ever you do, go slow . trust me you wont be happy with events if you look for speedy results.
– amar
Apr 30 '15 at 6:33
1
There are probably 20 questions that already deal with this issue on the site. Perhaps you could improve your question to focus on the specific problem you are having getting management to improve these standards
– IDrinkandIKnowThings
Oct 12 '17 at 20:30
 |Â
show 1 more comment
6
Have a read of this: joelonsoftware.com/articles/fog0000000332.html
– DJClayworth
Apr 30 '15 at 0:59
@DJClayworth, that is a really good article/point, thank you. Looks like we're just going to start implementing these processes one at a time. We just have to make sure that management trusts that we know what we are doing.
– JD.B
Apr 30 '15 at 1:08
Yes, if your team lead sees the need for improvement, then they should lead.
– Telastyn
Apr 30 '15 at 3:27
1
What ever you do, go slow . trust me you wont be happy with events if you look for speedy results.
– amar
Apr 30 '15 at 6:33
1
There are probably 20 questions that already deal with this issue on the site. Perhaps you could improve your question to focus on the specific problem you are having getting management to improve these standards
– IDrinkandIKnowThings
Oct 12 '17 at 20:30
6
6
Have a read of this: joelonsoftware.com/articles/fog0000000332.html
– DJClayworth
Apr 30 '15 at 0:59
Have a read of this: joelonsoftware.com/articles/fog0000000332.html
– DJClayworth
Apr 30 '15 at 0:59
@DJClayworth, that is a really good article/point, thank you. Looks like we're just going to start implementing these processes one at a time. We just have to make sure that management trusts that we know what we are doing.
– JD.B
Apr 30 '15 at 1:08
@DJClayworth, that is a really good article/point, thank you. Looks like we're just going to start implementing these processes one at a time. We just have to make sure that management trusts that we know what we are doing.
– JD.B
Apr 30 '15 at 1:08
Yes, if your team lead sees the need for improvement, then they should lead.
– Telastyn
Apr 30 '15 at 3:27
Yes, if your team lead sees the need for improvement, then they should lead.
– Telastyn
Apr 30 '15 at 3:27
1
1
What ever you do, go slow . trust me you wont be happy with events if you look for speedy results.
– amar
Apr 30 '15 at 6:33
What ever you do, go slow . trust me you wont be happy with events if you look for speedy results.
– amar
Apr 30 '15 at 6:33
1
1
There are probably 20 questions that already deal with this issue on the site. Perhaps you could improve your question to focus on the specific problem you are having getting management to improve these standards
– IDrinkandIKnowThings
Oct 12 '17 at 20:30
There are probably 20 questions that already deal with this issue on the site. Perhaps you could improve your question to focus on the specific problem you are having getting management to improve these standards
– IDrinkandIKnowThings
Oct 12 '17 at 20:30
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
9
down vote
accepted
The best way to convince people to change is to show what's in it for them.
First, realize that you have a long road to get from where you are to where you want to be. Doing this as a 'big bang' effort will likely cause problems with delays, pushback and it's difficult to sell as it's a lot of effort. Doing this bit by bit is the key.
You say the process is working, but has room for improvement. And in the comment you say "make sure that management trusts that we know what we are doing" -- you don't need trust, you can sell concrete benefits.
Work out what concrete benefits will the company see from these improvement. Sell each process improvement as something that addresses a concrete problem, not something that just 'could be better'. Argue why the extra effort up front saves time in the long run. Perhaps you find late bugs in development (a very common symptom of insufficient process), you can say:
Remember bug X in project Y. We found that late and had to do a lot of rework to address it. I believe we could have found it earlier by doing A, B or C. Can we trial one of these process improvements on a new project and see if it makes a difference.
Or perhaps the biggest problem you see is the amount of extra effort/overtime and the risk of employee burnout, so spin the improvements as addressing that.
Basically, identify what business impact of the process weaknesses are then sell the process improvements to directly address that. In the same way you'd sell anything, investing this amount now saves X times that later.
Do this for each improvement and do them separately, once you have a few proven improvements you can argue for creating a roadmap. Start with the improvement that you think will make the biggest impact for the least effort (low hanging fruit -- this is probably peer reviews, but not always).
You should definitely start with by approaching the software lead, but don't say "We should do code reviews". Explain why you think code reviews are important, how you would recommend they're done, how much resources (time and effort) you thing it will take and what the benefit to the lead is and what the benefit to the company is. Give him a complete proposal that he can take to his boss so that he have to spend time on it.
If they implement the proposal collect metrics to prove it works. If it doesn't work be prepared to work out why and reassess. It's easier to do this if you trial the improvement on only a few projects, so you can compare and contrast.
If the lead is on board you could start talking about a long term improvement plan, if he needs convincing work out the plan on your own and only share it once you've got a few successes under your belt.
Other assorted points:
Realize you're pushing against inertia in the organization. Particularly if they're more experienced engineers that have been doing this for a while. A lot of people really don't understand that the 'best practice' has moved on from when they were training -- or they were trained purely in software engineering (i.e. programming to solve issues) rather than the full software process. Here find the people most open to change, work with them to convince the others. There will be some holdouts but eventually they'll come round when they see the benefits (note, from experience, 'eventually' can take years ...)
If you get nowhere you may just have to accept it. Do what you can on your own, be an example. Talk about what you're doing differently, why you're doing it and what the benefit is for everyone else. If nothing else it'll make your life easy.
Ensure that whatever improvements you put in place are 'best practice', do research on them, as linked in the comments Joel On Software is a great resource, and there are plenty more if you search for them -- Google is your friend here, here's a nice breakdown from IBM. And of course there's all the information and advice on the StackExchange network (StackOverflow and Programmers are a good start). You can also use these resources to help sell the improvement.
You're unlikely to persuade the company to pay for external trainers or auditors, but they are useful because people tend to listen more when they've paid for the advice. One approach here is to show the your competitors are certified (i.e. CMMI) and argue that this is something that would interest customers.
Finally, let's talk about common code library. This is a lot more difficult to sell -- the copy/paste and tweak workflow is exceedingly common and if people are not used to using libraries they can be very much against them as it appears to be more work (or at least more learning).
Here the best way to start is to do it yourself, identify a few bits of code that could be common and start to build your own common library. Follow best practices, design upfront, document everything, build unit tests in to make it as bulletproof as possible. Start incorporating this into your projects. Then after you've done it you should be able to show why it's better and faster. Again, this is better with the support of the lead and some time, but just doing it where you can will make your life easier if nothing else.
edited Oct 12 '17 at 19:24
Robert Harvey
2,55821226
answered Apr 30 '15 at 2:27
SpaceDog
54637
This is exactly the type of advice I was looking for! Thank you for the ideas, I'll start the conversation with our lead to see what they think about it.
– JD.B
Apr 30 '15 at 21:49
suggest improvements |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
9
down vote
accepted
The best way to convince people to change is to show what's in it for them.
First, realize that you have a long road to get from where you are to where you want to be. Doing this as a 'big bang' effort will likely cause problems with delays, pushback and it's difficult to sell as it's a lot of effort. Doing this bit by bit is the key.
You say the process is working, but has room for improvement. And in the comment you say "make sure that management trusts that we know what we are doing" -- you don't need trust, you can sell concrete benefits.
Work out what concrete benefits will the company see from these improvement. Sell each process improvement as something that addresses a concrete problem, not something that just 'could be better'. Argue why the extra effort up front saves time in the long run. Perhaps you find late bugs in development (a very common symptom of insufficient process), you can say:
Remember bug X in project Y. We found that late and had to do a lot of rework to address it. I believe we could have found it earlier by doing A, B or C. Can we trial one of these process improvements on a new project and see if it makes a difference.
Or perhaps the biggest problem you see is the amount of extra effort/overtime and the risk of employee burnout, so spin the improvements as addressing that.
Basically, identify what business impact of the process weaknesses are then sell the process improvements to directly address that. In the same way you'd sell anything, investing this amount now saves X times that later.
Do this for each improvement and do them separately, once you have a few proven improvements you can argue for creating a roadmap. Start with the improvement that you think will make the biggest impact for the least effort (low hanging fruit -- this is probably peer reviews, but not always).
You should definitely start with by approaching the software lead, but don't say "We should do code reviews". Explain why you think code reviews are important, how you would recommend they're done, how much resources (time and effort) you thing it will take and what the benefit to the lead is and what the benefit to the company is. Give him a complete proposal that he can take to his boss so that he have to spend time on it.
If they implement the proposal collect metrics to prove it works. If it doesn't work be prepared to work out why and reassess. It's easier to do this if you trial the improvement on only a few projects, so you can compare and contrast.
If the lead is on board you could start talking about a long term improvement plan, if he needs convincing work out the plan on your own and only share it once you've got a few successes under your belt.
Other assorted points:
Realize you're pushing against inertia in the organization. Particularly if they're more experienced engineers that have been doing this for a while. A lot of people really don't understand that the 'best practice' has moved on from when they were training -- or they were trained purely in software engineering (i.e. programming to solve issues) rather than the full software process. Here find the people most open to change, work with them to convince the others. There will be some holdouts but eventually they'll come round when they see the benefits (note, from experience, 'eventually' can take years ...)
If you get nowhere you may just have to accept it. Do what you can on your own, be an example. Talk about what you're doing differently, why you're doing it and what the benefit is for everyone else. If nothing else it'll make your life easy.
Ensure that whatever improvements you put in place are 'best practice', do research on them, as linked in the comments Joel On Software is a great resource, and there are plenty more if you search for them -- Google is your friend here, here's a nice breakdown from IBM. And of course there's all the information and advice on the StackExchange network (StackOverflow and Programmers are a good start). You can also use these resources to help sell the improvement.
You're unlikely to persuade the company to pay for external trainers or auditors, but they are useful because people tend to listen more when they've paid for the advice. One approach here is to show the your competitors are certified (i.e. CMMI) and argue that this is something that would interest customers.
Finally, let's talk about common code library. This is a lot more difficult to sell -- the copy/paste and tweak workflow is exceedingly common and if people are not used to using libraries they can be very much against them as it appears to be more work (or at least more learning).
Here the best way to start is to do it yourself, identify a few bits of code that could be common and start to build your own common library. Follow best practices, design upfront, document everything, build unit tests in to make it as bulletproof as possible. Start incorporating this into your projects. Then after you've done it you should be able to show why it's better and faster. Again, this is better with the support of the lead and some time, but just doing it where you can will make your life easier if nothing else.
edited Oct 12 '17 at 19:24
Robert Harvey
2,55821226
answered Apr 30 '15 at 2:27
SpaceDog
54637
This is exactly the type of advice I was looking for! Thank you for the ideas, I'll start the conversation with our lead to see what they think about it.
– JD.B
Apr 30 '15 at 21:49
suggest improvements |Â
up vote
9
down vote
accepted
The best way to convince people to change is to show what's in it for them.
First, realize that you have a long road to get from where you are to where you want to be. Doing this as a 'big bang' effort will likely cause problems with delays, pushback and it's difficult to sell as it's a lot of effort. Doing this bit by bit is the key.
You say the process is working, but has room for improvement. And in the comment you say "make sure that management trusts that we know what we are doing" -- you don't need trust, you can sell concrete benefits.
Work out what concrete benefits will the company see from these improvement. Sell each process improvement as something that addresses a concrete problem, not something that just 'could be better'. Argue why the extra effort up front saves time in the long run. Perhaps you find late bugs in development (a very common symptom of insufficient process), you can say:
Remember bug X in project Y. We found that late and had to do a lot of rework to address it. I believe we could have found it earlier by doing A, B or C. Can we trial one of these process improvements on a new project and see if it makes a difference.
Or perhaps the biggest problem you see is the amount of extra effort/overtime and the risk of employee burnout, so spin the improvements as addressing that.
Basically, identify what business impact of the process weaknesses are then sell the process improvements to directly address that. In the same way you'd sell anything, investing this amount now saves X times that later.
Do this for each improvement and do them separately, once you have a few proven improvements you can argue for creating a roadmap. Start with the improvement that you think will make the biggest impact for the least effort (low hanging fruit -- this is probably peer reviews, but not always).
You should definitely start with by approaching the software lead, but don't say "We should do code reviews". Explain why you think code reviews are important, how you would recommend they're done, how much resources (time and effort) you thing it will take and what the benefit to the lead is and what the benefit to the company is. Give him a complete proposal that he can take to his boss so that he have to spend time on it.
If they implement the proposal collect metrics to prove it works. If it doesn't work be prepared to work out why and reassess. It's easier to do this if you trial the improvement on only a few projects, so you can compare and contrast.
If the lead is on board you could start talking about a long term improvement plan, if he needs convincing work out the plan on your own and only share it once you've got a few successes under your belt.
Other assorted points:
Realize you're pushing against inertia in the organization. Particularly if they're more experienced engineers that have been doing this for a while. A lot of people really don't understand that the 'best practice' has moved on from when they were training -- or they were trained purely in software engineering (i.e. programming to solve issues) rather than the full software process. Here find the people most open to change, work with them to convince the others. There will be some holdouts but eventually they'll come round when they see the benefits (note, from experience, 'eventually' can take years ...)
If you get nowhere you may just have to accept it. Do what you can on your own, be an example. Talk about what you're doing differently, why you're doing it and what the benefit is for everyone else. If nothing else it'll make your life easy.
Ensure that whatever improvements you put in place are 'best practice', do research on them, as linked in the comments Joel On Software is a great resource, and there are plenty more if you search for them -- Google is your friend here, here's a nice breakdown from IBM. And of course there's all the information and advice on the StackExchange network (StackOverflow and Programmers are a good start). You can also use these resources to help sell the improvement.
You're unlikely to persuade the company to pay for external trainers or auditors, but they are useful because people tend to listen more when they've paid for the advice. One approach here is to show the your competitors are certified (i.e. CMMI) and argue that this is something that would interest customers.
Finally, let's talk about common code library. This is a lot more difficult to sell -- the copy/paste and tweak workflow is exceedingly common and if people are not used to using libraries they can be very much against them as it appears to be more work (or at least more learning).
Here the best way to start is to do it yourself, identify a few bits of code that could be common and start to build your own common library. Follow best practices, design upfront, document everything, build unit tests in to make it as bulletproof as possible. Start incorporating this into your projects. Then after you've done it you should be able to show why it's better and faster. Again, this is better with the support of the lead and some time, but just doing it where you can will make your life easier if nothing else.
edited Oct 12 '17 at 19:24
Robert Harvey
2,55821226
answered Apr 30 '15 at 2:27
SpaceDog
54637
This is exactly the type of advice I was looking for! Thank you for the ideas, I'll start the conversation with our lead to see what they think about it.
– JD.B
Apr 30 '15 at 21:49
suggest improvements |Â
up vote
9
down vote
accepted
up vote
9
down vote
accepted
The best way to convince people to change is to show what's in it for them.
First, realize that you have a long road to get from where you are to where you want to be. Doing this as a 'big bang' effort will likely cause problems with delays, pushback and it's difficult to sell as it's a lot of effort. Doing this bit by bit is the key.
You say the process is working, but has room for improvement. And in the comment you say "make sure that management trusts that we know what we are doing" -- you don't need trust, you can sell concrete benefits.
Work out what concrete benefits will the company see from these improvement. Sell each process improvement as something that addresses a concrete problem, not something that just 'could be better'. Argue why the extra effort up front saves time in the long run. Perhaps you find late bugs in development (a very common symptom of insufficient process), you can say:
Remember bug X in project Y. We found that late and had to do a lot of rework to address it. I believe we could have found it earlier by doing A, B or C. Can we trial one of these process improvements on a new project and see if it makes a difference.
Or perhaps the biggest problem you see is the amount of extra effort/overtime and the risk of employee burnout, so spin the improvements as addressing that.
Basically, identify what business impact of the process weaknesses are then sell the process improvements to directly address that. In the same way you'd sell anything, investing this amount now saves X times that later.
Do this for each improvement and do them separately, once you have a few proven improvements you can argue for creating a roadmap. Start with the improvement that you think will make the biggest impact for the least effort (low hanging fruit -- this is probably peer reviews, but not always).
You should definitely start with by approaching the software lead, but don't say "We should do code reviews". Explain why you think code reviews are important, how you would recommend they're done, how much resources (time and effort) you thing it will take and what the benefit to the lead is and what the benefit to the company is. Give him a complete proposal that he can take to his boss so that he have to spend time on it.
If they implement the proposal collect metrics to prove it works. If it doesn't work be prepared to work out why and reassess. It's easier to do this if you trial the improvement on only a few projects, so you can compare and contrast.
If the lead is on board you could start talking about a long term improvement plan, if he needs convincing work out the plan on your own and only share it once you've got a few successes under your belt.
Other assorted points:
Realize you're pushing against inertia in the organization. Particularly if they're more experienced engineers that have been doing this for a while. A lot of people really don't understand that the 'best practice' has moved on from when they were training -- or they were trained purely in software engineering (i.e. programming to solve issues) rather than the full software process. Here find the people most open to change, work with them to convince the others. There will be some holdouts but eventually they'll come round when they see the benefits (note, from experience, 'eventually' can take years ...)
If you get nowhere you may just have to accept it. Do what you can on your own, be an example. Talk about what you're doing differently, why you're doing it and what the benefit is for everyone else. If nothing else it'll make your life easy.
Ensure that whatever improvements you put in place are 'best practice', do research on them, as linked in the comments Joel On Software is a great resource, and there are plenty more if you search for them -- Google is your friend here, here's a nice breakdown from IBM. And of course there's all the information and advice on the StackExchange network (StackOverflow and Programmers are a good start). You can also use these resources to help sell the improvement.
You're unlikely to persuade the company to pay for external trainers or auditors, but they are useful because people tend to listen more when they've paid for the advice. One approach here is to show the your competitors are certified (i.e. CMMI) and argue that this is something that would interest customers.
Finally, let's talk about common code library. This is a lot more difficult to sell -- the copy/paste and tweak workflow is exceedingly common and if people are not used to using libraries they can be very much against them as it appears to be more work (or at least more learning).
Here the best way to start is to do it yourself, identify a few bits of code that could be common and start to build your own common library. Follow best practices, design upfront, document everything, build unit tests in to make it as bulletproof as possible. Start incorporating this into your projects. Then after you've done it you should be able to show why it's better and faster. Again, this is better with the support of the lead and some time, but just doing it where you can will make your life easier if nothing else.
edited Oct 12 '17 at 19:24
Robert Harvey
2,55821226
answered Apr 30 '15 at 2:27
SpaceDog
54637
The best way to convince people to change is to show what's in it for them.
First, realize that you have a long road to get from where you are to where you want to be. Doing this as a 'big bang' effort will likely cause problems with delays, pushback and it's difficult to sell as it's a lot of effort. Doing this bit by bit is the key.
You say the process is working, but has room for improvement. And in the comment you say "make sure that management trusts that we know what we are doing" -- you don't need trust, you can sell concrete benefits.
Work out what concrete benefits will the company see from these improvement. Sell each process improvement as something that addresses a concrete problem, not something that just 'could be better'. Argue why the extra effort up front saves time in the long run. Perhaps you find late bugs in development (a very common symptom of insufficient process), you can say:
Remember bug X in project Y. We found that late and had to do a lot of rework to address it. I believe we could have found it earlier by doing A, B or C. Can we trial one of these process improvements on a new project and see if it makes a difference.
Or perhaps the biggest problem you see is the amount of extra effort/overtime and the risk of employee burnout, so spin the improvements as addressing that.
Basically, identify what business impact of the process weaknesses are then sell the process improvements to directly address that. In the same way you'd sell anything, investing this amount now saves X times that later.
Do this for each improvement and do them separately, once you have a few proven improvements you can argue for creating a roadmap. Start with the improvement that you think will make the biggest impact for the least effort (low hanging fruit -- this is probably peer reviews, but not always).
You should definitely start with by approaching the software lead, but don't say "We should do code reviews". Explain why you think code reviews are important, how you would recommend they're done, how much resources (time and effort) you thing it will take and what the benefit to the lead is and what the benefit to the company is. Give him a complete proposal that he can take to his boss so that he have to spend time on it.
If they implement the proposal collect metrics to prove it works. If it doesn't work be prepared to work out why and reassess. It's easier to do this if you trial the improvement on only a few projects, so you can compare and contrast.
If the lead is on board you could start talking about a long term improvement plan, if he needs convincing work out the plan on your own and only share it once you've got a few successes under your belt.
Other assorted points:
Realize you're pushing against inertia in the organization. Particularly if they're more experienced engineers that have been doing this for a while. A lot of people really don't understand that the 'best practice' has moved on from when they were training -- or they were trained purely in software engineering (i.e. programming to solve issues) rather than the full software process. Here find the people most open to change, work with them to convince the others. There will be some holdouts but eventually they'll come round when they see the benefits (note, from experience, 'eventually' can take years ...)
If you get nowhere you may just have to accept it. Do what you can on your own, be an example. Talk about what you're doing differently, why you're doing it and what the benefit is for everyone else. If nothing else it'll make your life easy.
Ensure that whatever improvements you put in place are 'best practice', do research on them, as linked in the comments Joel On Software is a great resource, and there are plenty more if you search for them -- Google is your friend here, here's a nice breakdown from IBM. And of course there's all the information and advice on the StackExchange network (StackOverflow and Programmers are a good start). You can also use these resources to help sell the improvement.
You're unlikely to persuade the company to pay for external trainers or auditors, but they are useful because people tend to listen more when they've paid for the advice. One approach here is to show the your competitors are certified (i.e. CMMI) and argue that this is something that would interest customers.
Finally, let's talk about common code library. This is a lot more difficult to sell -- the copy/paste and tweak workflow is exceedingly common and if people are not used to using libraries they can be very much against them as it appears to be more work (or at least more learning).
Here the best way to start is to do it yourself, identify a few bits of code that could be common and start to build your own common library. Follow best practices, design upfront, document everything, build unit tests in to make it as bulletproof as possible. Start incorporating this into your projects. Then after you've done it you should be able to show why it's better and faster. Again, this is better with the support of the lead and some time, but just doing it where you can will make your life easier if nothing else.
edited Oct 12 '17 at 19:24
Robert Harvey
2,55821226
answered Apr 30 '15 at 2:27
SpaceDog
54637
edited Oct 12 '17 at 19:24
Robert Harvey
2,55821226
edited Oct 12 '17 at 19:24
Robert Harvey
2,55821226
edited Oct 12 '17 at 19:24
Robert Harvey
2,55821226
2,55821226
answered Apr 30 '15 at 2:27
SpaceDog
54637
answered Apr 30 '15 at 2:27
SpaceDog
54637
answered Apr 30 '15 at 2:27
SpaceDog
54637
54637
This is exactly the type of advice I was looking for! Thank you for the ideas, I'll start the conversation with our lead to see what they think about it.
– JD.B
Apr 30 '15 at 21:49
suggest improvements |Â
This is exactly the type of advice I was looking for! Thank you for the ideas, I'll start the conversation with our lead to see what they think about it.
– JD.B
Apr 30 '15 at 21:49
This is exactly the type of advice I was looking for! Thank you for the ideas, I'll start the conversation with our lead to see what they think about it.
– JD.B
Apr 30 '15 at 21:49
This is exactly the type of advice I was looking for! Thank you for the ideas, I'll start the conversation with our lead to see what they think about it.
– JD.B
Apr 30 '15 at 21:49
suggest improvements |Â
6
Have a read of this: joelonsoftware.com/articles/fog0000000332.html
– DJClayworth
Apr 30 '15 at 0:59
@DJClayworth, that is a really good article/point, thank you. Looks like we're just going to start implementing these processes one at a time. We just have to make sure that management trusts that we know what we are doing.
– JD.B
Apr 30 '15 at 1:08
Yes, if your team lead sees the need for improvement, then they should lead.
– Telastyn
Apr 30 '15 at 3:27
1
What ever you do, go slow . trust me you wont be happy with events if you look for speedy results.
– amar
Apr 30 '15 at 6:33
1
There are probably 20 questions that already deal with this issue on the site. Perhaps you could improve your question to focus on the specific problem you are having getting management to improve these standards
– IDrinkandIKnowThings
Oct 12 '17 at 20:30