Jim Ebert is a Project Manager and Principal Scrum Master at ThreeWill. He has over 30 years of experience as a business and technology leader with demonstrated success in managing and delivering mission-critical projects and initiatives.
Introduction
As a Project Manager, I’ve always ascribed to the “servant-leader” approach, where I view my success as doing whatever I can to help those on my teams be successful. Whether that be through facilitation, support, coaching, mentoring, development, etc, I’ve never wanted to be viewed as a “command-and-control” leader.
My Introduction to Agile
As such, when I began to learn more about the Agile approach to delivering projects, where a Scrum Master’s role is to specifically be that servant-leader, I was very intrigued and excited to have the opportunity to move toward Agile project delivery management. I figured that even though I’ve been doing traditional waterfall-based project management for over 25 years, I have had that Scrum Master servant-leader mindset. I even went out and got my Scrum Master certification (CSM) and Scrum Product Owner certification (CSPO), wherein the training, I was eating up the whole Agile process.
Then came reality. I got my first Agile project. As a newly-certified Scrum Master, I went into the project thinking “I’m going to totally be in my element”, where I can facilitate and help the team do what they self-organize themselves to do. And where there’s no more long drawn out teeth-pulling waterfall processes.
What I wasn’t prepared for: I’m more command-and-control than I thought! Yikes!
What I Learned
Well, not so much around the facilitative part. But definitely in the command-and-control aspects around the planning and delivery process – i.e. detailed plans, clearly defined milestones, detailed requirements, etc. I quickly found it uncomfortable that we were coming up with estimates (story points) with just, in my opinion, high-level statements that I felt didn’t have real teeth. I mean, how do you have enough information to properly estimate with such little information? On top of that, without detailed, end-to-end plans and more clearly defined requirements, how can you come up with a true budget and timeline?
I know, I know. They told me this was how it worked in my Agile training. And yes, it totally made sense and got me really excited about this new (to me) project delivery process. But when it came down to actually doing it, I quickly felt outside my comfort zone. And although I’ve always been trusting of my project team members that they know what they’re doing, I found that because there wasn’t as much detail information and detailed-level planning that I was used to, I had to ratchet up that level of trust. Yes, I still need to ask questions/play devil’s advocate, but I have had to learn it’s okay not to know everything up front, to learn more detail as you go, and adjust accordingly when necessary. And that, in general, everything will be okay – if not better – since we won’t be going down an incorrect path for too long.
Conclusion
So why am I telling you this? Well, I’ve learned that switching from a more traditional command-and-control project management delivery style to an Agile delivery style is not a quick and easy switch. At least not like I had thought it would be. It’s actually a journey. A journey that takes time; time to adapt and let go of some old, more traditional project management style habits. Fortunately, I’ve been lucky on this journey. With the technical teams I get to work with every day, it has been well worth it!
