Blog

One of our more recent projects took us agile. It was a great learning experience and the take-aways were generally positive. The agile methodology places a satisfied customer and continuous delivery at the forefront. By adhering to a number of the Agile Manifesto tenets the team is able to deliver value faster and the feedback loop between the developer and customer is narrowed down considerably. This focused feedback loop allows for a rapid realigning of expectations and goals from persistent contact and collaboration with the team involved.

 

Utilizing agile software development as the driving philosophy on a project would be quite different for a consultant used to entering into the more predictable stream and flow of a typical waterfall development model.

 

Within the waterfall process, the software cycle is broken down sequentially; iterating over a long timeline, generally consisting of phases including: analysis, design, code, test, and then product release. In waterfall, as each phase is completed the project then moves on to the next phase in line.

 

The agile cycle iteration is far quicker - typically ranging from 1-4 weeks, and each of the phases listed from the waterfall methodology happen in parallel. Coupling to this shorter delivery cycle - there needs to be a strict adherence between the developers and the stakeholders in terms of the scope and the commitments in each development sprint. These sprint commitments are championed and a vital indicator of team performance within the agile framework. A single daily stand up focuses the team on tasks completed the day before and duties for the day ahead. This 'scrum' is not a status meeting, but instead meant to foster further naturally ocurring discussions between developers and team members.

 

Being a successful agile team requires that a team commit to a set range of tasks and be able to predictably and repeatably understand the limits of what can be completed in the given timeframe. So then, rolling tasks from a previous iteration sprint to the next sprint is not agile, and a new baseline needs to be agreed upon within the team on what is reasonable and what the team should be accountable for. Repeatedly rolling over sprint tasks is no longer agile and now simply waterfall with status reports and a weekly deadline.

 

Agile focuses on constant communication, identifying hurdles quickly, and adjusting to the obstacles quickly. "Quickly" in this context means the failure is identified and triaged by the end of the sprint cycle, if not sooner. This differs greatly from a waterfall technique which may not surface a flaw in the design phase until far later in the process during development or testing. In these later phases teams can become mired in the unenviable realization that "we don't have time to fix the issue having spent so much time on the wrong way already" and from there a known failure, however large or small, is now propogated to the deliverable.

 

Agile, as we used it, was geared toward reaching a working product quickly, constant customer collaboration, and readily responding to changes instead of sequentially following a hard-and-fast plan. It was a fantastic growing experience and though not without its drawbacks - a very positive and applicable approach that many projects should benefit from down the road.