Here is a really cool chapter I just read out of the book “The Software Project Manager’s Bridge to Agility”
Almost brought a tear to my eye.
How One Project Manager Crossed the Bridge
I’m Stacia Broderick, 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 project manager since 1993, agile since 2003. 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 1s and
0s. 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 (see Figure I-1). 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 agility bridge, 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.
Whereas Michele got it right away, it took me awhile. We each came
from very different places when embarking on our own personal bridges to
agility. Michele’s bridge was short and level; mine was a swaying suspension
bridge, on a 45-degree angle, fraught with high winds and torrential downpours.
What we both agree on is that since we’ve been helping teams—hundreds
of teams—move to agile methods, we have never been happier in our
professional careers. In the following chapters, we are pleased to present
some ideas for translating what you already know about managing projects
into your own agile paradigm. We’ll dig deeper into what you should expect,
how to successfully make the transition, and what steps you’ll need to take
in order to cross the bridge to agility.