How to be a good team member and push the team towards new paradigms and technologies at the same time.

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.