I am pretty new within our Scrum team. (Round about 4 months) Whenever I suggest some paradigm like "DevOps" or technology like "Kubernetes" to solve issues I am criticised at least from a part of the team.

Arguments are "these are just buzz words". Other times the team just does not react to my proposals.

I am really unhappy with the situation.

A lot of my spare time is going into watching conference videos and learning on diverse online training platforms and I think that the team could profit from it.

I ask for help often and asked the team to pair-program with me in order to assist me but also to learn from each other. However most of the other team members interpret this often as me being lazy or not willingly to solve the issue for myself. In my earlier career I was trained to ask for help early and I also see possible winnings in working closely together as a good DevOps-practice.

How would you approach this issue?

  • 1
    How would I approach the issue? I'd just go ahead and implement the stuff I wanted and trust to out performing them.
    – Ewan
    Oct 8, 2018 at 18:50
  • Well I am on my way to doing this. (I apply TDD for example) and improve my coding every day by writing, clean understandable, modular JS-Code.
    – user317100
    Oct 8, 2018 at 18:54
  • However I don't see this as team work... And in fact I ask for DevOps - not by one but by the team.
    – user317100
    Oct 8, 2018 at 18:55
  • yeah, I didnt say I would do the best thing.
    – Ewan
    Oct 8, 2018 at 19:05
  • 1
    Enlighten us - which problem of the team do you want to solve by introducing "DevOps practices", and which by introducing "Kubernetes"?
    – Doc Brown
    Oct 8, 2018 at 20:21

3 Answers 3


You have to explain two things in order for a new technology / paradigm / language / methodology / whatever to have any chance of success in a team. First, you need to explain what is not working with the current approach. You then need to explain how your proposed technology would solve those problems, while not introducing any bigger problems (that you foresee, at least).

If the team's current solution is working well for the team, they see no reason to change it - thus the indifference. If you haven't explained why your solution would be a good fit for this team in this situation, they'll dismiss it as buzzwords - especially if you just say "We should use DevOps for this", with no other explanation, because at that point it is just a buzzword.

Do your research and make sure you're not just throwing out buzzwords. Find numbers on the benefits of pair-programming (reduced bug counts, higher bus factor, etc), figure out why Kubernetes is a good solution for your apps, and figure out what about DevOps will benefit your team.

  • 4
    Yes, that matches my point of view as an "oldie". To exchange technologies, you should have a valid reason, otherwise you're just wasting time and money. If I had followed all buzzwords from the last 30 years, I wouldn't have finished a single project. Oct 8, 2018 at 19:19

Some things like DevOps really are just buzz words, and even groups that don't do "DevOps", really do indeed do large chunks of it.

For example:

  • do you have a code repository?
  • Do you run unit tests before promoting code?
  • Are your deployments automated?

There are many more. A lot of this was already happening before DevOps simply gave a name to it. So I can see how telling your team that "we need to do DevOps" could be met with "that's just a buzz word".

Maybe it would help to recommend just specific pieces of DevOps without actually mentioning DevOps. For example, if you have a code repository and unit tests, but deployment is not as automated as it could be, you could recommend a specific way to improve that automation. Or maybe show how a code sniffer can improve consistency of your code and how that can be automated so folks can monitor the quality of their code without having to do anything other than checking it in to the repository.

Developers are busy people, and rarely want to concern themselves with marketing speak. But if you can show them a way to be more productive with less effort, that is a win, and if they don't have to spend precious cycles learning new procedures, even better.


I guess there are a number of arguments you can use internally to push new technology or methodologies.

  1. Pitch to Managers : New tech introduction projects can be an easy win for new managers. "What did you do in your last position? I introduced product X and saved the company $$$."

  2. Pitch to Devs : Using new tech looks good on developers CVs. enabling them to apply for more and higher paying jobs. 'CV Driven Development'

  3. Pitch to Admins : Automating manual processes reduces people's work load.

The danger of trying to introduce new stuff is that you are getting rid of old stuff. Old stuff that maybe people pinned their reputation to.

ie. If I introduced Scrum last year and got a raise for it, I can't let you change it to KANBAN this year.

Find the things that no-one likes to replace or find stuff you can add without replacing anything.

Understand who introduced what and when before suggesting something.

  • 1
    If I were to detect CV Driven Development in my team, I'd vote against any rise for that team member the next 2 years. Oct 8, 2018 at 19:25
  • @Ralf CVDD is a problem, im not sure thats a good response to it though. In general Devs get raises by changing jobs, not staying put. But in this case do you care about the motivation if the result is good for the company?
    – Ewan
    Oct 8, 2018 at 19:28
  • As long as the benefit for the project has higher priority than CV, it's ok. If both profit from the change, everything's fine. Oct 8, 2018 at 19:33
  • I guess its a bit off topic, but I would question your approach. A sales person is always going to be looking at their commission first. If you are being sold to, you have to take that motivation into account. Theres no point punishing the sales person for wanting to get on in the world
    – Ewan
    Oct 8, 2018 at 19:47
  • Also, if a new tech skill is in demand, it means your competitors are using that tech. Maybe you should be too
    – Ewan
    Oct 8, 2018 at 19:49

Your Answer

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