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!).

The Austin Business Journal wrote a feature about SpeakerStack yesterday.

Software development firm CURTIS Digital, Inc.. is releasing its first software package this week, part of a suite of tools targeting the trade show industry.

Sometimes, users need a little help with inputting full, proper URLs. While working with Dibster, a local start-up MVP client, we ran in to a small usability problem while going through user testing. A lot of the users of the system are non-technical, and we kept finding that they were not inputting URLs the way that our system wanted.

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 .

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”