Monday, June 6, 2011

Reflections on enterprise Agile

or...
why I hate "Agile" as it's perceived today
and what does Agile mean to me


I'm a well-known anti-Agile pundit when it comes to enterprises: sometimes I literally can't help to not ridicule people taking it seriously. I'd like to state the reasons why.

First off,

  • I'm not against seriously taken processes at all.

  • I'm not against something which I call Agile.

  • The best time of my professional life was at a team doing SCRUM (more on that later)

In the late 90s, software development was in a - usual - crisis: projects didn't get done. There were a lot of people praising about how RUP or any other process would be better, and they tried to fulfill process criterias instead of solving end-user needs.

People simply had enough of this: they wanted to improve the World.

Agile manifesto was born.

Nowadays, I hear the following excuses:

  • No, we can't ship this to you until End Of Sprint
  • No, we cannot give your manager a preview of functionality, he can see it on the Sprint Demo day (editor's note: 1 day before deadline)
  • No, we can't commit this bugfix yet as we didn't find out how to test it, even if it's obvious it works - we cannot ruin our test coverage


To the contrary:

  • We don't have meeting notes, we're agile (not to speak about action points)
  • We don't have formal inter-team interface definitions nor formalized technical (not UX, not API doc) specifications
  • Each day we have a standup (10-20 minutes), we have a meeting day each sprint, a demo, a research day demo, a planning and a retrospective meeting


Also, "we" deliver each sprint - except the term "delivery" for me has much more means than pure deployment of a new version which passes all the active tests.

I mean, seriously: what is it, if not processes over people?

It's just an example, albeit a pretty serious one; my other favourite is non-colocated standups over phone, especially when it's made sure that people have distinct set of capabilities and they don't want to touch each other's stuff anyway; or when it doesn't matter if we advance or not.

Agile, for me, was some kind of rebellion against a world with no sense, like this one.

One should recognize, that a large organization needs processes; we're only free to choose which one we implement in an organization. Some roles are built-in: you could call your managers product owners, if they still do sign your timesheets. Make sure that your way of thinking has respect of your realities.

It's strange that all project methodologies seem to become famous on what they never wanted to be:

  • Waterfall never ever said you shall sequentialize modern sized-projects as a single chunk (a few thousand lines in its age were full programs, while I commit thousands of - hand-typed - lines on some more productive days),

  • RUP never ever said you shall have 94 roles and to make sure you fully document everything (and perhaps the brilliance behind RUP will once again regain the enterprise space where it belongs)

  • Agile never ever said you should follow process packages, especially not for the sake of following process packages.


Being or not being Agile is not the problem, especially when it comes to following or not following certain practices. These are tools. Not always applicable. If your problems don't fit, if these are not your problems, or if they won't work in your environment, don't use them.

Being Agile for the sake of being Agile is the least Agile thing you could ever-ever came up with.