Jul 31, 2009 3 min read

6 Lessons for Non-Development Executives at Agile Software Companies

6 Lessons for Non-Development Executives at Agile Software Companies
Photo by Luca Campioni / Unsplash

In many conversations over the last few months, I’ve see executive teams grappling with the positive effects of agile software development on their non-development processes and organizations. If you’re a VP of Marketing or Sales or Finance or Operations or Support at an agile software company, or one that is becoming more agile, improvements in how we build software will be shaping how you think about the software business and non-engineering departments. Here’s a short list of items that you need to consider in the face of increasing agility.

1. Agile development doesn’t solve market problems.

The biggest drivers of product success are external: choosing segments, identifying important customer needs, executing the sales process well, and pricing for value. No matter how fast (and how well) Engineering does its thing, whole products are a blend of pricing, marketing, segmentation, sales channels, messaging, positioning, packaging, and technology. We’ve all seen companies with mediocre software outsell technically superior competitors. Don’t be hypnotized into believing that Engineering will ever replace Marketing, Sales or Product Management. (FYI, a public example of this is the original market research we conducted with Borland in February of this year.)

2. We need fewer strategic priorities.

More than ever, current economic environment demands that executives make a few strategic choices, fully fund projects against them, and have a roadmap that honestly sequences the work. Fortunately, this is exactly what Agile methods require for success. Our old approach of “peanut-buttering” insufficient investments across dozens of “priority-one” initiatives, with everyone working on three or more projects, gets exposed under agile as grossly inefficient. (Check your burn-down.) The entire executive team needs to agree on the top two priorities, admit that everything else is #3 or lower, and then hold product management accountable to creating and managing their priorities – and development to demonstrating actual progress.

3. Improvement won’t be instantaneous.

When Engineering and Product Management start along the road to agile, give them at least a quarter to regain their original waterfall productivity and two or three more to really rock. Big organizations will probably need 18+ months to roll out serious change. Don’t hover after 3 weeks and start micromanaging velocity. (Our colleague Jeff Sutherland reports that extremely disciplined use of Agile methods can produce results more quickly. But as corporate executives, we want to manage our own expectations.)

4. The bottleneck is moving elsewhere.

As Development catches up with its backlog – shipping twice as much software with higher quality – other parts of the company are being stressed. Channel Marketing has to brief resellers twice as often, Marcom must revise collateral every quarter, Support needs training on the latest update, Operations has new bundles to create and price lists to change. Finally, Sales has to deliver real revenue against the improvements it demanded. (“I know I told Engineering that we could close $16M if we added Finnish and Swedish versions… “)

5. We need much better and much faster market input.

Marketing used to field one annual customer satisfaction survey and take suggestions at the annual User Group. Now, dozens of product owners are raising product issues in real time. Product teams need to get rapid qualitative market inputs aligned with two-to-four week cycles and continue to do long-term market research. This means thinking about market research differently. And once we have dozens (hundreds) of agile teams, Portfolio Management needs to make sure we have a coordinated way to collaborate with busy customers about large as well as small issues.

6. Maybe my department should be agile?

Lately, I’m getting asked about applying agile (or lean or scrum) to Marketing or Finance. This feels backwards, though: applying a method without thinking through the need. Scrum may be a good approach if your Marketing team is having trouble tracking deliverables and effort… but begs the question of how to track Marketing results rather than just activity. It may be challenging to apply “done done” completion criteria to everything in Product Management (or Marketing or Finance or Operations) since some results take a long time to prove out.

FYI, I’ve heard that Serena‘s Marketing groups runs itself using scrum, and Open View Partners is running an entire VC firm via scrum, so there are some real-life examples. There are also strong parallels to the Gazelle framework and Agile methods. Love to hear about your situation below or in the twittersphere.

SoundBytes

An agile software development team creates challenges as well as opportunities for the rest of the company. To gain the benefit of the opportunities while minimizing the challenges, think holistically about markets and customers and focus on the Agile business.

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Rich Mironov's Product Bytes.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.