Scrum smarter, not harder: Tips for agile development in the real world Part 1
If you research Scrum on the internet, what you will find, aside from pictures of what have to be some of the most badass/crazy sportsmen on the planet, is the following definition: “Scrum is an iterative and incremental agile software development framework for managing product development” (Source: Wikipedia).
What I have found is that Scrum is a lot easier to define than it is to implement.
I’m not going to explain the Scrum process itself in any real detail here. There are plenty of good books out there on the subject. Anything written by Jeff Sutherland, for instance. Instead, I want to share some of the things I’ve learned about how to make Scrum and agile development work in practice.
Figure 1. Scrum: Somewhere in that pile is a ball, and hopefully not a crushed engineer.
Lesson #1: Get on their level. In Scrum, the Scrum Master is in charge of running the necessary meetings, facilitating communication, and removing project blockers. You are team leader, agile coach, and productivity facilitator. You grease the wheels that make the company turn. But you don’t have any real power over anyone.
No one on the team reports to you. You have no hiring or firing power. Yet it is your job to somehow make sure the project moves forward as quickly as possible. Asserting your imaginary authority doesn’t work so well, so what can you do? The best thing to do is build respect and trust with everyone.
Figure 2. Being Scrum Masters is not like being Master of the Universe, but a guy can dream.
The team needs to trust that you know what you are doing, and that you are leading them in the right direction. And you need to trust that they will do what you ask of them without needing to micromanage. That’s how you can be a leader without having direct control over anyone. You have to stand on equal ground with the people you lead.
Lesson #2: The importance of being a SERVANT-leader. When I was promoted from Software Developer to Engineering Program Manager, I suddenly became project manager of several new teams of distributed data savants, real-time system gurus, and genuine ‘leet hackers, all of whom I was expected to lead through the Scrum process. So how do you lead a team of strangers?
Figure 3. Only the ‘leetest of hackers can program via keytar.
It all comes back to respect, and earning that respect. That’s where the servant in servant-leader comes into play. Ask the team what their problems are. Devote your time to removing their pain points. Eliminate their roadblocks so they can get back to the engineering work that they love. Show the team that you’re not just telling them what to do, but that you are getting your hands dirty, as well. And slowly, they will begin to trust you. You’ll stop having to ask them about what’s wrong, and instead, they will come to you directly with their roadblocks. And as long as you continue to respect them and show them that you care about their problems, they will continue to respect you and lend an ear to the things you say and suggest. That is how you can become influential without resorting to rule with an iron fist.
Figure 4. Besides, that thing looks itchy.
Lesson #3: Be as the reed. Another helpful tactic for establishing good relationships with your team is flexibility. With Scrum, this can be particularly tricky. Because Scrum is based on a two-week building cycle, each meeting is held at the same time for the same length with the same people every two weeks. And for some Scrum managers, any deviation in that schedule is stubbornly fought. But sometimes, processes and schedules that look functional on paper completely fall apart in practical implementation.
Take for instance the backlog grooming meeting – the time your team spends reviewing the tickets (feature requests, bugs, etc.) in backlog. In these meetings, you sort through which tickets are no longer necessary, which new ones need to be filed, and which ones need to be reprioritized. It is absolutely essential for any working implementation of Scrum, and it’s scheduled on a regular cadence. But life happens, and your engineers won’t always be able to make it to the meeting.
So what can you do? If most people can make it or the missing person is not necessary for the meeting to be productive, keep the meeting at the planned time. Other times, stubbornly sticking to the set time will mean an unproductive backlog grooming and thus being unprepared for the upcoming sprint.
This is where flexibility becomes so important.
- Can the meeting fit into shorter timeframe? Maybe it’s a light sprint and you don’t need the fully allotted time. If a shorter meeting means everyone can be there, it might be worth it.
- Can the meeting be moved to a time when everyone can make it? When you can’t shorten the meeting down, this might be the best option.
But what if neither of those are viable options? Consider getting everyone’s feedback individually. It will mean more work for you, but it will be worth it if it allows your sprint planning to go smoothly. And best of all, going out of your way to make things work for other people is one of the best ways to build strong relationships.
So remember young scrum master, when it comes to process, be as the reed. Bend, but don’t break.
Figure 5. Too literal! Stop bending!