My first three Scrum teams—the ones that truly scared the bejeezus out of me—will forever remain in my heart as the kind people who taught me the tough lessons of letting go.

Stacia Viscardi’s Story

Stacia Viscardi, Agile Evolution

I’m Stacia Viscardi, and I want to convey a deeply personal story of change in hopes of helping you recognize the importance of listening to yourself and learning how to grow, even when it is quite uncomfortable and scary.

I have been a traditional project manager since 1993. I am also a PMP, formally trained in the lexicon of the thousands of certified Project Management Professionals who went before me. When I started managing projects, I took certain pride in my abilities to plan a project, learned how to enter data into a project management tool, held status meetings, negotiated with contractors and third-party sourcing for resources and materials, mitigated risks in the project and, of course, controlled scope. I could perform forward- and backward-pass calculations in my sleep.

Project management was a perfect fit for me, who, as a third-grader, resource-loaded my two sisters and I into weekly rotating chore schedules. I even designed a process for reducing the number of dishwashing loads by only emptying the dishwasher based on a pull-and-batch system (pull a dish only when needed, and no more frequently; gather all dirty dishes in the sink until time to reload dishwasher; reload all at once), but my father did not support this new approach. For me—a self-admitted control freak—project management was a perfect fit.

My conflict with Scrum, one of the Agile approaches to software development, began in 2003. I was vehemently opposed to this new, lightweight, not-sponsored-by-any-formal-governing-body methodology (or so I had thought). My life was turned upside down when Ken Schwaber came to train and mentor our team of managers and software developers. As a devout PMP, or perhaps as a result of still being relatively new to software development, I was a bit leery of Ken’s initial teachings about self-managed teams and iterative development. As I drifted in and out of the two days of ScrumMaster training, the line that caught most of my attention was, “You have no power.” Ken meant it in the sense that the product owner and delivery team roles would be collaborative in nature, and that a project manager wasn’t the decision-maker in Scrum. Like a mantra, I repeated this line to see if I could get used to it. I kept thinking, “How could you possibly manage a project or people without power? Wasn’t it a prerequisite that you had to muscle your way through a project and demand that people work overtime and weekends (but promise to feed them free pizza)? As the project team grew fatter and physically slower, didn’t this mean you could more easily beat them into submission?” (I kid, I kid.)

When my boss failed to show up to ScrumMaster training, I was automatically thrown to the lions as my (now ex)-boss’s replacement. Congratulations to me: I was the newly minted ScrumMaster of three project teams.

Wow. So now I had to lead people. I had never lead people before. I had certainly managed them, and collected the status of their tasks, and quizzed them on how much time was remaining on those tasks. And, of course, I questioned their estimates. (Everyone knows that developers are horrible estimators!) I sometimes even gave my helpful opinion on whether certain technical tasks were easy or difficult, much to the developers’ delight, I am sure.

Of course, what I didn’t realize at the time was that I really had no power to begin with. You see, I had always managed a group of knowledge workers—folks who grew up crunching numbers, writing complex code, creatively banging out products that at their roots consisted of only 1’s and 0’s. I truly believe that up until learning to lead, these knowledge workers merely tolerated me. I had never really managed them. They managed me by deciding to make me happy by filling out their timesheets. They humored me when I asked to be walked through the testing phase of the project plan, again. They certainly knew way more about how stuff really worked than I did. My life was ruled by impossible project plans. For a few months straight I made great overtime by staying late at the office to perfect the Gantt chart, knowing in my heart that it would be out of date the very next day, if not the very next minute. Often, I was asked to “create a dashboard” for the executives: a report that I knew reflected a false, positive reality. Now that I look back, I wonder how I survived the “manager” title.

My first thoughts turned to tracking the status of projects. How will we know “where we are”? How will we know how much value we’ve earned? (My CEO at the time had written a book on earned value management.) How will we manage scope? (I had produced a scope change management process for the department and had spent weeks perfecting the diagram.) Most frightening of all, I wondered how insane our customers would think we are since we’d no longer be able to tell them when they could have everything they wanted. And what’s with the paltry Scrum project tracking mechanisms? A burndown chart? What does that possibly tell us? That can’t possibly tell us if we’re on track! I want my percent-complete status reports! And let me say that the first few meetings with executives were disasters. I know that I left red-faced on many occasions.

