With more than 10 years of experience in Scrum and Scrum-like teams, I finally decided to get certified as a ScrumMaster. What I thought would be obtaining a piece of paper, was in fact an eye-opening experience.
I strongly believe that a lot of my fellow developers don’t understand how empowered and self-organizing they can be. The key philosophy behind Scrum is that developers are experts who don’t need anyone to tell them what to do – because, frankly, no one really knows their job better than themselves. So, get the job done!
If I had 9 minutes to voice out just 9 important takeaways that I would like my developer friends to understand better, here’s what I’d have to say:
#1 Developers run the show
ScrumMasters are servant leaders, there to make sure developers are successful. It’s the development team that decides how much they can get done, size backlog items, and ultimately decide how to develop the features. That’s a lot of power, right there!
#2 There are no team leads
Developers are self-organizing experts. They don’t need anyone to tell them what to do. Developers are not order-takers, they are problem solvers.
If someone is trying to force their opinion in the team, then it’s time you have a conversation with them.
#3 Not everyone is ready to be a Scrum developer
Just like there are no shiny rock star developers, there’s little room for subpar performance. According to the Agile Manifesto, Continuous attention to technical excellence and good design enhances agility. Truth be told, attention doesn’t necessarily mean achieving excellence, but I definitely believe that experience is extremely important when defining a good development team.
On the other hand, working in a high-achieving Scrum environment is the best way to learn for junior developers, as long as the ratio favors experience. A small delta-force team in charge of babysitting a larger group of juniors is a recipe for disaster.
#4 With great power comes great responsibility
Each sprint, and in fact each story, should result in a potentially shippable increment. There are no explicit feature owners as your Definition of Done may include tricky tasks such as creating unit tests, functional test, defining design, peer review, integration, etc. Obviously way more than just writing that piece of code.
#5 Are you engaging the Product Owner enough
When your Product Owner rejects the story at UAT or Sprint Review then you know that you just wasted your time. Why? Because you should talk to the Product Owner continuously during feature development. Ask for feedback. Am I doing this right? Is this what you want this view to do? The Product Owner will be more confident, they will know what needs to change early on, and you will know what you need to change before it’s too late. It’s a win-win scenario.
On the other hand, Product Owners should hopefully be just as engaged and empowered to meet the demand and honor their duty.
#6 Technically, it’s all about Business Value
There are no technical stories. No refactorings. No architecture setup. No database initialization. Only business value. If you can’t express what you’re doing as business value, then you probably shouldn’t be doing it. Cleaner code is not business value, though. But 300ms faster route calculation is.
#7 Show your face
If you’re a co-located team, then you’re already crushing it. Being able to work in person is a fantastic privilege not enjoyed by distributed teams. Seeing faces is incredibly important for the team – increases trust, enhances communications, and even motivates the team. If you are working from home, get out of your pajamas, do your hair and show your face. You don’t have to brush your teeth, though.
#8 Improve communication
Some team members may be from cultures that value different kinds of communication and self-expression than what you’re used to. Some people are just shy. Encourage your team members, give them credit, ask for feedback. Let them learn that their opinion is valuable to the team.
#9 Wasting time is wasting life (and money)
Scrum meetings are timeboxed. Even if they were not, if 10 people wait 6 minutes to get that meeting started, a precious hour of cumulative time is thrown away and there’s no coming back. Be on time. It’s respectful. And finish in time. If you need to talk about things, schedule another meeting. Managing time requires efficiency.
Surprised?
Is this what you really go by in your Scrum team? I invite you to think about two of these points this week and see how much time you’re spending doing them.
I’m also interested in your experience. What did you like best? Do you have any suggestions? Share your thoughts in the comments section below. And happy scrumming!
