6 Lessons for Non-Dev Executives at Agile Software Companies
Sunday, July 5, 2009 at 08:02PM 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.
Sound Byte
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.
Reader Comments (7)
[...] 3. Agile for non-developers [...]
Fantastic post, love your site! Will be referencing your work in the white paper series for Dialexica and the Agile Lawyers Association. Lots to do before publishing the start of our white paper series on the adoption and integration of agile principles and practices for lawyers. Care for an interview?
Thanks for sharing what you are hearing!
I am not sure I could call these lessons, but maybe areas of thought and improvement.
I hope some of the Rally marketing team who have moved from Scrum to Kanban and the hosted operations team who naturally feel into kanban take time to comments on some of their lessons.
It is clear hear that the delivery pace drove everyone to small batches, theory based decision making and a focus on learning fast. Without Gazelle's framework, we would not have the business rhythm to keep improving. For more on these concepts, see some posts and video that Jean and I have been doing on the top 10 Characteristics of an Agile Organization. http://www.rallydev.com/agileblog/2009/06/4-flexibility-and-rhythm-%E2%80%94-top-10-characteristics-of-an-agile-organization/
Great Article!
I spend a lot of time talking to clients about the benefits of Agile, but you're right, it's not a silver bullet. I like your last point "Maybe my department should be agile" - I've seen Agile used in a number of non-development business areas. In fact, before I ever became involved with Agile (and Scrum in particular) - I found myself using it within a non-software development business area and wrote about it for the Scrum Alliance: http://www.scrumalliance.org/articles/101-the-accidental-scrum
Really good post, I think this is relevant to the question of evolution vs revolution. Agile solves organisational problems that exist at any given time, but in itself it either creates new problems or gives greater focus to existing problems. I think this is a good think, continual improvement, rather than wholistic change
Rich,
this is the best article you've ever written, IMHO.
couldn't agree more. Agile isn't a "style" -- it's a modification to a company's business processes and other departments must re-tune their operations to make it really sing.
Luke, Great post and it is well aligned with my experiences. In my view scrum is more a management system than it is a development process and works really really well in certain non-development departments where the situation is similar to the development domain that it was originally designed to address. The concepts behind it are also apply very well to senior management. We have found that portions of it also apply to sales, but not nearly as well as Kanban applies to sales. Jeff Sutherland and I are actually in the pre-planning stages of getting a group of people together to compare notes on the topic later this year.