READING TIME: APPROX. 3 MINUTES
What challenges did I face during my first DevOps project?
Listening to others, being open to new ideas
The team’s developers and technicians initially had very different perceptions of DevOps. That’s why one of my main tasks, time and again, was to ensure that neither the developers nor the technicians took their respective views of “the matter” for granted or considered them to be correct. Getting both sides to avoid taking anything for granted, to listen to the other side, and to be open-minded was the prerequisite for mutual enrichment.
It was important to create an atmosphere in which it was possible to admit when you didn’t (yet) know something, without feeling that you would lose the respect of your colleagues as a result. To that end, it was generally helpful to clarify and discuss the rules of collaboration early on in the project (though you’d do the same with a pure dev or ops team).
Staying Focused
Once the cross-pollination had gotten underway, the second challenge was to stay focused. New ideas are exciting; you want to try them out, even if the use case isn’t defined (yet).
Since we as a team had committed to a defined outcome, it was important to continually ask ourselves which tasks would bring us closer to that outcome and which—however interesting—would be a detour. We’re still working on making sure tasks are completed before starting new ones :-)
Ensuring that employees don’t take on too much
The learning curve is very steep when a DevOps team is first put together. While this is exciting, it’s also very exhausting. During learning phases, it’s especially important to make sure the necessary breaks are taken. After the first two weeks, it became clear that we needed to slow down overall to achieve this.
Personal challenge: Stay neutral
I think it was beneficial that I myself haven’t been actively developing for quite some time and am not personally tied to either Dev or Ops. It’s important that both sides have an equal say and value each other in order to benefit from the collaboration.
How do you ensure that everyone involved in the project develops—and maintains—a shared understanding of the project?
Of course, in an agile environment, the retrospective is an opportunity to continually synchronize the team’s understanding of the project. However, I believe that this is by no means sufficient for a newly formed DevOps team. The team often worked together as a whole using a projector. At first, we felt that this took up a lot of our time, but now we believe it has helped us more than working in parallel, because it allowed us to stay focused much better and keep our status updates in sync.
What is necessary to maintain or improve motivation among project participants?
This isn’t significantly different from pure Dev or Ops teams, but it’s partly a very individual, personal matter. In general, it’s important that a team isn’t too homogeneous, either in terms of expertise or personality, because then both positive and negative traits are amplified, and diversity is lacking. On the other hand, a team doesn’t function well if it’s too diverse either. Therefore, it’s part of the Scrum Master’s job to get the fast workers to help the slower ones catch up, to encourage the focused members to support the distracted ones, to make the outspoken ones understand that they should also let the quiet ones have their say, and so on. This is easiest when you have a team atmosphere where 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 through pair programming. But I think it was also simply the case that we were all really eager to work together!
How did we manage to keep the focus on what’s essential? Or: Is it “production-ready”?
Self-reflection, taking a step back, and viewing ourselves, the project, or the situation from a distance—that, too, only works as well as the openness and transparency within the team allow. What matters is that, as a team, we constantly remind ourselves that decisions are made consciously and that we don’t just get swept away by the flow of work: What is the decision that brings us and our project closer to our goal? Reminding the team of this was one of my responsibilities as a ScrumMaster.
Have you had similar experiences, or have you had to face other challenges? Let me know in the comments.
