* Was the "best tool" what the devs thought it was?
* Was it something they would hate using? Say, Java for Perl devs?
* Was there a steep learning curve? An obscure language?
2) How big is the system? How complex is the business? How ops-friendly are the devs to start with?
3) You (or someone) must know how much system failure would cost.
4) CI can help with your devops, but its main point is to help with your software quality. See #2.
5) Totally agree, though you can also try being agile about "Agile" and taking just whatever parts work for you.
My $0.02 anyway.
(Aside: years ago I worked on a team doing ad-hoc semi-agile, which worked pretty well. I'm 99% sure I could have double our output and launched a management-consulting career if I could have credibly held the threat of Real Corporate Agile Scrum over their heads. But that was before the flood. One of them works for Atlassian now, ironically enough.)
3) You (or someone) must know how much system failure would cost.
4) CI can help with your devops, but its main point is to help with your software quality. See #2.
5) Totally agree, though you can also try being agile about "Agile" and taking just whatever parts work for you.
My $0.02 anyway.
(Aside: years ago I worked on a team doing ad-hoc semi-agile, which worked pretty well. I'm 99% sure I could have double our output and launched a management-consulting career if I could have credibly held the threat of Real Corporate Agile Scrum over their heads. But that was before the flood. One of them works for Atlassian now, ironically enough.)