Softwareproject Management

Everything about software projects - management: done right or wrong

Who is Using 100% Agile. 80%? Seriously.

WHO IS USING 100% AGILE? 80%? SERIOUSLY. No - we are not kidding. When it comes to Agile, applic
No - we are not kidding.

When it comes to Agile, application Agile is on the rise. Agile is the fancy stuff.  This is not only us saying it: year by year there are more and more companies using Agile. Just read this report: The state of Agile (9th survey).

(No, we are not their marketing people - Versionone is one of those vendors who provide you with an Agile software development software, but they do not have plenty of things we have, and surely they stick to pure Agile, so we are not afraid of you having a look at them).

When it comes to fancy things, people claim to use / own / like / seen (etc.) those things - even if the do not or they do but not to a full extent. 
E.g. when it comes to yoga - yoga is more and more fashionable nowadays. If you ask someone if they know what yoga is, s/he will tell you "of course, I practice yoga". When you ask them, what kind of, they will give you some answer - then: end of communication (no, it is not always the case, but it is the case just quite often). So more and more people know what yoga is, and after a while it will become just too uncomfortable not to know what yoga is, as everyone else is saying that it is just too good to be true.

We are wondering the real adoption and application of Agile and Waterfall - and the relating project management processes and methods (think of PRINCE2 and PMBOK) and we are wondering what these real adoption levels say.
By real adoption we mean that someone is using pure Agile (say, 80% of the tools, methods Agile is supposed to work).

And we are not alone, wondering - there is another study result here: what results in better code? Agile, Waterfall or...?

Side-note: When (and Why) is it Difficult to Go 'Pure Agile'?

Still there are situations when it is very difficult to imagine that the project is done in a 'pure Agile' way.  Why? There can be several reasons:
  • fixed budget - if there is a completely fixed budget, then harder to predict requirements can represent a risk factor some participants may be unwilling to take.  This will result in plenty of documentation and the need to clarify the requirements (a.k.a. stories) early on and discussions over what is in / out of scope.
  • client-vendor settings: if there is an external vendor in a project who is responsible for some major part (or the entire project) - again, learning what is needed later may be just simply not an option
  • what project managers and your technical people are used to: if they know better waterfall or they believe in it more, it may be very hard to get them going the 'Agile way'

What to Do If 'Pure Agile' is Not an Option? 

What to do in these cases? You have three options:

  1. Stick to waterfall. Do everything the old way.
  2. Or go ahead with pure Agile and take the risks - as there are, for sure.
  3. Or combine both: create the list of requirements (=stories) and define those requirements in a 'waterfall manner'. Then execute the project applying almost all the Agile principles.

We believe that, apart from the very clear scenarios, it may be very difficult or impossible to go 'Pure Agile'.

... and the Survey Results: Combine Agile with Waterfall

A recent study by InfoQ: 2014 CAST Research on Application Software Health (CRASH) concludes that:

"Consistently across all the structural quality characteristics—Robustness, Performance Efficiency, Security, Changeability, etc.—the mix of Agile and Waterfall methods had significantly higher scores. In fact, for Robustness and Changeability ¾ of the scores for the hybrid methods were higher than the median for Agile or Waterfall methods used alone. In addition, there was less variance in the structural quality scores on the hybrid methods. Remember, these are primarily large business critical applications, so late corrections to the architecture are very expensive and often constrained. Believing that a satisfactory architecture for such systems will emerge across numerous Agile sprints can be risky. However, not evaluating architectural decisions until system testing in Waterfall projects is also risky. Good structural quality was most often observed when the early architectural analysis characteristic of Waterfall methods was combined with continual testing of the emerging software in Agile sprints. We did not see significant differences between Agile and Waterfall methods in structural quality, it was really their combination into hybrid methods that made a difference."

Are you surprised?
After thinking over the above factors, the results should come as no surprise to you.

Why? Just re-read the highlighted text.