In my daily life I am a senior software engineer, practicing the latest insights on Agile development. I have seen many organisations, small and big, old or brand-new (even startups). Using this insight I can spot a lot of problems with the often contradictory methods of development organisations are using to create software.

First a quick introduction to Agile development. Because it is often used as a buzzword with few meaning left in it. Non-agile is the factory line: in advance you plan and rule out all odds, the actual work is thus repetitive and not requiring a lot of skills (although you can argue it can still require some practice… but that’s exactly the problem: no thinking involved). It is input driven: someone somewhere decides what has to happen, everything and everyone falls in line to execute on that. Everyone has a predetermined place and function. You don’t need trust, you need rules.

Agile is the opposite. When you are agile you think of what you want to achieve, and make that happen with respect to the current state of the world and the tools at hand. By building on trust, by being in connection with everyone, by embracing the unknown. Yes that sounds idyllic, because that’s how humans like to be.

But why all this Agile or non-Agile? Why bother with project methodologies anyway? Just build something already!
Well, the following picture illustrates how a perfect world would look like. Look at all those connections. It would be great if we would build products in a world where all those connections between the content creators and consumers were flawless.

However as you probably know from your own experience, all connections between humans suffer from communication issues. This is the same picture, but now with the possible issues.

The idea is that a project management method helps you cope with these communication issues. The non-Agile project methods, where almost all game developments methods belong, have the following characteristics:

• You prepare to make a good-enough product that is sell-able to the masses. (This was done to account for the increasing costs of production, and the consumers accepted it because any product was better than none product at all)
• You try to mitigate the communication risks by using experts to understand the market’s needs. (This was necessary because your goal was to make something that had maximal impact on as many people as possible, but don’t listen to the individual)
• You plan in advance with what to build for what cost/benefit. (Because you had to prepare a whole factory line, where profits comes from doing it as efficient as possible)
• You add a line hierarchy with narrow boundaries to manage your workers. (Because of all these activities, the organisation is like a machine where every gear has its place. But those gears can’t do more than they are ment for, for then the whole thing would turn out to be less efficient.)
• You use mass media and and deals with large selling companies to get your products to the consumers.

But times are changing. A lot of the problems the non-Agile methods accounted for have been minimized in other ways:

• Creators and consumers can find each other much more easily. (Much less need for all kinds of parties acting as the middle-man. The internet with platforms like Bol.com / Amazon have brought both much more close together.)
• Costs of tooling is so much more lower. (You can work from home, get tooling on-demand without upfront payments.)
• Access to skills has changed radically. (Flex workers all over the world are available to you with specialized services.)
• Access to information has changed radically. (You can learn basic to advance skills using the internet (and time/practice) where previously the access was the limiting factor now our time is the only limiting factor.)

Add to this that these non-Agile methods come at a huge cost: the distance of the consumer to the creator is almost automatically enlarged, the time to respond to changes is in terms of quarters and years, and with each change large losses in productivity are unavoidable.

As a matter of fact, a lot of organisations are turning to Agile development nowadays. That is because the costs of non-Agile development out wages the benefits, and customers and workers are demanding a shift in culture.

I know from personal experience that introducing Agile methods in a previously non-Agile environments is a really painful process. The whole organisation has to change to adapt Agile, because otherwise perversely incentives will stay in place and try to re-introduce the bad from non-Agile.

This transition is worth the cost. People will be more happy as workers and as consumers. I hope to write some more blogposts on this subject and link to them from this article. I did write already one on game development over at my game dev site.

I will close this blogpost with a how-to. How to know if a decision on organisation structure of project methodology is Agile or not? I try to think of it as follows.

The past is: thinking in advance (official name: input driven). The future is: building what’s needed (official name: output driven).

Remember: All else is just a remnant of the past. People craving for power and thus aligning the organisation to fuel that craving. Departments creating work to stay relevant. So called ‘experts’ that place the consumer at a distance of the creators, significantly worsen the communication between those two.