Is this Project fit for Agile?

What is Agile?

The word "agile" can be used to describe frameworks, practices and a mindset arising from a set of values and principles. The values and principles were officially put down in the Agile Manifesto back in 2001. Process frameworks such as Kanban, Scrum and Lean were pulled under the umbrella of Agile because their practices mirror these ways of working. The process frameworks share the characteristics of being team-centric and iterative, as well as focused on feedback loops and adapting to change.

Why Agile?

Agile practices and frameworks have been attracting attention since well before the Manifesto, and a large number of companies continue to attempt large scale transformations to adopt more Agile practices. What's the appeal?

One of the main advantages of Agile is that changes are welcomed late, so requirements can be changed as feedback loops yield information. This is priceless when working in an area where not everything is understood up front, as is the case with many software and application projects, because decisions can be deferred until our knowledge is adequate to make them. Being able to adjust to new learnings in this way mitigates risk exponentially.

In addition, releases are faster because many small increments of value are delivered throughout. This iterative delivery forces determination of value up front, meaning the most important things get done first. Not only does this decrease the risk of complete project failure, it also focuses and reduces the scope based on value.

Agile processes tend to work well when a whole-team approach can be used, meaning that one team has all they need to move the product to completion within itself. Otherwise, it is imperative that dependencies outside of the team are manageable.

But why not Agile?

Agile frameworks aren't always the answer. Traditional or Waterfall methods of delivery can be beneficial. The biggest difference from an Agile approach is they largely "flow" in one direction and are characterized by distinct phases (Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance). They tend to be what larger companies fall back on because they fit well with their other business processes.

In the beginning of a Waterfall method, there is an agreement up front about what will be developed, so less customer involvement is needed after this first phase, and it makes both planning and measuring progress more straightforward. Also, as the project progresses, the only coordination between different roles is limited to their handoff points.

So, when might the Waterfall approach be better? These processes tend to work best if the end product is certain, and no learning or feedback loops are needed. An example of this would be when the technology is understood well and neither it, nor the team working on it, will change. They can also be helpful when controlled releases are important and the product can take longer to deliver.

The Agile mindset — a powerful tool

While we have a healthy comprehension of the frameworks and practices under the Agile umbrella, we are above all pragmatists and understand that cookie-cutter solutions do not tend to work. We have strong opinions, loosely held, built on numerous years of experience and a decidedly Agile mindset — a flexible application of a variety of practices. We won't prescribe a set of processes for you, but rather we'll collaborate with your company and its existing processes to discover how to best deliver on your unique needs. The Agile mindset is an advantage for any project, regardless of the frameworks and practices used.