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 19th 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.
