Many first time software buyers don’t know to consider software maintenance when planning their annual budgets. This shortsightedness is understandable—software is expensive to build and most dev shops don’t want to spend a lot of time on long tail cost curves.

Back in August, we wrote a blog article called “Benefits of Agile: Increased Customer Collaboration” in which we discussed why we loved the communal environment that agile fosters with our clients. That post got us thinking—what other things do we love about Agile? And thus, a blog series was born.

This second installment will be centered on another benefit of Agile that we love: increased risk management. As anyone who’s dabbled in the software industry knows, software can get very expensive very quickly. Risk is inevitable when large amounts of money are involved, but Agile can help alleviate some of the uncertainties inherent in software development.

Incremental Client Releases

One of the cornerstones of Agile is the practice of small, incremental releases. Agile projects run on sprints. Techopedia writer Cory Janssen defines a sprint as a “regular, repeatable work cycle during which work is completed and made ready for review. Generally, sprints are less than 30 days long.” The goal at the end of an Agile sprint is to have a shippable feature (for example, a bug-free purchase flow or account creation flow). This means that, at the very least, the customer will have functioning code at the end of a sprint cycle. As a client, having access to shippable code as soon as possible is imperative.

At CURTIS Digital, we hold a “Sprint Demonstration” meeting with our clients at the end of each sprint to review what work was expected to be completed, what work was actually completed, how we are tracking against our timeline and budget, and then we demo the system to them so they can see their product’s new, completed functionality. This idea might not sound revolutionary, but it means that a product owner has a chance to actually view their system early in the development cycle. In Waterfall, it’s not uncommon for a client to see their product for the first time during the Beta Release, by which point it is essentially completed. A typical Beta review period is hardly enough time to catch all the bugs in a system, let alone leave any room for the client to change their mind. God forbid the project doesn’t actually meet a client’s initial needs—at this point, there is literally (we wish it was figuratively) nothing to do except throw more money at the problem. We’ve said it before, but releasing a product that was built in accordance with outdated requirements to a client is heartbreaking. New software should bring joy, and the hardest part of working at a software agency is delivering a product that is no longer relevant. Unfortunately, it is not uncommon for clients to first realize their requirements were outdated when they see the actual product those requirements spawned. Waterfall methodology offers little room for error and even less room for adjustments.

One unfortunate, dirty-little-secret of the software world is that projects sometimes do get cancelled. This usually happens after thousands of dollars have already been poured into them. As we mentioned above, Agile methodology gives a project owner a clear window into their project, which in turn allows them time to make critical decisions—i.e. are we heading in the right direction, or do we need to shift course? Sadly, the answer to this question is that sometimes the project is no longer necessary for the client’s needs; however, Agile will at least leave them with shippable pieces of code should they decide to resume the project down the road or begin a new endeavor.

Increased Visibility in Timeline Tracking

Another issue with the Waterfall development cycle is that it offers little transparency into how a team is tracking towards their proposed timeline. This is exacerbated by a persistent myth that Waterfall teams can “make up for lost time.” Because work is not divided into sprints in Waterfall, it is often difficult to notice if a project is tracking behind schedule until it is too late to correct the problem. If a development team spends longer on an initial set of requirements than they originally planned, there is an impulse to say “No problem—we can make up for this lost time on other requirements.” Agile touts that lost time is rarely, if ever, reconciled; our personal experiences tend to corroborate this claim. As opposed to several weeks passing before a team realizes the project will be late, Agile employs certain tools that highlight risk almost immediately. Burndown charts are a type of Agile report that tracks how a team is performing daily. That’s right—daily. That means an Agile team can look at a burndown chart at the end of their working day, see how they’re tracking for the current sprint, and know at that moment if they are ahead of schedule, on schedule, or falling behind. This has proven to be a powerful tool for us, because it allows teams to self-diagnose a problem as its happening as opposed to trying to retroactively discern what went wrong. For example, are we ahead of schedule because we over-estimated these tickets? Are we behind schedule because one of our members was out sick yesterday? Having the option to ask these types of questions every day pushes the entire team towards accountability, and it gives management a chance to actually resolve potential issues before the project gets too far along.

Daily Scrum and Sprint Retrospective Meetings

