READING TIME CA. 3 MINUTES
What challenges did I face during my first DevOps project?
Listening to others, opening up to new ideas
The image that the team's developers had of DevOps and the image that the technicians had of it were simply different at first. That's why one of my main tasks was always to make sure that neither the developers nor the technicians took their respective images of "the matter" for granted and were correct. Getting both parties to take nothing for granted or given and to listen to the other and open up was the prerequisite for cross-fertilization.
It was important to create an atmosphere in which it was possible to say if you didn't (yet) know anything about something without feeling that you would lose the respect of your colleagues. It was generally helpful to clarify and discuss the rules of collaboration early on in the project (but you would also do this with a pure Dev or Ops team).
Keeping the focus
Once the cross-fertilization was underway, the second challenge was to keep the focus. New things are exciting, they want to be tried out, even if the use case is not (yet) defined.
As we had committed ourselves as a team to a defined result, it was important to constantly question which tasks would bring us closer to this result and which tasks would represent a detour, albeit an interesting one. We are still working on completing tasks before starting new ones :-)
Making sure that employees don't overreach themselves
The learning curve is very steep when a DevOps team is initially put together. It's exciting, but also very exhausting. During learning phases, it is particularly important that the necessary rest periods are observed. After the first two weeks, it became clear that we had to slow down overall in order to achieve this.
Personal challenge: Remain neutral
I think it was good that I haven't been actively developing for a while and that I'm not personally involved in either dev or ops. It's important that both sides can have an equal say and appreciate each other in order to benefit from the collaboration.
How do you ensure that everyone involved in the project develops and retains a common view of the project?
Of course, the retrospective in an agile environment is an opportunity to repeatedly synchronize the team's view of the project. However, I am of the opinion that this is far from sufficient in an initially assembled DevOps team. The team often worked together as a whole on the projector. In the beginning, we had the feeling that this cost us a lot of time, but in the meantime we think that it has brought us further than parallelization, because we were able to keep our focus much better and keep our status synchronized.
What is necessary to maintain or improve the motivation of those involved in the project?
This is not much different from pure Dev or Ops teams, but it is sometimes a very individual, person-related matter. In general, it is important that a team is not too homogeneous, neither in terms of expertise nor character, because then both positive and negative aspects are reinforced and there is a lack of diversity. On the other hand, a team does not work if it is too diverse. Therefore, one of the tasks of the scrum master is to get the fast ones to pick up the slower ones, to get the focused ones to collect the distracted ones, to make the loud ones understand, to let the quiet ones have their say, etc. This is easiest if you have a team atmosphere in which you can talk openly about strengths and weaknesses and ask colleagues for support to compensate for your own weaknesses. You can then find very good solutions in pairing. But I think it was also simply the case that we all really wanted to work together!
How did we manage to keep the focus on the essentials? Or: Is it "production ready"?
Self-reflection, stepping back and looking at ourselves, the project and the situation from a distance - this also only works as well as the openness and transparency in the team. What counts is to keep reminding ourselves as a team that decisions are made consciously and that we don't just get lost in the flow of work: What is the decision for us and our project that will bring us closer to our goal? One of my tasks as a ScrumMaster was to remind people of this.
Have you already had similar experiences or have you had to face other challenges? Let me know in a comment.
