When the agile manifesto was published in 2001, a wave of enthusiasm took over the developer community. Finally a decent, human-centered approach to development, full of common sense to replace the construction-inspired bureaucratic processes that were the state of the art at the time.
But as the development community became more professional and the size of digital projects grew, bureaucracy came back. And now with agile in its name.

As pioneers of agile, devops and lean, with 12 years of experience on hundreds of successful software products, we want to fight back against that bureaucracy and maintain the enthusiasm of the early days.
To do this, we will go back, together, to the agile manifesto to understand its core DNA. And then look at what research tells us on how we can scale it.

There is no silver bullet against bureaucracy... but there is 70 years worth of research on the topic, that we have experimented with over the last ten years and that we believe deserves much more attention. 

Although leadership skills have been analyzed for so long, there is something in the way we choose and raise our technical leads that defy all laws. We often think that the brightest and most creative person in the team will eventually become a technical lead, which actually happens in most cases. The exciting part, though, the process of becoming a technical lead starts when we actually take over the role. What seemed to be a gratification for excellent results can become a long list of failures if you don’t really, really prepare for the challenge. Luckily we can learn from each other’s mistakes, so join us to touch some hot spots in the technical leadership journey. 

Engineering metrics have a terrible reputation — and for good reason.
That’s because most early attempts of measuring engineering performance were largely focused on tracking the activity of individual developers with metrics like lines of code, rework, and code churn. Yet, these metrics have no proven correlation with business performance. And in fact, they’ve done nothing but alienate developers, create mistrust, and misalign incentives.
But what should engineering teams be measuring instead?
In this session, we’ll walk through the seven persistent misconceptions that are still preventing engineering leaders from using data to improve their teams’ satisfaction and productivity.
We’ll also discuss the three areas of engineering you should be measuring if you’re looking to speed up software delivery without sacrificing culture or quality. 

CI/CD seems to be simple. But let's take a step back, and look at it from a helicopter view.
Let's think about the design CI/CD processes for the project, team, even organization. Let's go through "architecture of CI/CD". What areas should we cover? How to talk with Stakeholders about CI/CD when we design the backbone of DevOps driven Organization? 

Collaboration within open source projects is becoming increasingly important for companies, but it can be difficult to strike the right balance between the needs of the company and the open source project. This can create friction and put significant pressure on employees who participate on behalf of their company when the needs of the individual, the company, and the community are not aligned. This talk will focus on ways to create this alignment between individuals, companies, and the community to help all of us be successful together.
Communities are a critical component of open source projects, and the way that people participate can reflect positively or negatively on the person and organization that they represent. The majority of work in some projects, like Kubernetes, is done by people working for a wide variety of organizations, and the success of many projects rely on participation from these companies. The advice in this presentation will help people, and the organizations that they work for, improve their participation in open source communities.
The talk contains three major sections:
• Dynamics of collaboration in open source projects between individuals, companies, and communities.
• Strategies for participating in ways that will benefit your company, your employees, and the community.
• Tips for being a good corporate citizen as you contribute to open source projects. 

We love numbers, don’t we? If we are good managers, it’s natural that we want our people and our teams to get better. Incremental improvement is the mantra of agile philosophy and what better way of doing that than measuring things? Velocity, bug counts, MMTR, cycle time etc. However, there can be a darker side to metrics that we can easily slip into it if we are not careful. What starts off as a way to encourage and motivate a team leads to behaviour that is counter to what we want – stifling innovation and creativity as adherence to the metric becomes the prime driver. In this talk we look at common metrics we measure as tech leads, what they should and should not be used for and how, by developing a closer relationship with our team, we can dispense with metrics for something less harmful and more effective. 

As more and more companies are building tools and platforms that enable developers, the rise of DevEx programs continues to accelerate in almost every corner of the software world. In every one of these new programs I have seen two key mistakes that almost every organization makes. Some recover from them and some do not, but both of them can be avoided before you make them. Join me as I talk about what they are, why they happen, and how to fix them before they become a problem for your program. 

If you're building a product or service for developers, documentation can easily become a second class citizen: something to tackle once we get more funding, more headcount, or more traction. In this talk, I'll explain why that is a big mistake, and talk about how to build your documentation into a strategic asset.
When you are building for developers, documentation is critical from the very top of your funnel. That's because your documentation is content marketing: it contains the answers to questions your prospective users are asking.
Documentation defines your product, because developer psychology eschews glossy brochures in favour of nuts and bolts: your docs are how they decide whether your product creates value.
Documentation is your user interface: When a developer is using your product, they are staring at either their code or your documentation. Your docs are your brand and your user experience.
So how should we write it? I'll break down the different types of documentation: their audiences, how they differ, and how to make them work together. I'll also describe how to avoid the classic trap of shipping a pile of API documentation and calling it a day.
Finally, I’ll talk about how our users and customers can show us the way. By using our community - and avoiding thinking about this as “a problem for the DevRel team” - our users will show us where we can do our most impactful work. 

Wondering what it takes to build and lead a global, remote engineering team? Hopin’s VP of Engineering will share his insights on how to support your global remote team to quickly, efficiently, and successfully build products that meet customer needs and stay ahead of the competition.