Hi, I am Daiany!

More than 10 years into the DevOps movement, by now we know that it’s not just a job. We know the truth about DevOps (do we?) and understand that in principle there is not such a thing as a DevOps Engineer or a DevOps Team. Yet, our industry needed to find a label, a way to name the new role which Sysadmins or Developers were further growing into. Today, job ads for “DevOps Engineers” are everywhere, with diverse descriptions. I went through the hiring process for such a position in my team last year, and after interviewing a decent amount of candidates I started reflecting: How is this role going to evolve in the future? What about the next generation of “DevOps Engineers”? How do we get them “fresh” out of university”? How does someone come to the idea of starting their career in this field at all? In this ignite talk, I’ll share thoughts on nurturing the next generation of DevOps professionals. With patience, because we need tomorrow’s DevOps Engineers, today! :P

About two years ago I was faced with the task of building a team from scratch, to rebuild and redesign an old application into a new one, more modern and flexible to include a lot of new requirements. I managed to build a small “DevOps” team which delivered successfully a first version of the new application. Today it is actively used in PROD, and continuously further developed. Leveraging public cloud, the team can cover the whole delivery chain in a “we build it, we own it” fashion. So far, so good, until it was time to scale. In this ignite talk I want to tell the story about why my team is stuck in the face of the application scaling that is upcoming. I will be basically making a point of the need for a shared self-service platform approach on a corporate level, so that teams like mine can lift off.

About a year ago I was faced with the task of building a team from scratch, to rebuild and redesign an old application into a new one, more modern and flexible to include a lot of new requirements. Counting with enough budget I started by proposing a usual setup: a system analyst (requirements engineer), a few full-stack, a tester and a DevOps engineer. However, the budget available at the end was allowing me to hire only 3 new employees. I went for the following setup: one system analyst and two full-stack DevOps engineers. “Full-stack DevOps engineer”, is that even possible? Well, I guess my colleagues would probably disagree to be called like that, though at the end that pretty much covers what they are effectively doing in the team now. In this ignite talk I want to share some thoughts to further sparkle an opinion exchange with the audience about the scope of these two roles “Full-stack vs. DevOps”. Based on my experience, I will put the focus on the actual minimum skillset necessary to develop and maintain a system when the “usual” role-specific constellation in a team is simply not possible. What to search for in possible candidates? What to keep in mind and how a team dynamic could look like, in order to succeed. Daiany Palacios IT Product Lead Customer Care & Verticals @ Kuehne + Nagel I work at Kuehne + Nagel for the Customer Care & Verticals Product Group in Hamburg. Originally from Venezuela, I joined the company in 2011 and have had different roles so far. Today I can better be defined as an IT specialist with a broad range of experience: starting as a software developer, I’ve been business analyst, agile facilitator, conference speaker and devops engineer. I am a lifelong learner, convinced that if you try hard, you can get good at anything. I like challenges and I face them with energy and courage. I am passionate about continuous improvement & exchanging experiences with the tech community.

With the growing cloud adoption, we constantly find new roles in the market that didn’t exist a short time ago: “Cloud Native engineers”, “Cloud Architects”, etc. Where do suitable candidates come from? My answer: people evolve into those new roles. For companies it’s faster to find people with the right (but not necessarily perfect) combination of the required skills and the right mindset in this way than trying to find someone filling in all new job requirements. For us, employees, it’s a chance to grow and take on new professional challenges, which is usually combined with a boost on the motivation (and on the salary!) Stepping into the unknown requires courage. I went through this adventure between 2019 and 2021 when I joined a cloud-migration project as an engineer in a platform team coming from a system analyst role in a product team. The technological learning curve was very steep and difficult, but other kind of skills were my key to tackle the challenge and not to lose sanity in the way. In this talk I will take the audience in a journey from catching the opportunity, starting in the new role, growing into it and learning to be prepared for whatever is coming next. I will provide tips on how to improve our self-confidence, self-awareness, adaptability and effective learning through storytelling with daily-work examples that anyone can hopefully use whenever it’s time to step out of the comfort zone and grow into any new role, even beyond the cloud.

Panellists: Yenny Cheung (Engineering Manager, Yelp) Daiany Palacios (DevOps Analyst/Engineer, Kuehne + Nagel) Dominika Rogala (Engineering Manager, Vector Technologies) Amir Safavi (Software Engineer, Google) Estimating projects is hard. Whether it's negotiating technical debt, understanding new requirements, or grappling with a lack of useful documents; the number of moving variables make it difficult to judge just how long a project will really take. So how do we reckon with estimations? Do we try to get a deeper understanding of the task, account for overpromising, and try to story map a project? Or are estimations too much hassle for the value they provide? In this session we’ll hear from both sides of the estimates/no estimates debate, dive into the problems that are currently apparent, and try to begin a journey to more accurate estimations.

