When you think of Iowa, you might not immediately think of computer science firsts, but it was here that the world's first electronic digital computer was built and operated by researchers at Iowa State University in the 1930s. Since then, computing has come a long way, and the spirit of advancing computer science and development has never left the Hawkeye State. Iowa is also interesting from a geological perspective, as it is the only state bordered by two navigable rivers: the Missouri River and the Mississippi River. These factors made Des Moines, at the center of the state, the perfect place for both the DevOps and the Agile communities to come together to discuss how to navigate their challenges at Agile + DevOpsDays Des Moines 2024.

Over 500 Agile practitioners and DevOps professionals from all over the region got together at the Community Choice Credit Union Convention Center to attend sessions throughout the two days of the event. There were talks from 32 different speakers, including your author, who was able to share a session on rotating secrets at scale and the need for better secrets management and observability. This year also featured six different Ignite talks, shorter sessions that are only 10 minutes long, and Open Spaces conversations on the first day.  

It would be impossible to cover all the amazing lessons learned at this conference, so here are just a few choice highlights. 

Context is everything when it comes to incident response

In her keynote,"Using incident communication patterns to drive strategic roadmap changes," Nora Jones, Senior Director of Product Management at PagerDuty explained that complex situations, like production outages, require understanding the full context of who was involved and a deeper look at the details that lead up to the incident. Right now, most teams building incident reports immediately jump to the technical 'what' of the situation rather than taking a larger step back to understand the true root cause and how we can improve our systems and communication to prevent similar or worse issues. 

Nora said we get lost in the deep technical details, not considering what people are thinking about along the way. We are generally scared of finding bad data that point to larger problems. She cited Rian van der Merwe, who said, "It's not good or bad. It's just data." If we can face the facts head-on, then we can affect change in our organizations.

The realities of the modern enterprise have changed in the last few years. Instead of growth and customer acquisition at all costs, revenue is now king, and leadership teams demand positive cash flows. Instead of developers having the freedom to experiment, C-suites are making more buying decisions. Even the definition of 'incidents' has shifted and needs to consider much wider business needs. We need to engage in "cognitive questioning," finding the true root cause of our issues, which can only be done by understanding our communication patterns and engaging as humans with all the people involved in any incident. 

Why developers are not adopting your internal platforms

Adam Brunner, Engineering Advocate at John Deere, in his highly informative talk "Influencing the developer experience through advocacy, automation, and democratizing data," walked us through the challenges his platform engineering team has faced getting developer adoption inside their enterprise. With over 3,500 engineers, across 100 global teams, John Deere has faced a lot of challenges getting everyone on the same page to streamline all their processes. 

Adam explained they have categorized the issues of adoption into three areas:  awareness, desires, and skills. If the engineers are not aware that there are better paths, we can not expect them to take those preferred routes. They have implemented a way to track link clicks to see what messaging works and continually improve their outreach methods to get everyone informed. 

If it is a desire to use the internal platform and tools, we must identify why there is a sticking point. If we treat our internal users as customers, listening to what they actually want and why they prefer to do things their own way. This requires listening to them and empathy. If there is a skills gap, then a better learning path must be provided. Internally, they have implemented a system not just to teach skills but also to establish a way, through 'code katas,' that developers can practice these skills in a safe and supportive environment. Recognizing growth is also a key factor in leveling up developers. 

By the end, Adam said we must quantify the value of our internal development platforms in terms our engineers will understand. We must always listen to feedback as if they were our paying customers, valuing each decision the developers make. Finally, we need to focus on eliminating, or at least reducing, the toil on the developers as much as we can through automation if we really want them to adopt our 'better' tools and practices. 

A roadmap to psychological safety for your team

In their 'The Monkees' themed co-presentation, "Then I saw PS, now I'm a Believer: How to get the best out of your DevOps Team," Kara Burgan, Agile Software Engineer at MITRE, and Deanna Stanley, Principal Software Engineer (DevOps) and Group Lead, also at MITRE, walked us through their "Full Stack Psychological Safety" framework. This path towards healthier and more productive teams involves addressing this challenge in the phases of culture, community, conversation, contribution, and commitment.

Kara and Deanna walked us through each of these areas and showed us first what a healthy culture looks like at each of these steps. Even before you join a company, you can identify healthy work environments by their acceptance that you can't possibly know everything and expect you to learn and grow if you come aboard. Compare this to a LinkedIn job posting that damnd 20+ years of experience and the need to 'hit the ground running' for any technical hires.

How a company communicates is also key to building the psychological safety needed to build healthy teams. If your organization is always transparent and truthful with you, then you are much more likely to feel safe, even if there are issues and even layoffs. As a community, we must work to ensure everyone has access to the tools and resources they need to succeed. 

Conversation health allows and encourages everyone to ask the questions they need to ask to get their work done and understand why they are doing it without judgment. Everyone learns in different ways.

Contribution safety is all about valuing every person's work as significant. Teams should welcome individual initiative and passion projects as long as they help the organization reach its goals. This takes trust that our teammates are working for our greater good. Kara and Deanna said Commitment safety is the ultimate goal for a healthy team exhibiting true psychological safety. This means people can disagree authentically without injury. Failure is not punished but seen as a learning opportunity in these healthy ecosystems. No team can get here overnight, but it is the true measure of a healthy team. For anyone wanting to learn more about this approach and their framework, they referred us to their project website. 

A company's developer experience determines how it produces results

In his session "Streamlining Developer Experience: The Power of CI/CD Standardization and Interoperability," Jeremy Meiss, Director of Developer Relations at OneStream, said Developer Experience (DevEx) could either be a painful disaster or can be a magical and amazing experience. Good DevEx requires understanding existing workflows and defining our standardization goals before we start ripping and replacing tools.

Above all else, we need to prioritize tools that fit within your teams' existing ecosystem. We must align our DevEx with the organization's goals. Any coding standards we adopt should favor consistency and readability above other concerns. We must consider the next generation of developers who will follow the current ones. We should also try to leverage version control not just for our code but for our tools as well. If we can think of branching and pull request strategies for tool changes, it will be that much easier to understand how we arrived at the current stack. 

We can not neglect documentation and training. Any new tool or process must come with comprehensive training covering processes, configuration, and the best practices developers need to adopt to be most successful. We must try for fast feedback loops and streamlined workflows in our developer tooling, as we have done in our CI/CD pipelines. They are highly interrelated. Ultimately, an organization's DevEx reflects that organization's values.

Learning from one another makes all our communities stronger

Both the DevOps movement and the Agile movement owe their beginnings to developers who looked at their challenges and determined there must be a better way. While the Agile community focuses on the transformational change of systems thinking from a process and management perspective, DevOps is just another side of the same coin: implementing the processes and technology that Agile methodologies enabled. It was refreshing to see these communities uniting to understand better how they can help one another.

While there might not be a cross-community event in your backyard, we encourage you to challenge yourself and expand the circle of folks you are talking to about your challenges. This could mean attending a different conference or meetup than you might regularly consider or just sitting down for some coffee or snacks with another team you don't usually work with. You will be amazed at how much we have in common and how much we have to learn from one another. If you do get to DevOpsDays, BSides, or other events, keep an eye out for GitGuardian; we might just see you there.