Several forces in the software industry are combining to dramatically shorten product cycle times for even the largest applications. These forces also shorten the feedback loops on an application's quality, usability, and customer relevance. As feedback loops shorten and the number of software deliveries goes up, it becomes paramount to inform and collaborate with employees, customers, and partners in a community setting.

Let me briefly share my perspective on how we can enable software teams to scale up their interactions from single-user conversations to collaborating across dozens, hundreds, and thousands of stakeholders. I'll also share my experience from the recent beta program of Agile Commons, a community where users, partners, and employees collaborated in an agile development process to define the top features during a seven-week release cycle.

Agile Makes Us Leaner - But Demands User Feedback Loops
Agile practices are being adopted by larger development efforts because they are intertwined with three forces driving fundamental change across the software industry - namely, software delivered as a service (SaaS), pay-as-you-go pricing, and Web 2.0 technologies. Together, these ideas are helping to wring out large amounts of waste in the software lifecycle and moving the industry away from shipping "products" toward providing software services that deliver a continuous stream of value.

While the software industry has been "doing" agile development for over a decade, what has recently changed? In the 90's, we were running small projects with XP and Scrum and delivering new releases in short time boxes. In 2007, the size of agile projects is increasing (e.g., Rally's Agile Lifecycle Management solution has many customers with over 75 users), while the release cycles are staying short. With multiple agile teams of developers and testers on faster cycle times, the importance of healthy user feedback loops skyrockets. So does the need to keep employees and partners apprised of the team's latest priorities and progress. Without a mechanism to quickly and openly collaborate with users on design decisions and feature rankings, you risk adding waste to the software process and delivering little value.

Producing rarely-used or never-used features wastes time and money in development, maintenance efforts, and opportunity costs. According to a Standish Group Survey, 64% of software features are rarely if ever used. [i] To avoid these losses, software organizations need to become masters of product feedback loops. Tight user feedback management and priority collaboration through flexible Web 2.0-based communities will become a required part of increasing agile scale and discipline. These communities provide a critical platform for engaging in dialogues, building trust, and encouraging promoters in the ecosystem of users, customers, and partners. They lead to deep customer understanding and less information hand-offs across the organization.

Why Agile and Web 2.0 Communities?
When people use the term ‘agile communities,' I think of consumer Web 2.0 communities like Facebook and mySpace that are tuned to the needs of agile development teams to test design ideas throughout the release cycle. Some of my favorite communities are those that actively engage the users - leaving behind the one-to-many publishing communication style of the past and bringing forward one-to-one and many-to-many communications of today:

• http://success.salesforce.com/ (Salesforce's customer community)
• http://www.dellideastorm.com/ (Dell's customer feedback community)

By engaging the user community to help you dialogue, debate, and prioritize features upfront, you can reduce surprises, eliminate conceptual defects, and increase alignment with the customer's highest priorities. These user communities also improve transparency into the development roadmap and enable customers to rank and discuss the changing backlog.

Traditional enterprise support portals and forums like support.microsoft.com or Oracle.com/support don't provide the flexible grouping, permission, or discovery mechanisms to drive dialogue and trust in dynamic user groups. However, advancing beyond these one-way, "publishing-first" paradigms and opening the organization up to a new level of customer engagement and visibility takes guts. Your agile practices need to be disciplined in order to support this extreme level of customer engagement and expectation setting.

To explore this transition to agile user communities, let's quickly look at what got us so disconnected from customers in the first place and how the Web 2.0 communities are so much more tailored to the feedback needs of agile organizations.

From Ignoring Feedback ...
A waterfall method of releasing and delivering a project or shipping a software product drove our industry to think about a linear process that ends with a release. That linear, hand-off-oriented process produced very large and long feedback loops. When our agile teams were acquired by BEA in 1999, our team grew by a factor of 10 and we slowed down to shipping software on 18-month cycles. We couldn't get actual customer feedback until half way through our next release. Because we had no room for feedback or change, it was too easy to turn a deaf ear to most of it after the design phase (in month four of 18). In this world, the focus of customer management is dominated by reactive support to their trouble tickets.

