Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

June 20, 2016

Is Agile dead (already)?


I've been pushing Agile development for long time, as opposed to traditional methodologies like waterfall... or to no methodology.
I no longer deliver IT projects myself, but I help customers and partners to plan and deliver theirs.
The most important goal I set is achieving quick wins, like I described in become-cloud-provider-in-3-months.
A quick win encourages all the stakeholders (the project team, their clients, the lines of business that provide the budget, everybody up to the CEO).
Not only it demonstrates that the solution works, but it is a concrete measurement of the return on the investment.
Generally projects are not done because they are smart, but because they are supposed to generate a financial gain (more revenues or lower expenses). Even when the goal is described as a faster go to market, the ultimate target is generating more revenues.

Agile development make projects easier and faster


Agile development is not the only way to achieve a quick win, but it helps.
It also helps in reducing the project risk because, if you have to fail, you fail soon (and save a useless effort).
So, when a colleague sent me this article to solicit my comment, I almost felt insulted by the author... though I'm pretty sure he was not referring to me  :-)

A note on the author: 
Matthew Kern has a long experience in the field, so he knows what he's talking about.
He’s been writing many posts since 2015 to explain that Agile is dead.
Definitely he knows the Agile methodology and its usage, so he deserves respect.
More, he published a followup of that post offering the correct interpretation: probably he received too many protests.

Nevertheless my first impression was negative, because he was criticizing my fundamental believes.
But reading it carefully I understood that he's not wrong. He criticizes the evolution of the Agile methodology and the usage that someone made of it as a marketing tool, also in the light of newest trends like DevOps.

the feedback loop in devops


In my opinion, some overstatements in the article - starting with the title - are a mean to get visibility.
Indeed, in the conclusion he explains what he really means (and I partially agree): he refers to the “Agile” brand, to politics and to commercial usage (literature, consulting, marketing...).

When he says that agile don't work for large enterprises, I would distinguish between vendors of software products and customers doing it for their own project. 
The lifecycle of a software applications is completely different in these two scenarios, and so are the business requirements, the expected quality of the product, the variety of users, the frequency of the updates and bug fixes. 

When he says that many projects fail, he highlights a fact that is common to all methodologies.
But, at least, with Agile you fail soon (that is one of the objectives: better to fail in one month than after 1-2 years of unproductive activities eating your time and money).

it's better to fail before you fly too high


So, if we focus on the hype, on brands and marketing activity, Agile is being replaced by DevOps (that can be considered its evolution, taking care also of the Operations with continuous delivery and feedback) and later even DevOps will be replaced by next hype.

But they both produce a value for developers and for the IT: you can see it in the cultural shift and in the individual interpretation of the principles, rather than in  coded best practices. As an example, I’ve seen that my colleagues in Cisco Advanced Services started using Agile with visible benefits for both themselves (less bureaucracy) and customers (better and faster projects).

In conclusion, definitions are important and they help to spread the knowledge.
But theory is important for professors only, while a good practice makes developers and project managers happy.
If they adopt the principles of Agile, they work - even using Scrum informally - implementing those guidelines and produce good results, would you stop them?
It’s better to be Agile than not... 

it is better to be agile than not...

References