Benefits of Agile: Increased Customer Collaboration

Over the course of the last year, CURTIS Digital made the switch from being a primarily Waterfall software agency to an Agile one. If you are at all familiar with the software world, you likely know that each methodology has an almost cult-like following. Jumping ship from one to another is a little unusual—it’s like waking up in the morning as a firm right-wing conservative and deciding by the end of the day that you are actually a staunch Marxist (or vice versa). The decision was certainly not one we made lightly. We became a very successful company using the Waterfall method, and had a lot of positive experiences with it. However, over the course of CURTIS Digital’s trajectory, we wanted more opportunities to collaborate with our clients. In this regard, Waterfall was really letting us and, more importantly, our clients down.

Waterfall Patterns

Waterfall has very specific windows for collaboration. The most notable of these is at the beginning of the project lifecycle during the “Define and Discover” phase, which is when project stakeholders and managers work together to define the project’s business requirements. The development team reviews these business requirements and refactors them into software requirements, thus, the scope of the project is born. Understandably, it is extremely difficult to know exactly what a project will need upfront before it begins. Yet, this is how Waterfall works. All the requirements need to be clearly defined in the beginning, which leaves very little room for mistakes, but it creates the perfect environment in which to make them. Changes to these requirements become change requests and are billed as additions to the project’s total cost.

This process would not be so scary if Waterfall did not also subscribe to rigid release cycles. Typically, this means that the development team locks themselves away for weeks to months at a time, and then presents the finished product to the client during a beta release. Technology can change overnight—look at the differences between iOS 6 and iOS 7 for a pertinent example. Imagine that a client signed off on the scope of work for a multi-million dollar mobile app that was estimated to take six months to complete. Then, in month three, iOS 7 was announced. This is the perfect time for agency-client collaboration, as many major decisions would need to be made for the best way to move forward. For example what (if any) design changes need to be made so the app looks good in iOS 7?; Will the software update in iOS 7 deprecate any of the methods in our code?; etc. With Waterfall, changes of this caliber are immediately considered out of scope: iOS 6 was in scope, iOS 7 was not.  Additionally, the client approved the agreement not knowing iOS 7 was coming down the pipe. To make matters worse, the client would not get to see the app until it was essentially completed. By this time, several months have passed and they probably realized a lot of the flows they thought they wanted no longer make sense to their users. The only way to get the app to where they want it is to spend more money. Understandably, they would be upset.

Building products that our clients love is why we are in custom software. It is what makes our jobs enjoyable. There is nothing more heartbreaking to a software firm than delivering a product that we know the client is unhappy with because a rigid requirements document left little room for innovation. After some introspection, we at CURTIS Digital decided to try something different—we wanted to bring our clients into the development weeds with us and to let them play a bigger role in the destiny of their products. This is ultimately main driving force behind our decision to convert to the Agile methodology.

Agile is an umbrella term used to describe a general approach to software development. Though there are many agile incarnations, all agile processes, including Scrum emphasize teamwork, frequent deliveries of working software, close customer collaboration, and the ability to respond quickly to change. – Mike Cohen

Agile Story Workshops

One of the main ways we encourage collaboration is during an initial user story workshop. This meeting typically lasts from four hours to a whole day, and it involves the client meeting with our project management team and lead architect to brainstorm as many features of the system, collectively, as possible. These features are called “user stories” and typically follow a “As a ______, I want ______ so that ______” format. For example, “As a system user, I want to be able to add items to a wish list, so that I can save them for later.” These user stories are collected and prioritized into a product backlog. We review how many of these prioritized items we can complete within the client’s time and cost constraints, and Ta-da! A project scope is agreed to. At first glance, this might sound similar to the Define and Discover phase in Waterfall. The user stories are created in the beginning of the project, and the client agrees to a specific subset to be completed under the project scope. The key difference here is that the priority of these stories is not set in stone with the Agile methodology.

What does that mean, exactly? Imagine that, during a user story workshop, a client creates a story that allows users to upload Word documents into the system. This story is low enough in their backlog that the development team will not begin work on it during the first sprint, but it still falls within the project scope. A few weeks later, the client realizes that their users do not really need to be able to upload Word documents. However, they would really love to upload pictures instead. In Waterfall, this situation would warrant a change request. However, in Agile, the client has the opportunity to say, “Actually, I can see that these stories take the same amount of effort to complete. I’d like to swap them out.” To which we say, “Awesome!” and that’s that. They’re happy, which in turn, makes us happy.

Agile Sprints

Another key component of Agile is its use of sprints. A sprint is a set time period during which the development team commits to complete specific work. Our sprints are typically two weeks long, and the goal at the end of each sprint is to have completed features that could, in theory, be shippable. Once each sprint is completed, we hold a sprint demonstration meeting with our clients to show them what stories we completed. That means, at a minimum, our clients have a chance to see and interact with their products every two weeks. A sprint demonstration offers our clients the opportunity to voice their feedback, and it gives us a chance to confirm that we are building the system they want. Sometimes, actually seeing a certain feature in place is enough for a client to realize they actually need X to operate like Z. We have found that it is better to learn these details as soon as possible versus at the very end of a project. By the time our beta release rolls around, nothing is a surprise—our clients have seen the system for weeks, and their feedback has been heard and incorporated throughout.

We have found the opportunities for collaboration that Agile creates are necessary for happy clients. What experiences (both good and bad) have you had with agency collaboration? Did you find a certain methodology more helpful in encouraging communication?

Interested in working with us on your next project? Complete the form below.