Once an organization has the maturity to scale software agility beyond single teams to whole product or program teams, the benefits of agile development get addictive to the business and users. Users start to expect a better product with short cycles that deliver the highest value enhancements. This reduced cycle-time tends to set new levels of expectation by drawing users into the feedback process. But, this agile process only succeeds if there is a highly visable, open channel for feature collaboration and timely feedback.

Does your organization have this? Most don't.

...To Welcoming as Much as You Can Get

In the pre-Web 2.0 world with large, long, linear, and late releases, software support teams typically used a workflow system to handle the flow of reactive trouble tickets. They might also have a support web site with frequently asked questions and a message board to dialogue with limited, and typically expert users. With the agile approach of welcoming change and shortening feedback loops, the thinking and infrastructure for supporting users has to change. Luckily, the advances of Web 2.0 community solutions can help us do that.

In these worlds, registered users have the ability to participate in ongoing dialogues with the company, partners, and other customers surrounding new features, roadmaps, and product usage techniques. You already know your users are online and building connections - you just need to become a part of that cycle. In Rally's community, our product managers have dedicated spaces for each major component area where users can propose and vote on features requests. The community voting process helps build consensus and allows the best ideas rise to the top. After all, the community is collectively telling you what its top 10, 20, or 50 features are. By focusing on the community and timely delivery on the top items, it makes customer expectation management and backlog justification and prioritization easier. This helps eliminate potentially 64% of development wasted by building the highest value and frequently used features for the broadest set of users.

Lessons Learned

In 2006, I started a gradual rollout of a Web 2.0 community called Agile Commons to a few dozen employees and customers. After 12 months, we opened the community at the Agile 2007 conference. As part of this community, we enable direct access to Agile Commons and a private Rally Customer Community from inside our product. Here are my top two items to consider as you start your move to Web 2.0 agile communities.

1. Your development house needs to be fairly mature with agile.

   If you open your backlog to community voting, customers are going to expect the top items get addressed on fairly short order. Your technical debt levels need to be burned down before you create this expectation. You also need to consider how much of your backlog should be driven by your current customers and set those expectations clearly. At salesforce.com, they report that well over 40% of their backlog is driven directly by their Web 2.0 community, and the top 10 ideas must be implemented within one release cycle or else they appear on a "neglected" list that gets special attention in the company's quarterly business planning cycles. [ii]

1. Start by finding, educating, and thanking the mavens.

   If your community is going to grow and be successful, the sharing of information and dialogues is going to be critical to creating trust and success. User-generated posts and comments can not go un-addressed. You need to engage all departments in your company by starting with the employees who are already comfortable bloggers. Those employees can help pull in the influencers and mavens in your user base. Once you pull them in, you need to provide means to support and reinforce their contributions.

As your agile adoption scales and matures, the drive to eliminate waste is felt in your entire business. The move to agile communities helps you get leaner and closer to your customers to really improve the quality and timeliness of your feedback loops. We'll build better products at lower costs that our customers value, while also increasing the effectiveness and happiness of our agile developers. The large-scale software game I knew in the 90's is thankfully much leaner today; I hope you are having as much fun as I am!

---

About the author

Ryan Martens is founder and CTO of Rally Software and is an expert in assisting organizations transition from traditional development processes to more Agile techniques. Before founding Rally - his fourth software start-up - Ryan directed the corporate adoption of Internet technologies within Qwest Communications, and then moved on to co-found Avitek, a Boulder-based custom software development firm where he served as Vice President of Marketing Business Development. Ryan's successful efforts at Avitek culminated in an acquisition by BEA Systems in 1999. At BEA, Ryan served as Director of Product Management for the eCommerce applications division and he was instrumental in growing that division to more than $50 million in revenue within its first twelve months.

Ryan received his Masters in Business Administration and his Bachelors of Science in Civil Engineering from the University of Colorado at Boulder. Ryan is an alumnus of the Colorado Chapter of Young Entrepreneur's Organization (YEO). Ryan is also involved in a variety of community boards including Colorado Conservation Trust, Entrepreneurs' Foundation of Colorado and the Agile Alliance.

---

[i] Jim Johnson XP2002

[ii] Figures taken from a panel discussion led by salesforce.com product managers.