 Okay, Scrum for Developers. The stereotypical developer works alone. At home, without pants. Oops. He knows better than everybody else. He hates change requests, but he hates meetings even more. And above all, above all, he does not like to be managed. In real life, the developer works more often in an office and hopefully with pants. He is of course also she and they, and we never work alone, right? Whether you're building bespoke websites or plugins or themes for distribution, whether you work at home or from an office or from a beach in Thailand, you're at the very least going to be brought to work with your customers or clients and more often than not with other developers, designers and specialists in their field. We collaborate with others so that we can improve our products and services so that we can improve ourselves and our work. And to do that, we need to be able to communicate effectively. The word Scrum comes from the world of rugby and whether or not you like rugby, this image tells a compelling story about a team puddled together as a single unit working together to accomplish a common goal. Outside of rugby, Scrum is a framework for delivering complex projects. The roles, language and ceremonies of Scrum provide us a playbook for effective communication. Dave West says, unlike in sport, Scrum encourages you to always be sprinting so that you can deliver working software while continuously learning and improving. This is the embodiment of Scrum. Now before we can actually talk about Scrum, we have to talk about Agile, the philosophy on which Scrum is based. The Agile Manifesto defines these four values and says that while we value the items on the right, we value the items on the left more. We value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. There's often confusion, but Scrum and Agile are two different things. Agile is the philosophy, it's an attitude, it's a set of values and principles that serve as a guide to use to fall back on when confronted with difficult situations and decisions. While Scrum is the practical implementation of a delivery system. So I wrote this talk for developers and for talking to developers about Scrum because of some of the cultural hurdles and the stereotypes on both sides. These are things that I have encountered again and again in the 20-some odd years that I've been working in the web industry. There's this idea, and it's not specific to developers to be honest, this idea that real success can only be achieved alone. And because you're alone, you think you have to know everything, which leads people to think that they need to know better than everybody else. And that's just impossible pressure to maintain. The fear of change is something that we all have, right? And I've always found that ironic because we know that change is inevitable. And when we embrace change, we learn as we go. We embrace it and we allow ourselves to build better products and services and we get better doing it. Now similarly, I don't think anybody likes meetings, am I right? Especially the introverts among us, they take a lot of energy. And a lot of times they're called without real purpose or tangible goals and nobody likes to have their time wasted. And managers can also have a bad rap. Some can be rather domineering, maybe a little micromanagy and nobody either likes the feeling of having somebody breathe down your neck, putting pressure on you to perform. So Scrum addresses these hurdles. It empowers cross-functional teams to self-organize. It embraces change as a natural, as a normal part of the iterative process. And it clearly defines roles and ceremonies that are both value and goal-oriented. Okay, yes, there are a lot of meetings in Scrum. But each has a very specific purpose geared toward discovery, transparency, and focus. In order to build great things, we need to understand what we're building and why. We need to evaluate the risks and the challenges. We need to test the results of our work. Are we on the right track? Are our customers responding positively to what we're building? What have we learned that we can use to improve? So let's run through the events really quickly. The sprint is the heart of Scrum. It is the time box cycle, typically two weeks, but it doesn't have to be, that we define for delivering value on a project. What does that mean? Well, we don't wanna build something that somebody doesn't want, right? So rather than building a whole thing and waiting until the end to deliver it and get feedback, no, we're gonna build things in smaller increments. We're going to deliver small pieces frequently, get that feedback quickly, and then incorporate it back into our work. The sprint plan is not a plan in so far as we think we have everything figured out in advance because that never happens. It is a meeting to set the goals for the sprint. We want, and knowing that we're gonna discover things as we go. We define our tasks for the sprint based on those goals and what we think we can reasonably deliver. The Daily Scrum, yes, it's daily, but it's the best meeting ever because it only lasts for like 10 or 15 minutes. And it's a great opportunity to touch base with your team to make sure that everybody's on the same page and delivering on their commitments. A typical standup asks each participant, what did they accomplish yesterday? What are they gonna do today? And do they have any problems or impediments they need help with? Sprint review occurs at the end of each sprint and often includes stakeholders. They're an opportunity to showcase your accomplishments to demonstrate that functional working software and to get feedback on it. This is an interactive process. And they're an essential part of the iterative process because it creates real visibility for everybody involved. And finally, we've got the sprint retro. Now this is probably my favorite of all of the sprint ceremonies because it creates a real space for the team to evaluate how they're doing. It's a chance to not only celebrate everything that you're doing right, take a look at those things that are going well so that you can keep doing them, but also to take a candid look at what's not going so well and take actionable steps to correct them. Now when implemented correctly, all of these meetings are time boxed, which means that meetings don't run over. You give yourself a specific amount of time to focus on necessary aspects of each sprint so that communication is optimized and you create a sustainable cadence for the whole team. So let's look at the team. What's the first thing you notice? There are no project managers on a scrum team. Now this can be very disconcerting for the project managers amongst us, but that's gonna be another talk for another time. No, really, there will be another talk. So let's look at the product owner. The product owner is the person who keeps everybody focused on the business value of what's being built. They've got the big picture view. They know what we're building, but more importantly, they know why we're building it. They are generally in charge of maintaining and prioritizing the product backlog, maintaining the budget, and both reporting to and protecting the dev team from various stakeholders. The scrum master has two very important tasks. The first is implementing scrum, making sure that communication is open and transparent and that everyone understands the goals and the scope of the project. And secondly, removing any impediments from the scrum team that might prevent them from achieving their goals. Scrum masters are not merely meeting facilitators and it's not just another fancy word for project manager. They play an essential role in setting the tone for the team's interactions and for orchestrating a productive working environment. And then we have the dev team, which can also include designers, accessibility experts, and anybody else who is responsible for deciding how to build the thing and then doing the actual building of it. Nobody tells the dev team how to do their job. They are empowered to organize themselves to consider the goal set before them and create their own path toward achievement. But with that great freedom comes great responsibility. And for a team or a developer that seeks autonomy, you've got to be willing to make the commitment to the project. I know developers for whom scrum is not a good fit and that's okay. Some people prefer to execute without having to be responsible for the deep problem solving and the decision making that comes with an agile team. The trust goes both ways. And when it's in place, when all parties are working openly and full transparent, taking responsibility for their work, for solving problems together, it's beautiful, a joy. We challenge ourselves and we challenge each other and that shows in the work. We end up building some pretty extraordinary things and we can have a lot of fun doing it. Perhaps to my colleague, Than, who found this, this is from Alan Cooper, the father of Visual Basic, who touched on something really important in this Twitter thread and that I find is overlooked in the general discourse. When you hear people, when you hear developers, especially resisting or arguing against agile methods, it's a problem that you have to show your work. You have to be willing to expose work that's less than perfect to your team members without fear of being judged. So a successful scrum team is a team that cultivates an environment of safety and trust. Scrum is not a silver bullet for project management and delivery. Similar to code frameworks, a lot of times they are much easier and more straightforward in theory than in practice. In the end, we're all just people, flaws and all and no framework is going to replace the hard work and the determination that is required to have an effective, open and transparent communication. And this is where we have agile to fall back on and to look to for help because it's always people before processes, always. I'm afraid that's all the time I have. I have put together some resources for you here. My slides are online. I'm gonna tweet them out after this talk. I will be at the happiness bar just after two. So if you wanna dig in more and talk with me, I would love that. My name is Jenny Beaumont. You can find me at Jenny Beaumont on all the things. I am a senior project manager and certified scrum master at an amazing company called Human Made and we're hiring. So you can come talk to me about that too. Thank you for listening.