Bryan Snow

I’ve always been a bit of a computer nerd. My father was a project manager back in the olden days when waterfall ruled and product ownership was about marketing and novel sized requirement documents. I would go to his office in Salt Lake City for a hamburger from time to time, and see Gantt charts taped to the wall, a dozen feet long and higher than I was tall. Project Management looked amazing and so complicated. As a tech geek, I remember vividly the day he brought home a brand new 486 DX2 66 computer. That thing was so fast! I remember first getting excited over DOS, and then, Windows 3.1, and then Windows 95, the Operating System to change all Operating Systems. Later I enjoyed building computers and optimizing them to play StarCraft, Unreal Tournament, and to occasionally chat with friends on the dial up bbs, LowerLights. Ahhh… the good ol’ days of geek techdom.

Then one day I grew up and got my first big job, working with an internet startup during the glorious years of the dot com bubble. I create web pages and toyed with technologies such as Server Side Includes and CSS.

Then the .com bubble burst… Time to start over…

I went back to school and majored in clinical psychology. People are so interesting. It was fantastic! But I still loved computers and software. So over time I found myself working with IT once again, this time helping facilitate communication between a group of account managers and a dedicated development shop nearby.

I kept my ear to the ground for new opportunities, and similarly kept my resume up to date, logging experience and successes. One day I took my resume to a recruiter and asked, “What kind of a resume does this look like to you.” With a little thought he responded, “This looks like a project manager’s resume.” Little did I know at the time, but I had been building sprints and managing projects following a scrum model for more than a year! The dev shop had been quietly teaching me simply by asking me to manage the work request a specific way. And thus began my journey to where I am today.

As a child I envisioned myself growing up to be a train engineer. Finding, instead, that I had grown up to perform a mix of project management and product ownership roles seemed oddly fitting. Rather than helping to move physical products, I had begun helping to move software, from concept to complete functionality. I spent my days working with account managers and their customers, then translating what I had learned into user stories and tasks our development team could work through.

Now, years later, I’ve managed Web Operations for a large company, I’ve had great success as a consultant to billion-dollar corporations, and I’ve done my time at a tech start-up. As I continue my career, I find that I am lucky enough to do what I love. This is not because I love software development on its own, although being part of great software development does have it merits, but because I love the servant-leader model of Agile and Scrum. Scrum provides for teams of cross-functional equals, working toward a common goal. QA is involved in planning, devs are involved in QA. Product Owners communicate with customers directly, and ensure the product vision is clear to the team. Scrum Masters help the whole team identify and remove impediments and run short and efficient meetings.

The best teams I've worked with have been Scrums teams. A shared vision, a well-groomed backlog, and an opportunity to learn from mistakes and to showcase good work has led to great morale, great products, and happy stakeholders.

I feel lucky.

My Dad was a great Project Manager. The SDLC model he spent his career working with is not the same model I work with now. I'm fortunate that much of the innovative groundwork for a new style of project management was laid before I truly began my career. Jeff Sutherland and Ken Schwaber publicly laid the groundwork for Scrum in their 1995 paper presented at OOPSLA(1). In February 2001, seventeen software developers Agile Manifesto met at Snowbird, Utah and developed the widely known Agile Manifesto(2).

Innovation will continue, but amazingly even now, there is much to do to help companies realize the benefits of being Agile. Scrum works best with a more collaborative company command structure than the top-down hierarchy of times past. With the right culture Scrum is easy to implement. Changes in people, though, culture changes, are not as easy. In the meantime, the world keeps turning, and hopefully, each day I'm making positive contributions not simply to a corporation's bottom line, but to each individual with whom I interact, helping to build an agile company culture, strong teams, good morale, and great products.

Sources:

1. Sutherland, Jeffrey Victor; Schwaber, Ken (1995). Business object design and implementation: OOPSLA '95 workshop proceedings. The University of Michigan. p. 118. ISBN 3-540-76096-2.

2. Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance.