My workplace has several groups that have little to no software development process. They use source control, and lightly use an issue tracking system, depending on the project. Teams are not regularly creating unit tests and running them in a CI server and not performing code reviews. This varies from project to project. It's a large company and there's no basic framework for doing software development.

I get push back from management about that "their hands are tied" to some degree with the billable customers, and that it's up to individual software developers to do this. I don't entirely agree, but I'm thinking that I should create such a process.

I'm not sure that I should define a "software lifecycle document", e.g. describing Waterfall, Agile, etc. But, I think describing using tools, e.g. "must use issue tracking", "run unit tests on a CI server", and other "best practices".

What would I call this document? Have others struggled with trying to get software teams on board with best practices? How do you overcome this?

  • 1
    Is that a software company or just a non-software company with an in-house team of developers? Commented Aug 3, 2016 at 11:42
  • 1
    It's a group that has done mostly hardware development in the past, with less of a focus on software. Things are shfiting more towards more of a focus on software, but not much view on software development practices. We produce a lot of software, but we're not a pure software company Commented Aug 3, 2016 at 11:47
  • 1
    Non-software companies rarely embrace software industry estandard practices in their in-house development. Since software is not their bread and butter they don't want to invest money on those things. Commented Aug 3, 2016 at 11:49
  • This sounds like a typical case of digitalization. There are many industries which become heavily computerized, where products have slowly morphed from hardware to embedded systems to computer networks. E.g. in live audio engineering, the same companies which used to make large format analog mixing consoles no more than 2 decades ago, now make digital audio networking equipment … with the same people and processes. They have become a software company and don't even know it. Commented Aug 3, 2016 at 12:49
  • I think you need first to speak their language. It means money. If you want they listen to you on this subject (project management, QA, CI, ...) you first need translate all these concepts into benefits. If costs of implementing your strategy outweigh the benfits, there's nothing to do. Remember that you are trying to propose a strategy at the enterprise level not for a mere project. So make sure you know what are you doing :-). One person rarely changes a whole company's philosophy. Even when there's no philosophy at all.
    – Laiv
    Commented Aug 30, 2016 at 8:27

1 Answer 1


Without backup from management: forget it.

If you have some backup from management: do not start with any theoretical documents. Start by interviewing people which real issues they have. Then organize a workshop and involve the team to solve the issues. For example:

  • did source code get lost in the past -> suggest more rigorous use of source control

  • do local builds break often because people check things into source control which don't compile? -> suggest a CI server

  • do they have often regressions? -> suggest to write more automated tests

  • code quality problems, or maintenance problems whilst one dev is on a vacation? -> suggest to make more code reviews

So let the devs find out by themselves what they need most, and write the measures all agreed upon in a document after finishing the workshop.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.