Posted On: Tuesday, 27 May 2008 by Rajiv Popat

The Internet is quite literally littered with articles on how Google considers it's employees really important and how beautiful life is at the GoogolPlex. There are a huge number of articles out there describing how Google is very selective on who they pick and how Google offices around the world take care of their employees:

Folks at 37Signals are also particularly articulate and bold about expressing their opinionated approaches and techniques of how they focus on recruiting smart employees rather then huge number of bodies:

There's no need to get big early — or later. Even if you have access to 100 of the very best people, it's still a bad idea to try and hire them all at once. There's no way that you can immediately assimilate that many people into a coherent culture. You'll have training headaches, personality clashes, communication lapses, people going in different directions, and more.

Companies like Google and 37Signals have made it big, in completely different ways and yet somehow managed to retain the 'magic touch of being small'. These companies have emerged as companies which have achieved success in a distinctly different way. To add to that, they, much like anyone else who is successful, are particularly un-ashamed about flaunting their success and sharing nuggets of wisdom with  anyone who cares to learn how successful companies are built and run.

No doubt, the Internet is quite full of articles based on perceptions and ideas on how successful companies are built and run.

If you’re a round-peg-in-the-square-hole, these companies and how they function will continue to sound like a perfect validation of how you think and function. Agile, Scrum and philosophies like embracing the truth of software development and getting real will make perfect sense and a huge appeal to you when you read about these concepts and how these companies have had success with these methodologies.

On the other hand our industry also has companies that run huge body shops across the globe. Companies that have always been a known to be cultivate symbolic armies of consultants, bred through a well defined process and rapid growth measured purely by the number of 'resources' hired:

These are companies that genuinely and truly believe that a process oriented approach and processes like SEI CMM or RUP are an answer to how software is built. The fundamental principal these shops work on is that If you can somehow stuff fifty resources in a tiny room and make them follow a process you can get software built.

If you’re an I-have-earned-my-degree-from-best-college-and-I-wear-a-suite-to-office kind of individual, these companies and how they function will always sound like a perfect validation of your beliefs and how you get your projects done. Big Design up-front, RUP and SEI-CMM will make perfect sense and appeal to you when you read about these processes and how these companies has had success these processes.

Like it or not, the Internet will always be littered with articles from two kinds of companies. Companies which innovate and change the way software is built and companies which out-source and build software needing huge number of bodies and very little innovation. Given that you're constantly going to be bombarded with articles and success stories from both camps, how do you pick which camp you belong to? 

This is one question the guys at 37Signals solve rather easily when answering the question if their book is for you:

You realize the old rules don't apply anymore. Distribute your software on CD-ROMs every year? How 2002. Version numbers? Out the window. You need to build, launch, and tweak. Then rinse and repeat.

Or maybe you're not yet on board with agile development and business structures, but you're eager to learn more.

If this sounds like you, then this book is for you.

One of my first projects I was involved with as a young engineer was a implemented through a deadly blend of RUP and CMM. As much as I was learning the tricks of defeating the client and getting my Project UAT done successfully with the help of CYA documentation, there was something that constantly 'felt wrong'.  When I first read about Agile and Particularly scrum I was hooked. It 'felt' right.

Ideas like putting people before process, working with smaller teams which can sustain themselves, doing away with un-necessary documentation and bureaucracy and the like, clicked. It was a reconfirmation of what I always believed in and gave me enough reason do what I always wanted to do as a young engineer, which is: have fun and build software that, for a change, works. That is exactly what I'm doing even today. Every day of my life.

Did a book or a web-cast on scrum change my life and convince me to go the Agile route? Not Really. I think I was already sold to a particular way of building software way before I picked up my first book on Agile. The books on Agile and web-casts on scrum were an excellent an enabler, reconfirming my faith in what I already believed in.

After sending countless links to young and budding developers, and traditional managers around the world, I finally realized a simple fact of life: The whole CMM Vs. Agile thing and which one you pick for your project is usually deeply rooted in your personality, character and your past experiences including how and why you entered the business of building software. You've probably picked your methodology way before you put your first step in software development world and way before you even heard about these methodologies.

The confused ones, willing to learn and move will nudge easily. However, for a traditional manager who truly believes in the power of the Gantt-Chart, trying to nudge him over to the agile side is usually a waste of time and energy on everyone's part.

Yes, confirmation from someone like Google or 37Signals or anyone else who has made it work by trusting people over process helps, but in the end which methodology folks will follow will largely depend on their way of looking at things and character. Remember, it's not about Google, 37Signals or your software development process. It's more about your personality, beliefs and above all, yourself.


Comment Section




Comments are closed.