Dr. Scrum: Or How I Learned to Love Agile - Part One

I've been noticing a lot of product management blogs that begin "Aack! Development has gone Agile!" Recently I came across "Spotting Fundamental Flaws with Agile" in Pragmatic Marketing's magazine. You'd think we product managers had yet another business challenge and roadblock in front of us because now the development team is getting all needy because they want 'product owner.' Now, truth be told, it's a software methodology, but for us PMs sitting and collaborating with development on the latest products, these changes can have significant impact on our lives.

Agile is much better that what came before it. I've been doing product management for about a decade now. Remember what became before it? Pages and pages of PRDs, detailed technical requirements specifications, 9 month Gantt charts detailing in excruciating detail the development of your product? Do you remember? It was like entering NASCAR with cement wheels. A chasm the size of the grand canyon between product and development. I was directed to talk to the project manager, not development. The black box of months of development/QA/beta testing, that you'd beg to 'get a peak' at before launch. It was awful. My only way to help products get better was to try to forge relationships directly with the development team (beer helped), and talk about the product, and the users, and how great the product could be, then sometimes I'd be able to collaborate better, sometimes my IM would pop up and I could 'get a look.' Then, user testing (if there was any) was so long at the end of the product launch, there wasn't really a chance to change it before the launch date. It was bad. Soo...here's why I like agile.

Agile allows you to respond to market changes quickly. In SaaS software, your 2009 roadmap could completely change by March. Competition, new technical partnerships, business models emerge that may make you rethink what your organization is doing next month. You can completely chance course 2 weeks out in agile, and this was very hard before that. Agile allows an organization to be nimble in responding to market opportunities - and that can make a huge difference.

Agile forces you to think about what's important. One of the key tenants of agile is 'satisfy the customer through early and continuous delivery of valuable software.' Guess who's job it is to ensure what is valuable, and that it's delivered first? Product Management. This doesn't mean you don't have a roadmap, but it does force you to make tradeoffs so the needed features are the next iteration, and the 'nice-to-haves' are in the backlog.

Agile forces you to refine your communication skills about what the product needs. In creating user stories and acceptance tests, you need to both ensure what functions are critical for the next sprint, and what are not. It's light weight, but that forces you to be crystal clear on what you want the product to do. In PRDs, often what was critical was written along side with what was nice to have.

Agile seems to help the creative process of product development. I've been in two separate agile teams at separate companies and even working with different locations, Agile brings a certain level of creativity to development and product that wasn't their before. Being lightweight, it allows better collaboration and creativity with the end product. I think that's a good thing. The best software engineers I've meet have 12 different ways to develop a feature, and have suggestions on how to make the product better. I think Agile gives a process to collaborate creatively on product development.

Again, agile is a software methodology, and in many cases we have a new hat as a 'product owners' (Unless you are a very large companies and have analyst act as product owners). Unfortunately, agile is not by itself, the defacto rule of success in developing great products. We can arm/aid the development team to paint an accurate picture of the user of the product, their technical expertise and needs, and ensure there is adequate end-user feedback, market research, etc to validate the product user stories. Most companies don't have a list of checkboxes to answer "Are you an agile shop?" there's cultural and process changes that need to happen to make it work.

Next up? How I've tweaked my work life and communication style to develop successful products using agile.