Agile utilizes other tools that foster team accountability and transparency. The biggest of these are the Daily Scrum meeting and the Sprint Retrospective meeting. These meetings are internal meetings (i.e. not client-facing) and are places for agile teams to raise possible red flags to the management’s attention.

The Daily Scrum meeting occurs (you guessed it!) daily, typically in the mornings. Mike Cohen notes that these meetings are under 15 minutes, and they are a time where the team reports the following questions to each other:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

Answering these questions allows the team to see where the project stands as a whole. Asking about potential impediments is a great way for the management team to learn about possible road blockers that could appear. It is also a good way for the other development team members to offer possible solutions.

The Sprint Retrospective meeting occurs at the end of each sprint. In this meeting, the entire team discusses what went well and what went wrong during the sprint cycle, as well as what the team can do differently during the next sprint to improve. The Sprint Retrospective is a safe place for everyone to raise their concerns and discuss ways to become a more efficient team. It is not meant to be a place to blame or point fingers, and is meant to be a way to encourage comradery between all involved parties.

Conclusion

Having multiple routes to encourage transparency between the development team, the management team, and the customer helps mitigate the opportunity for risks to flourish. We love the scrum meetings that Agile utilizes and have gleaned crucial insights from our sprint burndown charts. Please do not hesitate to reach out to us if you have a question about how agile helps mitigate risk.

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

Last month at Google I/O, the Android community announced the release of their new integrated development environment: Android Studio. Android’s new IDE is based on the popular Java-oriented IDE, IntelliJ IDEA Community Edition (also free!).

We know. We’ve been a little radio silent on the blog-front, but not without good reason. We’ve been locked in the lab working on our first CURTIS Digital product, and it’s finally ready for the world to see. We are proud to present SpeakerStack to you today.

SpeakerStack is a revolutionary new platform that is aiming to create a seamless experience for conference presenters and show organizers. Both speakers and show organizers know that managing content for a presentation can be difficult. Presentations have a tendency to be media-rich, which while exciting for the audience, makes content delivery a hassle for speakers.  Large file sizes eliminate email as an option, and FTP and Dropbox can be inefficient. The simple task of sending a presentation to a show organizer has a tendency to turn into a monumental undertaking.

Managing content isn’t any easier for the show organizers, who are already responsible for planning every minute detail surrounding an event. They’re also required to review and approve presentations and confirm that their formats function with the available conference equipment (which they often don’t-technical difficulties are cited as one of the most common complaints among professional speakers). Presentations aside, organizers also have to pull together speaker bios, profile pictures, and session handouts. This might not sound like a big deal for a single speaker, but think of an event like SXSW-hundreds of different speakers held presentations of the course of the festival, and it was someone’s job to make sure that all they had all the necessary content for each and every session. There didn’t used to be a system delegated to housing and organizing this kind of information-until now.

SpeakerStack is a new kind of virtual space where speakers can upload their own content or connect to common repositories like Dropbox, Box, Google Drive, Skydrive, etc. and add their materials to their SpeakerStack profile. This puts their collateral in an online location where it’s ready to go, all the time. They can also add a bio, their headshots, and pull in additional information from social networking sites. Show organizers using the SpeakerStack portal, mobile app, or website can connect via API to obtain this information dynamically. This prevents Speakers from having to resend their information for each conference that they attend.

Here is a picture of what a speaker profile looks like. Notice that their upcoming events and session handouts can be easily found via the timeline.

Show organizers can upload a spreadsheet of speakers at their event into the system, and SpeakerStack will search to see if any of the speakers already exist inside of Speakerstack. If they do, it will pull together all of the information available on the speaker’s page. Show organizers can monitor their progress, view documents, approve presentations, and export everything they need. SpeakerStack can also be integrated with existing show management software via APIs, allowing organizers to gain access to all data in real time.

Interested in signing up? Head on over to http://speakerstack.com/, and be sure to keep an eye out for upcoming products from CURTIS Digital Labs.

Most of the systems we develop here are CURTIS Digital now have a input pattern around Twitter handle inputs, e.g., @quotientaustin or @social_quotient .

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.

An Agile Story can be defined as ” short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system – Mike Cohn”