All of these questions were fueled by the personal struggle I was going through: “Wow, if teams are self-managing, they’ll no longer need me. I don’t have a place in this organization now that we’re using Scrum.” I had no idea how to act within this new realm. I had a very real struggle with getting past the “me” and focusing on the team. I was also troubled with ownership issues. I routinely struggled with not owning the administrative task of updating the product backlog; for me, this represented scope, and not having it within my charge was very frightening. I felt powerless and as if I had no role.

Somewhere around the third sprint, I started to get it. Once the teams started delivering real value that could be seen and touched, the light bulb went on. What were once yelling product owners were now engaged, energized product owners, who actually worked with the teams to talk about the user experience, helping developers deliver valuable product increments. Observing collocated team members who were often heard laughing, working closely together, and enjoying their personal lives again touched me in a way that no perfectly calculated project Gantt chart or nested work breakdown structure ever could. I began to realize what it meant for teams to work at a sustainable pace and to focus their energy on what really mattered: creating software for the company that they work for, while being able to enjoy their personal lives the rest of the time (after all, isn’t this the foundation that keeps us all sane?). Coupled with a VP who “got it” and banned overtime for the department, the Agile principle of sustainable pace really lifted morale and improved the quality of work life. I even had time one evening to visit the home of one of our developers, meet his wife, and learn more about real Indian food. It was a wonderful, personal experience (and I now love soan papdi, a wonderful Indian dessert).

After my personal light bulb went off about the value of Agile development, I began to realize how I could provide value as an agile project manager. First of all, I let go of the backlog, and it relinquished its grip on me. By doing so, I gave control to someone else, namely the product owner, and let him prioritize the list. This gave me more time to focus on building teams. I moved into the collocated space with one of my teams, and I worked on justifying budget for other teams to collocate (and succeeded!). I created a newsletter for all of the project teams, called the Daily Collaborator, that included photos, stories, and interesting facts about the project. I learned how to report to executives, which was no small feat, by understanding their needs and by asking the team to help me determine how to show the project data. I made sure that stakeholders were involved in product reviews; sometimes it was difficult to get their time. I involved people from training and support in our iteration reviews and garnered their support in the testing lab when we were manually testing part of the system. I helped set up product backlog meetings that replaced our traditional change control meetings. I worked with customers as they implemented early releases of our products to gather feedback and understand how we could improve their experiences. And when I was in a period of quietness, I observed, observed, and observed some more—in the team rooms, daily standup meetings, reviews, and general team interactions. These observations helped me determine which obstacles to tackle next; I kept detailed notes and added tasks to my own impediment backlog when I saw a change or an organizational impediment that needed attention. I was a chameleon and a peacock at the same time, retaining the ability to blend in with the environment, while standing out and displaying my feathers when the environment needed to change.

We celebrated a very successful release nine months after instituting Scrum. It was a proud moment for us all; we had each traveled a personal journey and transformation unlike any other. Our release t-shirts said “Develop with Heart; Deliver with Pride.” That department of 85 people always will remain my fondest memory of a truly performing Scrum development organization.

My first three Scrum teams—the ones that truly scared the bejeezus out of me—will forever remain in my heart as the kind people who taught me the tough lessons of letting go.

The best day of my professional life was the day that I walked into one of my Scrum team’s daily meetings and the team looked at me, smiling, and said, “We don’t need you here, Stacia. Maybe you can use this time to work on other things or to help another team. We’ve got it under control.” And you know, they did have it under control. I walked away on the verge of tears, but the tears weren’t for me and my “loss”; they were from the happiness I felt at being able to let go and know that all would be just fine, and from the satisfaction I felt from helping individuals become empowered.

For me to cross the bridge to agility, I had to understand what it meant to put others before me. This wasn’t something that came naturally to me; because of a tough upbringing and lack of sense of self, I created a strong identity in my project manager title. I had to learn how to facilitate and listen for problems underneath the surface. Most importantly, I had to learn that the people doing the work know the work the best and will figure out the best way to get from point A to Z. All they really needed me for was to clear the path. They knew this already; Scrum helped me see it.