Issue 37

I know Scrum, Kanban and a few other Agile words

Ovidiu Şuta
QA & Bid Manager


I've been working in IT for the past 10 years now and it has definitely been both fun and a challenge to observe (and sometimes follow) the trends in terms of Methodologies in our industry. By definition, the IT industry involves a creative process, although the terms of "Factory house" and a few others exist, primarily we are talking about an industry that is not focused on a "production" factory type setting with repetitive work, but rather a creative one where finding some sort of standards in terms of how we work has been a struggle from the beginning.

If you look at how software development is done nowadays, it focuses a lot on Agile methodologies. And there are a lot of them out there.

It seems like each one of the original authors of the Agile Manifesto went on and created their own methodology afterwards. We have XP, DSDM, Crystal, Adaptive Software Development, Advanced Development Methods, Scrum and a few others, all coming from the same people that originally agreed on a few basic principles and then went on and implemented them in a different way. This in itself is quite descriptive of the problem we face. If they cannot agree on how to do things in a standard way, how could we?

So putting in place some sort of methodology on how to do software development proves quite difficult just because it is a creative process and one that is influenced by a lot of things like technology, culture of engineers, size and type of projects, and a lot others.

Another aspect in my view is the financial one, everybody wants to have the best efficiency, to have products on the market yesterday, to cut as many corners as possible; IT in general has kept up (and some would say even influenced) the world's "fast-forward" development. Everything is faster now, compared to a few years ago, and things are not slowing down, quite the opposite.

There is a lot of money to be made with these methodologies, we have trainings, certifications, workshops, consultancy services, conferences, products, tools, all focused on getting the "users" of a specific methodology up to speed and increasing the "development speed" by quite some percentages. Entire careers have now been created around methodologies and justifying one's professional existence has led to a serious number of debates in the IT world, what is right, what is wrong, which one is the best, most efficient, etc.

If you do a quick google on what "Agile is" and let the autocomplete suggest some alternatives, the 3 most popular are "Dead; bullshit; a cancer". There is equally as much money to be made from preaching against Agile as there is to be made by praising it. But Agile is just one of the steps in terms of Software Development Methodologies in the history of IT. If we look back in the history of IT, we will see things like: Structured Programming (1969), SDM (or PANDATA in 1970s), SSADM (1980s), OOP (initially in the 1960s, took off in the 1990s), RAD (1991), DSDM (1994), Scrum (1995), RUP (sustained by IBM from 1998), Extreme Programming (1999), and a lot others.

The point is we seem to put something on the market in terms of how we work, build a hype around it ("The new kid on the block"), misuse it, blame it and move to the new one, hoping for better results. But is it not the methodologies that fail, but the people using them, generously helped in doing so by the industry build around the methodology itself (remember all those trainers, consultants, events, etc.?). We, in IT, have very short memories.

But where is this behavior coming from? Why do we keep on inventing stuff, using it for a while, reaching the conclusion that "it is rubbish" and then moving on to the next cool thing? I believe this comes from 2 main parts.

1. The maturity (or lack of)

IT industry is rather new. We have a life span of 50 to 70 years (depending on who you ask) and that, in the grand scheme of things, is almost nothing. Look at other industries such as avionics, manufacturing (cars or other goods), logistics, research, medical, etc. We are a mere infant compared to the other ones. They had more time to fail, to learn, to adapt.

If you look at head count, according to the IDC research worldwide we are around 11 million professional developers (making a living of it) and about 7.5 million hobbyist developers. That is insignificant compared to the overall worldwide work force (over 2.3 billion), less than 0.5%, but with a much higher impact.

Looking at those numbers and the perspective, it sounds rather logical that IT "has not yet found its way", we are still struggling to form some standards and work decently well. But we are doing this while the world is on an accelerated pace to new development, much more than it was 50 or 80 years ago. In certain ways, it is like trying to jump into a speeding train. Not easy.

Maturity takes time, but time is something we as a society have little of, we want everything and we want it yesterday. There is no patience to grow up, and that sadly we see in all layers of our society, especially and unfortunately in our children.

This lack of maturity coupled with the increasing speed and demands is reflected in the success rate of projects worldwide. There are different statistics on this one, but let's say that IT project failure rate is somewhere between 30 to 60% on different levels (never seeing usage, severally over deadline or budget, etc.). Now, how many of you would buy a car or build a house or get on an operating table knowing there are 30 to 60% chances it would all go horribly wrong?

Sadly, as an industry we have already started to create an expectation of failure. Whenever an IT project is involved, contingencies are made in terms of money and time as it is expected to have overruns. Doing a job where more and more people are expecting you to fail is probably the low point for me personally in terms of career choice.

The silver bullet

One could argue that the silver bullet is still a representation of immaturity, but for me this has a special place.

Our constant search for that recipe that would make the perfect project, would ensure success, would make the teams happy, would make the management happy, does not exist! It never will, yet people are searching for it, and where there is a demand, there will be an offer; hence the overflow of methodologies, trainers, consultants out there. They exist because there is a need, artificially created in my opinion by some management, that believes that once this company/department/project is Agile/doing Scrum/working Kanban/"insert anything here" they will be the best and all the problems will go away.

I often run into scenarios where management/customers believe they "need to optimize" time usage for the teams, and that too much time is spent on doing planning and estimating, too much time is wasted on retrospective sessions, so decisions like moving from Scrum to Kanban (hey, this one has no planning, right? So more time coding ) are taken top down with little regard or understanding of actual reasons a team is not performing as it is supposed to.

The punchline

How you do things is of little consequence now. It is too early, we have not yet understood WHY we do things and have already moved to the how. Once you have a clear grasp on the why, the how becomes much clearer. Once you understand WHY there is a need for team alignment, WHY there is a need to have predictability, WHY there is a need to have customer feedback, WHY should there be built in a system for the team to voice its concerns and frustrations, how we do it becomes easier.

In the end, it is not the recipe that matters: focus on the principles, build a culture where people challenge the rules, let them find the best way to do something.

Someone once told me that if somebody survived more than 6 months in IT, given the high intellectual maturity of the job they are already in the 5% smartest people in the world. Now, maybe I just want to believe it because I am also working in IT . Generally we are talking about very smart people that when presented with a problem will find the best way to solve it (better than any consultant could). Just teach them the WHY and get out of their way. It might sound all flower power, but it works!




  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects