Agile

Let's start quite simple. I will try to explain why I don't like Agile. Well for first, it may sound stupid – it killed World of Warcraft. And from now on, I will use a lot of Video Game industry analogies. I, myself, have worked in quite different industries all around the world. I have built IT systems for heavy production machinery companies, telecommunications, health care, but video game industry is, how to say, one of my favorite, as being a geek.

Okay, how does the Agile killed WoW? Well it’s still one of bestselling MMORPG’s of all time’s, there’s no doubts about that, but does it still can accumulate same amount of player base as back in 2007? Sure, it’s like, what 12, years old game! But still, if it’s perfect, millions will use it also after a 100 years. Let’s say, a car! Petroleum internal combustion engine was invented back in middle of 19^th century, but it’s still widely used standard for cars. Sure, it has uncountable innovations up it since Karl Benz wife drove that first car, but the initial workflow is same, same for almost a hundred years. So, let’s go back to the WoW. Agile, tells us to release smaller things more frequently! But does it says anything about quality? Ye, maybe, I will not go through whole thing as it’s useless anyway. Quality of those small things have dropped dramatically. Back in vanilla, you had four raids, each unique and you had to found 39 more people (what was adventure on its own), dedicated as you, to beat those end bosses. Today, you have, what, a forty raids, for whom you can use Group Finder and just bounce in to raid or dungeon quickly beating it and jumping to next one, without learning about dungeons lore, and all dungeons look same and boss techniques are same. For, god, Blizzard even doesn’t care about creating new ones, they just take old ones, tweak boss health bars and present them as new HEROIC mode, basically by using same assets, but asking us new money.

Fine, let’s get back to real life. Above, was frustration number one, in a long list of my frustrations that today Doom IT.

Agile. Main point on Wikipedia says, ‘set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.’

Let’s go through them all (we may not finish today):

• requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams

Okay, this thing, has nothing to do with Agile. It’s a normal process of everything you do in your life, been there for last four thousand years. Teams will always be self-organizing, and will cross over to other teams. What does even ‘self-organizing’ means? God damint, if you don’t know how to organize your work (any kind), you’re done, go home! People organize things they do, and human being is social animal, so he will cross paths with others always, it’s not some specific principle.

• it advocates adaptive planning

Again, basically same thing, you have to plan your work, but with catch – ‘adaptive’! It beans, if you screw up (and by using Agile you always screw up), you change your plan, and continue as nothing happened before. Of course we always have to roll with punches, but still, put this as the principle? Main principle? It already shows, that you actually don’t know how to plan your work, you just assume (ass of you and me) that you will screw up and you will have to change plan.

If you spent quite an effort in planning, and checked everything eight times, then your plan doesn’t have to fail. Sure, thing, you can create plan B (as in movies), that’s normal practice to have. But just in beginning already gave up an assumption that you will fail?? That’s wrong.

Japanese have this thing they call ‘80/20’ (I didn’t thing about annotations for the first time, but to fair and for everything to look legit, I will try to find more resources on things I will talk). Basically, it means 80% of planning, 20% of actually build. ANYTHING – software, construction, car manufacturing, doing your fitness trainings. BEFORE YOU START ANYTHING –PLAN.

You may ask, why do I think this works? I will answer you like this:

                Honda – best bikes in the world;

                Toyota – best cars in the world;

                Sony – best home entertainment electronics in the world

                Yamaha – best professional sound systems in the world

                do I have to continue…

And this all, only because Japanese are hardworking, dedicated people and they believe that planning is most important part of project, not actually building it.

Agile fails here. First, it already assumes that plan is shit, and you will have to adapt to on constant change while you’re doing build. Don’t get me wrong, change isn’t bad, change is only law of life, as one famous person told us, but, if you constantly change your plan in the middle of the build on fly, it just gets you full of stress, and in the end nothing is done, as final result is nothing that was initial planned, but are compiled from different parts, each part from the each plan, you changed. Yes, take a glue, stick it all together and let’s hope it doesn’t break apart, LOL (that’s another story, on how companies nowadays implement IT system support workflow (by assuming that system will break in the first day of the release), will take note on that).

So, now some thing from my personal experience. Oh gosh, how much I haven’t bounced back and forward, just because, project hasn’t had a real plan… Manager creates plan (let’s say in Gantt chart), gives each team member tasks, but adds, when you start building, you can easily add a tasks to your plan… WTF? Did you then created a plan or no? Or do I have to do it on my own? If so, then mr. Manager, I’m done! Yes, I finished my tasks, open your plan and check! No, no, no, I don’t have to do those task, they are not applicable, I changed the plan, and you told us we can do so!

Then, next thing happens. By Agile we split build in phases (yes, we don’t split project in phases, we split build in phases, whatever that means). Phase one, you do plan, small analysis, you do build, unit test, done. Not done? No problem, we will just roll over thins thing to next phase! End of the last phase comes, AND WHAT A SURPRISE, you have about 75% of not done tasks from previous phases. Why did it happen? Because we don’t validate end of the phase, and start next phase before we finish first one. Imagine car, you have to change brakes on it, but you put yourself on a deadline, 15 minutes per task, so you took off tire, it took you 2 minutes, so now, you smoke for 13 minutes. Then you change brakes, 15 minutes passes, but you haven’t yet done half of it, aaa screw it, let’s roll to next phase, PUTTING TIRE BACK ON.

So, now team is full of stress, as they have to build all previous phases in one phase and the deadline is close. Yup, we use ADAPTIVE PLANNING.

• evolutionary development

This is just marketing use of words, that doesn’t have any meaning besides this: Client asks, how will you build my system, manager answers, we will use “evolutionary development”, client blushes, as he has no clue what that is, but understand that “those guys” are professionals.

Okay, I can’t take this anymore, let’s continue next week.