Where is Agile?

I’m a pragmatic programmer, not a pragmatic agilist.

If I had to be a pragmatic agilist during my career, I’d have been fired several times, and that’s why.

The Agile rape

We hear the word Agile everywhere, thanks to the fact that this is a concept 10 years old, brought to the public by some of the greatest minds in computer engineering, who could also describe interesting things other than a cool way to have more fun and be more productive at work.

Let’s face it: the word “Agile”“ has been raped over the past 5 years. This is not because it became mainstream and everyone wanted to adopt it, it’s because once it was about to become mainstream a lot of people heard of it and wanted to integrate their own vision of agile development into their IT infrastructures.

You read it: their own vision.

Take a look at the lean software development: we have the Poppendieck saga and not much more; sure, there are a lot of books and a lot of opinions about LSD across IT professionals, nonetheless everyone takes inspiration from the infamous weds, not from what they heard about what they wrote.

Fact, this is the reason why LSD is still a pure oasis in IT1.


Sure, one of the things I’d point my finger against is SCRUM.

This lightweight agile methodolgy is probably on everyone’s mouth since 3 years, since lot of people adopted it and it seem to work: nonetheless, SCRUM is failing and will continue failing in preserving and communicating the legacy of the agile principles, values and patterns.

The problem with SCRUM is not SCRUM itself, because I think it may work in some contexts, but to the way people interpret it and implement it in their own processes:

Yes, the last one is a merely pure personal observation: still, there’s no doubt about the certification itself, which I find pretty overestimated.

[Formally] Certifying processes that don’t have formal approaches is purely counter-intuitive: sorry, agile processes are not formal2.

All in all the history of SCRUM and its adopters teaches us that a few big corporations are willing to make a step and try to embrace agile development, with the wrong approach: if you will to adopt something that – oh, boy! – has a manifesto you should, in first place, try not to betray its values, transparency at first place.

We are different

The reality is that I never heard stories from the trenches of an agile organization: ok, I read them, ok, I heard something, but I never spoke with someone who illustrated me a 100% adoption of one agile methodology, no matter if SCRUM, crystal or XP3.

I still think that embracing agile is the winning option, (almost) no matter when and where: share with me your stories, I’d be glad to give them some space here.

Still, agile’s biggest problems are both management and programmers: the management always has a skeptical eye on new methodologies that make their teams slower4 and programmers often think that they should interpret their own view of agile development.

Just a mention: I worked several months for a firm who was selling itself as “agile” or – at least – “agile-prone”, while no one ever did a retrospective in months.

I spoke with PMs, I spoke with the CTO, I spoke with the programmers: everyone had good intentions but no one was eager to be the change, not to just talk.

Back then, it was really frustrating: so no surprise I parted ways with that organization while account managers are still there, working every day until 9pm because “in this industry it works like this”.

We are different”, they said.

An agile and slower IT would just be a pain for our business

IT is a bottleneck, get over it.

Still, most organizations think that the problem between their ideas and their success is IT, since it tends to slow down and raise doubts about estimates, delivery times and implementations.

Now, put things this way: you have a great idea, you know it’s gonna work.

Sadly, having an idea and implementing it are different things: in a case, you think it and it becomes real, in the other you need to work hard and in a very qualitative way not to limit and ruin the motivation behind your work – guess if IT fits in the first or the second case.

Still, IT is a bottleneck.

Be fine with it, that’s why technicians tend to limit/screw your ideas: they try to bring you back to reality and suggest the most credibile solutions to your problems. They have to be the bottleneck between a management’s childish dreams and reality.

Still, agile is a bottleneck.

Be fine with it, that’s why agilists tend to enpower collaboration: they try to find the best mid-term solution for your problem, to help your business not facing IT bottlenecks in put-some-number-here months. They have to be the bottleneck between a management’s lack of knowledge and technology.

That’s why the management should listen to its IT department and get some genuine advices about their digital strategy and the upcoming issues that technology could reserve them ( read “it’s stupid to spend 600k on facebook ads for a mini-site if you dont have the right servers to handle the groundbreaking traffic which will come from ads themselves” ).

I once worked in a company where the CEO thought we could do whatever technologic project people would have asked for: the CTO – pretty seasoned – was battling everyday to get this guy understand that a salesman cannot sell projects he doesn’t know, at all – and yes, that salesman was the CEO5.

It’s funny how management tend to prove itself as the dumbest department ever: you hire some-area professionals, you pay them lot of money, you hear what they say, you eventually ignore them6.


Still, your problem with IT is you, not IT itself.

Now ask IT guys if they would like to work the agile way: 80% of them will just tell you “of course” (at least in europe). Now ask IT guys how many of them work in a company which truly promotes agile development, following both processes and values: 15% of them will get back to you with a positive answer.

A failure, because it means that – still – IT departments don’t have the decisional power to make their job better, easier and safer from a business perspective7.

Agile is not a reality

Today I hear too many people talking about agile8 while too few organizations succesfully implement it in their own processes: simply, agile is mainstream but not a reality.

You need the right people to truly integrate and implement an agile methodology, this is a simple fact, and “the right people” doesn’t always mean experts, but people who truly believe in agile values.

Phil Jackson won 11 NBA titles while coaching Chicago (11) and the Los Angeles Lakers (5), always using the triangle offense.

Look at his teams:

Simply, he was preaching the triangle offense and had the right men at the right time.

Red Auerbach, the Boston Celtics legend, built several ( as a coach first as well as GM later ) teams devoted to team-playing, respect and pride. Counting up to 10 NBA titles.

He had Larry “The Legend” Bird, Kevin McHale, Robert Parish, Glenn “Doc” Rivers, Bill Russel… I should stop: he simply – again – had the right people.

You say it’s a coincidence: less words, more people.

  1. Don’t be so enthusiast: in 2 years what happened to the agile software development will happen to LSD
  2. Quoting Ron Jeffries: http://www.sviluppoagile.it/sfuggente-e-di-qualita (italian article with english quotes)
  3. Ok, maybe - in Italy - Ideato is the only example I can mention, but they are too small to count as a truly succesfull story
  4. Following agile practices makes your team slower: that’s a fact. For their first months programmers need to learn a new way to manage their job and handle collaboration among team members. Not to mention that when the team is experienced, kickstarting an agile project will always be slower, since in your first steps ( = iterations ) you tend to be more pragmatic and deliver with the highest quality, while cowboy coders start like the new John Wayne and end up screwing everything they can.
  5. Now, that company is about to implode, guess why
  6. It’s funny how I was surprised - joining Rocket - when PMs and MDs were really about to follow your advices :) some of my previous experiences were really too far from this
  7. Keep in mind that leveraging the technical quality of IT products ( like agile does ) means delivering software without a vendor’s lock-in: as a result, agilists trust their job and try to deliver the best artifact they can, since they would be replaceable at any time of the process – see, everything for the customer’s advantage
  8. Myself included

In the mood for some more reading?

...or check the archives.