¿Y si lo escuchas mientras vas al trabajo o te pones en forma?: https://www.ivoox.com/48497684 ------------- Site-reliability engineer roles did not exist 10 years ago. With the growing cloud adoption, we find roles in the market that didn’t exist 5 years ago: “Cloud-Native engineers”, “Cloud-Architects”, etc. Where do suitable candidates appear from? My answer: people evolve into those new roles. For the companies it’s faster to find people with the right (but not necessarily perfect) combination of the required skills in this way than trying to find someone filling in all new job requirements. And for us, employees, it’s a chance to grow and take on new professional challenges, which is usually combined with a boost on the motivation (and on the salary!). It’s a win-win situation. Stepping into the unknown requires courage. I’ve been in this adventure since early this year when I joined a cloud-migration project as an engineer in a platform team coming from a system analyst role in a product team. The technological learning curve has been very steep and difficult, but other kind of skills have been my key to tackle the challenge and not to lose sanity in the way. In this talk I will take the audience in a journey from catching the opportunity, starting in the new role, growing into it and learning to be prepared for whatever is coming next. I will provide tips on how to improve our self-confidence, self-awareness, adaptability and effective learning through storytelling with daily-work examples that anyone can hopefully use whenever it’s time to step out of the comfort zone and grow into any new role, even beyond the cloud. ------------- Todos los vídeos de DevOpsDays 2020 en: https://lk.autentia.com/DevopsDays20-YT ¡Conoce Autentia! Twitter: https://goo.gl/MU5pUQ Instagram: https://lk.autentia.com/instagram LinkedIn: https://goo.gl/2On7Fj/ Facebook: https://goo.gl/o8HrWX

Ignite Talk delivered at the joint Ignite Event of the O'Reilly Velocity & Software Architecture Conferences in Berlin, November 2019

Kanal abonnieren ►► http://bit.ly/lwipshhsub Werde Teil der Community ►► http://bit.ly/lwipshhmeetup Infos zum Video: Folgendes hast du sicherlich schon erlebt: Das nächste Stück Software ist so schnell wie möglich zu entwickeln. Zwei Teams werden gefragt, wie lange sie brauchen würden. Team 1 sagt 5-8 und Team 2 6-9 Monate. Der Abteilungsleiter steht aber unter Druck, er soll einen Liefertermin nennen. Er nimmt daher einfach 7 Monate, Durchschnitt beider Teams und so basiert auch der Rest des Projektplans auf Mittelwerten. Inspiriert durch das Buch "The Flaw of Averages" erklärt unsere diesmalige Half Hour Heroine Daiany Palacios, warum Pläne, die auf dem Durchschnitt basieren, in genau diesem Durchschnitt dann versagen. Gleichzeitig wird sie eine konkrete Alternative aus aus ihrem Arbeit präsentieren, wie auch du diese Schwachstelle bei Software-Entwicklungsschätzungen umgehen kannst. Daiany Palacios arbeitet seit 2011 bei Kühne + Nagel für das KN FreightNet Projekt in Hamburg. Ursprünglich aus Venezuela kam sie als Softwareentwicklerin zum Unternehmen. Heute arbeite sie u.a. auch als Requirements Engineer und unterstützt die agilen Coaches des Unternehmens bei der Moderation agiler Retrospektiven. Ihre leidenschaftlich für continuous improvement lässt sie immer wieder nach Wegen suchen, die Arbeitsweise des Teams zu verbessern, um die versprochenen Ergebnisse auch zu liefern. In diesem Sinne war sie von Anfang an vom Continuous Probabilistic Forecasting Ansatz begeistert dieser in einem ihrer Teams eingeführt und etabliert wurde. Der Vortrag war Teil des Treffens der Limited WiP Society Hamburg vom 06.08.2019 Ein besonderes Dankeschön geht an unseren Raumsponsor Kühne + Nagel ►► http://www.kuehne-nagel.de/ sowie an Lukas Schmidt und Peter Schwind von der Deutsche Telekom AG - Mayflower für die freundliche Unterstützung beim Bearbeiten des Videos.

The next piece of software is to be developed by 2 teams and they now have to answer how long it’s going to take. Team A says 5-8 months and Team B 6-9 months. But the department head is under pressure to deliver a date, so he takes 7 months as the average of the 2 teams. In this talk I will explain why average-based plans fail on average, then take a look at the psychological problems we humans have dealing with probabilities as a possible reason why we keep falling into the averages trap. Finally, I will show a way to avoid it when it comes to software development estimates.