You may find that your individual goals for annual reviews come into conflict with what needs to happen to support your team. That’s something to take up with your leaders. It’s important to bring those goals into alignment so you’re not stuck in the middle.
In this episode, Richard and Peter answer the question: “Our team is adopting Scrum, how does my role (as a developer) change?” Obviously, you’ll be doing Scrum now and you weren’t before, but beyond the obvious, there are three big ways you can expect your work to change.
Learn More About Scrum
Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work Community!
In the past month, we’ve done episodes on what to focus on as a new ScrumMaster and what to focus on as a new Product Owner. This episode takes up a related question for the rest of the team: “Our team is adopting Scrum. How does my role (as a developer) change?” This is often the core question for participants going into our Agile for Teams workshops, which is the one we do to get teams started with Scrum.
But, before we jump into today’s episode… We want to help you with whatever challenges are most frustrating you right now. If you’re feeling stuck on something, whether that’s trying to take a more human-centric approach to your work, trying to make your product or your business outcomes better, or if you’ve just got a more tactical, process-related question, let us know about it. Send us an email at firstname.lastname@example.org with a few details about your situation, and we’ll share how we might think about that challenge right here on the Humanizing Work Show.
And just a quick reminder to rate and review the Humanizing Work Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you. Your help in spreading the word is super meaningful to us!
And if you want to get access to even more content we produce, not just the show, you can sign up for our newsletter where we share one key idea every week. Sign up at humanizingwork.com/hwnews.
All right, on to today’s mailbag question: “Our team is adopting Scrum. How does my role (as a developer) change?”
First, a reminder: “Developer” in Scrum refers to everybody on the Scrum team other than the ScrumMaster and Product Owner; all the people who build the product, regardless of specialty. If you’re a programmer on a Scrum team, you’re a developer. A tester…you’re a developer. A marketer…you get the idea. So, we’re talking to everybody else on the team with this episode.
Before Scrum, people have usually been working either mostly alone on a piece of something larger or they’ve been working on a functional team with other people who have the same speciality.
Here are three ways you can expect things to change when you join a Scrum team:
You’re going to be part of a cross-functional team now. A Scrum team is made up of all the skills required to get an increment of product, a slice of value, to “Done.” This means that what you call your team will no longer be people of your same specialty. Rather, your team will be those people who have a shared goal, a shared commitment, with you to get some increment of value done each sprint. You may still have some connection to your functional group, but that’s not your team anymore.
And that brings us to number 2:
Your definition of success changes. It’s no longer about getting your tasks done. Work comes into a Scrum team via the product backlog. In Sprint Planning, the team commits together to a set of items from the top of that product backlog, agreeing to collaborate to get those done by the end of the Sprint. Success, then, is contributing to that shared commitment.
Sometimes, that means getting tasks in your specialty done with extra urgency and focus because you see how they contribute to a larger goal on your team. Maybe you have people waiting on you. Other times, that means contributing outside your specialty because that’s just what needs to be done to move the most important work forward.
We talk sometimes in Scrum about the value of having T-shaped team members. Picture a capital letter T. The vertical line in the T represents your deep expertise in your specialty. When something difficult needs to be done in your specialty, you’re the person who’s most likely to do it. The horizontal line at the top of the T represents breadth outside of your specialty. You’re not the expert on everything, but you should be able to contribute to other things, more and more over time. Being T-shaped doesn’t mean becoming a generalist—there’s too much to know in complex product development—but it does mean developing both depth in something as well as breadth across a range of things to support your team’s shared commitments.
By the way, you may find that your individual goals for annual reviews and such come into conflict with what needs to happen to support your team. That’s something to take up with your leaders. It’s important that those goals come into alignment so you’re not stuck in the middle of conflicting goals.
All right, on to number 3:
When you join a Scrum team, your way of working changes. There’s an obvious version of that: you’re doing Scrum now, and you weren’t before, so now you’re doing Scrum events and using Scrum terms.
But there’s also a deeper version, which is to say that a Scrum team is always focusing on building two things: a product and a better and better system for building that product. You’re an important contributor to both of those.
That means, for example, that it’s important to understand why you’re doing each of the Scrum events; the purpose of those events– so that you can help contribute towards achieving that outcome. It’s important to think about these meetings as a key part of the work, not a distraction from the work.
You have a responsibility as a Scrum team member not just to build the product but also to build the team and the process.
The good news there is that you have the power to make your work better. The bad news, I suppose, for some people, is that your work is inherently collaborative now and isn’t just what you do on your own.
When your team adopts Scrum or when you join a Scrum team as a team member, your work changes in 3 ways:
1. Your team changes. You’re primarily aligned with your cross-functional Scrum team now.
2. Your definition of success changes. It’s about your team’s shared commitments now.
3. Your way of working changes. You have a new responsibility for your team and your team’s process, not just your tasks.
Joining a Scrum team can be a big shift for individual contributors. But it’s also a big opportunity to improve your work and increase your impact as you collaborate with others to build a team and a product together.
Please like and share this episode if you found it useful, and keep the questions coming to email@example.com! We love digging into tough topics, so send them our way.