Over the past seventeen years of my career, I have been a Scrum practitioner. As an R&D leader in 3M, we applied Scrum to advance software and data analytics research programs to inspire more digital capabilities into our product offerings. I stepped into a leadership role as the Director of Agile, driving the implementation of Scrum and Scrum@Scale in 2017, where we used these practices to become a strategic corporate research laboratory, transitioning away from its previous role of commercialization support to our product divisions. During that time, I was a customer of Scrum Inc. and was eventually invited to join the company in 2021 in a Scrum of Scrum Master role.
Recently, I changed roles at Scrum Inc. and joined one of our delivery Scrum teams. I found myself in a brand-new-to-me accountability as a Developer. I was excited to be onboard with this team, as I knew its members from the other roles I held in the company and was curious about how they leveraged the Scrum framework. After joining the first few events, something occurred to me – I have never been on a Scrum team as a Developer. Every other Scrum team I have been a part of has been either as a Scrum Master or a Product Owner. I didn’t think of this as anything but a new opportunity to create value for our customers and our organization. It felt to me like a way to get back to why I joined the company — sharing Scrum with others so they can experience all it has given me — happiness and joy working together as a team!
As I reflect on the experience so far, my main takeaway about being a Developer comes down to four small words – 1) How, 2) Can, 3) I, and 4) Help. My Scrum team lives by these words. My team consistently hears them over the sprint and in almost every event. It isn’t that I never heard these words uttered on a team, but being a Developer, it felt different, closer to the heart. Most of the time, when someone makes this offer to a teammate dealing with challenges, maybe they had to be out unexpectedly, or things just stack up, the offer isn’t accepted, but sometimes it is. Regardless, this habit builds a team-first mindset. It is about us as a team over myself as an individual. It feels different than when I had leadership accountabilities. To clarify their meaning in this context, let’s examine these four words more closely.
Word #1: How
In Scrum, the team decides how the work gets done during the Sprint Planning, where we plan to achieve the Sprint Goal together. In the role of Developer, there is a lot I don’t know about how we get our work done. This requires me to be more t-shaped than I have been before. Being T-shaped implies having a broad range of skills (the horizontal bar of the T) while possessing deep expertise in a specific area (the vertical bar of the T).
A T-shaped mindset is being willing to learn what is necessary to help my team achieve the Sprint Goal. Could I learn to do something new well enough to support a teammate? Could I help the team if something happened to a teammate? Simply stated, it’s about putting the team and the Sprint Goal first and helping where possible. I plan to continue to use this mindset to learn continuously – it’s an essential approach to being a good teammate. In addition, adding new skills is significant for increasing our value to the organization and our personal growth.
Word #2: Can
I felt like the new kid in class in the early weeks on my new team, even though I had relationships with everyone there for some time. There was so much that I needed to learn or understand as I was onboarding, and I still had a few things from my previous role that I needed to complete. However, I remember reminding myself there are things I can do while I continue to onboard. It was being an active team member and intentionally focusing on engaging with the Scrum Events.
Developers play a critical role in the Scrum Events. Active participation is a must. It demonstrates the Scrum Values and helps the Product Owner and Scrum Master perform their accountabilities more effectively.
The Daily Scrum is a key opportunity for re-planning. It’s essential to provide current updates, actively participate in problem-solving, and assist in removing impediments to achieve the Sprint Goal, much like I did as a Scrum Master.
Leading with the word “can” during the Daily Scrum is essential when dealing with changing circumstances requiring a response. Imagine getting a panicked call from a colleague first thing in the morning, asking for coverage of a customer-facing event, such as a training class. Saying “How can we” instead of “No, I won’t” out loud changes the mindset. Even though it’s scary, it does put me in the mode of solving the problem together, as best as we can, rather than doing the easier thing — making it someone else’s or another team’s problem.
Being open and transparent during the Sprint Retrospective was another opportunity for me to contribute to the team and help it improve. Every insight, every question, and every concern regarding the team’s improvement significantly affect the team’s chemistry and ability to deliver. This is similarly true for Sprint Planning and Backlog Refinement.
In Sprint Review, demonstrating the value created in Sprint can also support the Product Owner in building trust and confidence with the stakeholders. Understanding their priorities and communicating clearly and concisely helps lower barriers, fostering open dialogue and feedback exchange.
Word #3 & #4: I Help
This is two words. I combined these to emphasize areas where I can help my team as I onboard. I can help my team is by being transparent about what work I still need to complete from my previous role.
It is rarely a clean break from the past when transitioning into a new role. Some things need to be fully completed, and they need to be tracked. My approach is to bring as much backlog to my new team as possible so it is transparent to my new team. They could help me tie up the loose ends to focus on delivering value for the team as soon as possible without dropping essential things. I’ll admit that I have struggled most with this part of the transition, but I will improve as I work through the next few sprints.
You Can Use These Words Too
The Developer’s accountability is critical to the success of a Scrum team. Operating in that role has been a helpful personal leadership growth experience, helping me be more T-shaped to help my team deliver. It has deepened my understanding of Scrum. I feel a part of something EVERY DAY that is bigger than myself.
How are you going to help your team today?
Copyright © 2018 – 2026 Michaele Gardner and Brian Hackerson