Cultivating Agility

Part I: Why Agile?

ProtoShare was originally conceived of to help the development team here at Site9 to better define and scope our own contract projects. We were literally our own first customer, which meant that the product feedback loop was very short and early versions of ProtoShare evolved somewhat organically, adding features as we realized what we needed. When we eventually released the tool to the public, we quickly discovered that most of our customers also had unique views of how prototyping fit into their organizations’ software development lifecycles. Today, nearly three years later, ProtoShare supports a huge variety of use cases and we have come to depend almost exclusively on customer feedback to drive the product forward.

Our goal with ProtoShare is to support as many common prototyping workflows as possible, while still providing a structured and clear path to success for all types of users. To help us achieve this, we catalog every feature request, brainstorm, and bug report that comes in from our customers. Being a subscription-based product it is absolutely critical that we can react quickly to our customer’s evolving needs. That means capturing feedback from thousands of companies, finding the common denominator, and finding a way to integrate it back into the product in a timely manner. This has proved increasingly challenging as ProtoShare has become an ever more sophisticated tool.

Changing a particular feature or workflow in order to benefit one group of users can often lead to frustration and confusion for others. Additionally, as new features inevitably snowball, large amounts of changes are made to the code and a much bigger burden is placed on our QA team. The best way to mitigate these risks is to deploy small changes as frequently as possible, or in Agile terms: “Just enough, just in time”. This allows us to deliver incremental value frequently, as well as to rapidly adjust to any problems that may arise.

Last year, as we began the huge development effort for ProtoShare 5, we realized that without a new development methodology in place it was going to be very hard for our team to determine which features to build first. The one priority that was abundantly clear from our customers was to improve performance across the board.With that in mind, we focused nearly all of our initial efforts for the 5.0 release on optimizing the underlying architecture of ProtoShare. From an engineering standpoint, this translated to a ground-up re-write of the existing code. Fortunately, doing this complete overhaul also gave us the chance to officially migrate all of our various development artifacts into a uniform format: Agile User Stories.

Prior to 5.0, our customer feedback, specifications, and feature ideas were stored across a variety of systems. We had data in spreadsheets, CRM records, bug tracking tools, and within ProtoShare projects. By combining all of this data into a uniform format we have put ourselves in a much more “agile” position going forward. Interestingly, as we began documenting and re-implementing existing functionality from ProtoShare 3.9, we also uncovered features that had crept into the product without any documentation at all. Closing these types of holes is essential for us to effectively detect and communicate changes to the software. Having a living collection of User Stories outlining every feature in the product is also extremely helpful when bringing new team members up to speed.

So, the tenets of Agile certainly suit our development needs, but how do we actually go about gathering and decomposing large User Stories, and what role does ProtoShare play for us amidst this new agile software process? In Part II of this post I will discuss in more detail how we use Agile behind the scenes and how we use ProtoShare in conjunction with Rally ( an excellent Agile development tool ) to support a parallel process which some have dubbed “Agile UX”.

(Read Part II: Under the Hood)