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 Web 2.0 communities 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 Web 2.0 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.
Advertisement
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://www.agilecommons.com (the
agile community that is home to Rally's customer community and Agile University)
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.
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]
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.
Articles 
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.
