Every compelling comic book character has an equally compelling origin story. Superman blasting off from Krypton. Spider-man and the radioactive spider. Captain America and the Super Soldier Serum.

I'm not a comic book character (as far as I’m aware) and I'm certainly no superhero, but given my fondness for both, I could think of no better way to start this blog than in the form of a professional Origin Story. Of course, I could write several origin stories - how I became a husband and father of two, how I became a musician and church band leader, or even how I got into comic books and superheroes.

This origin story will focus on my professional life and how I became a Professional Scrum Master, Agile Coach, and trainer.

Have You Heard of Scrum?

It was my first day on the job at GE Healthcare. My manager was showing me around, but the territory was very familiar to me, since I had been an intern there a couple years prior. As we approached a hallway with a bunch of sticky notes arranged on the wall, he asked me, “Have you ever heard of Scrum? Did they teach that in school?” I didn’t recall hearing that word in any of my classes and it hadn’t come up in my internships, so I answered that, no, I had no idea what that was.

He began to explain that his software development team used Scrum to organize their work. Everything the team planned to do was represented by a sticky note on this wall. In total, they represented 3 weeks’ worth of work. When they were done, they’d demo their work, scrap the sticky notes, and start again with another 3 weeks’ worth of work. Every morning, the team met for 15 minutes (although sometimes it was closer to 20-25 minutes) at the wall of stickies to update the wall and each other of their progress.

And so began my use of Scrum, a framework for team-oriented product development. At the time, I probably would have called it a methodology for software development. I wouldn’t understand the nuanced differences between those two phrasings or even why that mattered for several years.

What Came Next

I worked GE Healthcare for almost 10 years, starting as a co-op intern during college (alternating semesters of full-time work with full-time school), working through the Edison Engineering Development Program (a two-year rotational work and training program for engineers), and then as a software engineer. I loved writing code. Designing an elegant solution to meet the need was like a giant puzzle. And as someone who had heart surgery as an eleven-year-old kid, writing software in the medical device industry was incredibly motivating.

I loved the way the team worked together using Scrum. The transparency that the daily standup meeting gave our team, making all the work visible, and actually demonstrating what was accomplished at the end of each sprint was something I hadn’t imagined before. The way our team could quickly adjust to problems and the way they rallied together to get the work done was inspiring. I had worked in traditional project management before and found the concept of trying to make a work breakdown structure at the start of a project infuriating. How was I supposed to know what tasks I’d need to do six months from now? This new way of working made so much more sense. I loved it and never wanted to go back.

What I Do

Much has happened since my early days as a Software Engineer. I spent a few years as a Lead System Designer — a systems engineering role that is responsible for requirements, quality, compliance and a whole lot more on a project at GE. I moved on to Rockwell Automation working in IT as a Solutions Architect — I helped our IT organization understand the needs of Software Engineering and vice versa. All the while, I found myself infusing the principles of Scrum on whatever project I was on. If the project teams were actually using Scrum, I often became the defacto Scrum Master and/or Agile Coach, encouraging each team to work better together. If they weren’t formally using Scrum, I’d try to infuse as much transparency, inspection, and adaptation as I could, preferring shorter cycles, less upfront design, and more empirical and emergent design practices.

In 2017, I joined Centare, a consulting company that developed software for clients using Scrum and also offered Agile Coaching and Training as part of their services. I was fortunate to be on a team with several very experienced and talented Agile Practitioners, Coaches, and Trainers. I started as a Scrum Master for one of our clients, while training with my new peers and preparing to coach and teach Agile teams. I eventually began teaching Scrum using Centare’s home-grown courseware and coaching our clients in how to use the framework effectively. I found that training in a classroom setting, coaching teams to grow in agility, and especially coaching individuals one-on-one has been even more satisfying than writing code ever was for me. I help people work better. That’s hard to beat.

Why I Do What I Do

I love to see teams work well together. The intangible yet undeniable spark of energy that animates a team when they are able to produce real, valuable results is exhilarating. Watching as the light bulb flickers on and then gets almost visibly brighter as they realize that there is a better way to work that not only yields better results but actually makes work more fun is truly a deep, satisfying joy. It’s almost like watching a superpower engaged for the first time.

I also know the flip side of that happy path. The mild-mannered (and mind numbing) reality before the superpowers emerge. I’ve felt the dull drudgery from a mountain of work that not only seems never-ending, but pointless. The countless project updates where a Gantt chart that no one really believes is updated with a percentage that no one really has confidence in, all to someday release a product when no one really knows if the customers want it. It’s painful. And it doesn’t have to be that way.

I was fortunate enough to find this way of working that encouraged my teams’ autonomy, grew their mastery, and inspired them with purpose. I was introduced to this way of working that gives the team real, frequent feedback based on delivering actual, valuable working product rather than moving the needle 1.7% on a meticulously complex project management chart.

I want to help everyone work this way. I want everyone to be able to experience the satisfaction that comes from showing your work to your stakeholders, getting their feedback, incorporating into your next iteration, and doing the whole thing over again. While I work out how to get everyone on this path, I’ll settle for the teams I come into contact with in my professional coaching and training engagements, the people I meet at various Agile meetups, and anyone who will engage with me in a conversation about this radically different way to work.

Next Issue: Where Does He Go Next?

So that’s my professional Origin Story into the world of Agile and Scrum. So far. There’s more to come. This blog will chronicle my journey along that path, as well as share some stories of my work in this space, lessons I’ve learned along the way, and ideas I’ve crystalized while doing so.

At least that’s my rough plan. I’ll probably inspect and adapt as I go.