My Scrum Master Retrospective

As I come up on my 4 year mark of being a Scrum Master, I thought it was appropriate to practice a core tenet of what we teach and look backwards. Across multiple teams, varying from technical developers building & supporting products, engineers executing data migrations & project SoWs, and nontechnical folks looking to improve the platforms they rely on, I’ve been there coaching Scrum principles and helping fight the good fight. I want to write down what I learned, and while I’m not speaking from Scrum-God given authority, I do want to show how my experience has led to my perspective. Hopefully this is helpful, or at the very least interesting, for other Scrum Masters, Product Owners or Managers, and of course developers in Scrum teams.

Scrum is still Good

Wow. A certified Scrum Master thinks Scrum is good. Daring today aren’t we? I know, I know, but it bears repeating, albeit from another perspective. Well functioning teams are not well functioning because of Scrum. Teams are well functioning because they communicate, correctly share and exploit skills, are accountable, and are adaptable, all of which comes together to achieve a goal. Scrum is Good is not a tautology, Scrum is Good because it aligns and codifies the traits of a well functioning team.

If your definition of a performing team cherishes different skills or behaviors, or if you have been blessed with a good team using some other methodology or process, then congrats! Let’s remember that the point of work is to get work done, and Scrum’s purpose (to me) is to offer a process to make that happen. That’s all there is to it.

Get your hands Dirty

Scrum Masters, or Scrum Coaches, is a consulting style role, and it inherits the suspicion and scorn from daily executors that comes with it. To deny this is to deny reality and denial makes your own ability to lead or coach all the worse. You cannot walk in, tell people that they’re wrong from the safety of your ivory castle, and walk away. You need to get your hands dirty. Understand the tech, understand the goals of the project. A process that doesn’t understand the end goal isn’t a process, it's a distraction. And the longer you don’t speak the language of the foot soldiers who make the world go round, the longer you will just be a distraction in their eyes. Align to the Good of Scrum and be a servant.

Scrum is not a Silver Bullet

The waters may have been muddied out there, with salespeople selling their Scrum services to company leadership about how ‘one cool trick’ can help their developers turn water into wine. As I previously discussed, Scrum is just a detailed process for helping teams improve and execute, while aligning their output to what clients actually want. While this is powerful, you need a culture that is open to new methodologies and learning new tricks. This is why it's important to speak the technical language of the team, to improve those odds and foster the creative mentality to try new things.?

It is also important to introduce (and pitch) Scrum simply. That goes for its process, its capability, its impact, and its design. Scrum won’t make your product fly off the shelves, but it will build processes to improve inter-team communication. Scrum won’t enable you to increase your velocity by a factor of three, but it will enable better reporting and eventually projections. Hold the urge to oversell, because what we are really selling isn’t a silver bullet, it's a series of meetings & a culture of adaptability, which when executed correctly, is more bang for more buck.?

Roadmaps aren’t Real, but they Exist

I’ve made a lot of roadmaps. Roadmaps for feature enhancements, for projects, for cascading tasks to migrate data. These roadmaps were powered by pretty accurate velocity averages and team backlog grooming, but nonetheless, they were binned at probably a 50% rate. This is okay. A Scrum team cares about the current Sprint, the Product Owner about the next. Anything after that is, and should be, speculative. This sounds like I’m calling the purpose and process of building Gantt charts and offering timelines to clients a waste of time or an act of futility. But I’m not, because I learned the true purpose of a timeline. A timeline shows the opportunity cost, the road not traveled, the other option.?

In my experience, when a roadmap isn’t followed, it's because something has come up, the world has changed and the Scrum Team changes with it. So should we not build roadmaps 2+ sprints out and save three hours a week? Ehh, probably not. You still need the guiding light of your project. You need the context and your leadership team needs to know what's the impact of their off-the-cuff distracting priority. But maybe the lesson here is to remember that roadmaps are to be read more than they are to be followed.

Make them move the Tickets

Whatever tool you’re using, JIRA, Excel, Hubspot, whatever. If it has the tasks that outline work, developers (or the executors as I call them) should be the one moving the tickets from column to column. Not the Product Owner, not the Scrum Master, not their Mothers, no matter how nice they are. They move the tickets because it's their work and it's their process. If someone is doing this for them, then someone else is doing Scrum for them. Ownership is important to Scrum, and if they can’t own the daily process that takes 2 seconds, then they are not in the right mindset to do anything else Scrum offers. This should be the first thing you instill, since an active Sprint Board (or just task list) has large benefits to communication.

Jira is getting Good

5 years ago, Jira was a bit of a hot mess. ‘Next-Gen’ boards that were style over substance, ‘Company’ boards that took a Masters degree to manage. It was all too much and not enough. But since then, every release has been good over good. The shift to standardize Next Gen boards and make it feature rich has been well executed. Automation is easy to use and great for team notifications. Creating custom issues is a breeze! Roadmaps give you the tools you need to spend the right enough time on planning. And the new Project Management boards are slick with built in dashboarding that makes my Scrum boards envious. Good work team! I would recommend Jira for Scrum, doubly so if you need a customer service model and can use JSM. Now Atlassian just make the legacy back-end schema system somewhat understandable and I’ll kiss the ground you walk on.

Scrum is Work

I mentioned this earlier, but I like to describe the process of adopting Scrum as achieving ‘more bang for more buck’. Of course the popular phrase is ‘more bang for your buck’, as in you get more out of it than what you put in. I think you do get more out of a Scrum team than most non-Scrum teams, but let's be honest. Scrum is Work. Getting Scrum working for your team won’t turn your $1 into $2, but if you and your team focus, it will turn $2 into $2.50. You’re still in the positive, but the amount of work you put in did increase. Let's acknowledge that making new habits and adding 8 hours of meetings every two weeks is effort that many teams didn’t have to previously do, because by acknowledging this we come off less as Scrum salespeople and more like realists with grounded expectations, and a respect for new Scrum teams trying their best in an unfamiliar system.

Closing the Retrospective

It isn’t a retrospective unless there are action items that will impart change. If you don’t have actionable steps coming out of a retro, then congrats, you had a corporate sanctioned whine-fest, not a retrospective. Which hey, sometimes your colleagues need to be heard or need to vent, but they should be the exception not the expectation. So to follow my own guidance, I’m going to list a few high level goals for the next stage of my Scrum Master career:

• Make them move the tickets. I need to stop trying to be over helpful when it gets in the way of fostering accountability from the ground up.
• If they don’t touch the tasks, they aren’t doing Scrum, or Kanban for that matter. Likewise, I have done one too many projects where I manage task state. That makes me a manager, not a Scrum Master. And even if I am in a manager role, I want my devs to follow Scrum or Kanban principles!
• Ask harder questions, and don’t put answers in people’s mouths. If the expectation is that an Scrum Team personnel is to do an action, and they don’t, I should ask why. And I should set expectations going forward. People rarely improve without outside stimulus, and I shouldn’t be afraid about being that action.

Hope this was interesting, and thank you for reading. The past 4 years I have learned a lot with truly great people, and I’m eager to continue learning.