The Project Manager’s Personal Bridge to Agility
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When I first started applying Scrum and Agile principles to projects, I was extremely uncomfortable. Before Scrum, I was accustomed to managing, controlling, forcing and ‘owning’ my projects. I was an expert scheduler, able to do forward and backward pass calculations in my sleep; I could turn any executive project dashboard into a work of art, with colors, charts and lots of bling. I had no problem asking people (including myself) to stay late and/or work weekends to bring the schedule in. I passed my PMP exam and felt extremely proud that I was mastering the profession of project management. Boy did Scrum really throw me for a loop.
While working for Primavera Systems in 2003, and having suffered at delivering products the traditional way, we brought in Ken Schwaber to teach us about Scrum. While I was curious about the terminology like ‘sprint’ and ‘scrum’ and ‘chickens’, I was very concerned when I heard Ken say that ScrumMasters had no power. My internal voice ran amuck. I’m going to be a ScrumMaster. What does this mean? How am I going to create a ‘Scrum schedule’? How are people going to listen and do what we need them to do if they’re self-managing? Won’t they just goof off? Oh, and if they’re self-managing, what do I do, then? That last question echoed in my skull. I knew that big change was ahead, and I was scared. After the second day of training, congratulations to me - I was #65 Certified ScrumMaster.
The day after training, my boss, the senior project manager, was fired. Congratulations to me again - I was now a ScrumMaster of three teams (which I strongly caution against the first time around). Our overall goal was to integrate our product with a third party tool that provided workflow and document routing/management capabilities, providing our customers a seamless experience. Gulp. How do we do that, one iteration at a time? Very carefully.
We chose a very narrow slice to deliver that first sprint, and we delivered it. We added on to the feature little by little, sprint after sprint, negotiated scope and watched it come to life. We built an entire portal around that feature. It was not easy. As the team was going through their ups and downs, I was definitely going through mine. It was about three sprints before I finally ‘got it’. A few times before that third sprint review, I almost quit. Let me give you some advice based upon my early transitioning experiences.
Scary Change
Whether it’s going off to college, losing a loved one, breaking off a relationship or taking a new job, change is tough to handle. Life changes can make us feel as if we have no foundation; everything that is familiar and reliable is now shaky and unstable. We have to recreate our realities. Moving to an agile way of development is a big change. In my role as a traditional project manager, I found immense satisfaction in planning and executing projects. In fact, I became quite adept at and actually liked creating schedules and reporting. Additionally, my entire life I fought my way up Maslow’s Hierarchy of Needs; coming from a poor childhood, getting my first job at age thirteen, struggling my way through college and finally getting a toehold in the corporate ladder. I was afraid of falling off the ladder and having to start all over again. Input change (becoming a ScrumMaster), and the output for me was an immense amount of fear.
While it might not be that big of a deal for you, change for most people shakes up and challenges the status quo. It forces us to dig really deep within ourselves to figure out how we’ll deal with the new circumstances. For those of us accustomed to change and its consequences, shifting to the role of an APM is probably a walk in the park. For me, however, I had huge anxiety about it.
Acting Out, and then Observing
What did I do? I grumbled. In my misery, I picked fights with the two other project managers (who were also struggling with change from their perspectives). I lobbied for special projects. I worked really late and tried to show competence by number of hours worked (I know). I left work on more than one occasion with tears in my eyes. But, most importantly, I hung in there. I paid attention and I learned. I saw how iterations/sprints worked. The teams started to deliver. The pieces started to fall into place, and my role began to emerge. Nobody could have predicted in the beginning just exactly how that would happen. As it turned out, my teams liked me. I liked helping them, and was impressed with their level of knowledge and experience. I began to learn so much. Most importantly, I learned how I could help others be successful. Going through tough change challenged my value system and on what I chose to prioritize. I learned to prioritize others’ needs before mine, for the sake of the bigger picture.
While you may not have a situation like I had, you might be struggling with how you face your feelings around competition, ego and trust, among others. The first thing to recognize is that if you’re struggling with the transition, you’re not alone. The “valley of despair” was coined by Virginia Satir in her Change Curve.
The Eye of the Tiger Team
Competition is completely normal. As humans, we are wired for it. What we must do is recognize when our inner Rocky Balboa starts to speak, and listen. I felt like I needed as much work as I could to justify my existence in this new, self-managing-teams environment (and I didn’t really want to share that work with my perceived competitors). I eventually learned to create a sense of team with my competitors. We worked in sprints, setting goals with time-constrained deliverables. Having a common goal with your perceived competitors (we will henceforth call them your teammates) will help you all focus on what’s most important: creating a streamlined development shop with plenty of visibility. That’s so tough that one person cannot do it alone; you’ll need help. Define teammates instead of enemies, and make it happen together. Gather strength and courage in numbers - you'll need that, too. Create your Impediment Backlogs and go for it.
It also helped me to find a couple of people whom I could trust and admired professionally and personally to mentor me. I knew that they would challenge me and wouldn’t let me off easily. This was a tremendous help in those early days. I learned to create and update a personal change backlog of things I wanted to learn, new ideas I wanted to try. I kept a journal so that I could go back and read it to see how I had progressed. This type of introspection was extremely valuable and insightful.
It’s Not All About Me?
Change implies letting go of vanity. We all want to feel as if we are valued and recognized for what we do. In agile methods, since our primary focus is to create self-managing teams, we must learn to feel recognized when our teams feel recognized. It’s not all about moi any longer. But before you become saddened by this, let me ask you: do you think it’s easy to help a team get to a self-managing state? Do you think that they get there alone? It takes strong leadership - of the servant kind - to get this to happen. It also takes a strong, courageous voice against interference from the organization to earn the team’s respect. There is much to feel proud of in helping a group of people accomplish this; pride like you have never known.
Build Upon Skills
It is important to remember that you already have great skills to build upon. While in this new agile way I had to release my inner taskmaster, I could still bring my planning skills to the table. I could ask the team questions to help them think through a perceived impasse. I could create milestones in the release plan to help manage drops from the vendor. I worked with the product owners to help them rank a backlog and think about releases incrementally. I saw over time that I didn’t have to throw out all the skills I had before; rather, I just utilized them differently and always from the perspective of leadership. I became a valued member and facilitator of the team.
Can I Trust You?
Many of our traditional processes cause a general lack of trust - from business to developers, from developers to testers (and vice versa), and in many other scenarios - it is difficult for us to trust others, or to know when what you’re facing from others is a lack of trust from them.
When we cannot trust each other, we cannot truly collaborate. It is impossible to have a solid, true team goal. [Read Patrick Lencioni’s book for more info about this.] A culture of trust starts with one person at a time taking the leap. This is probably the most difficult thing to do. We earn trust by trusting others. When it comes to your team, help them plan, help them understand the goals, go to bat for them, and then back off. Trust that they will do the work. Trust that they will come to you if they need help with something. And reinforce that you are there for them every step of the way. Become a bridge-builder yourself and help create trust between your team and the product owner. Show the team how to make its results visible. Invite the product representative to key meetings; don’t shut them out and whatever you do, don’t become a barrier to this key relationship. By modeling trust we can inspire others to do the same.
Back to my third sprint review, when I finally ‘got it’. We set up a big science fair-style review, with ten or so teams demonstrating product deliveries to senior executives and other stakeholders. There was laughter, serious information trading, ownership and responsibility of work, as well as suggested product changes. I observed true product collaboration between business and development for the first time in the four years I had worked at that company. Nobody was shouting, nobody was offended, nobody was let down. Eight months later, after lots of hard work, tough trade-offs, and interpersonal change for everyone, we delivered our first product delivered using an agile model. Our team t-shirts said “Develop with heart; deliver with pride.” I think it should have also said “We made the leap.”
I couldn’t possibly fit all that I’d like to write in this article, but I’d love to hear your questions. Or share a story about your experiences with transitioning. I focused mostly on values and interpersonal skills, and there is surely more to write about when it comes to tactical stuff like planning and executing projects, building a bridge, etc.