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.
Isn't is possible for us to device a methodology that suits our personality, our thought pattern and mostly that fits the best delivery model.
Hope one day people will device their own development methodology which may or may not be based on proven things and come off with flying colors.
--manav
> Don't you think, that, more the number of resources, more is problem
I don’t like using the word ‘resources’; I prefer to refer to people who participate in building software as programmers, people or team members, but that’s just me.
I know calling people “people” is hard, but try it for a few days; quite a few ‘managers’ tend to look at you like you have a third eye when you do this. It’s fun! :)
Coming back to the point, I’ve always believed that the number of people in an organization has nothing to do with its largeness or smallness.
Here when I used the terms large I was referring to Monolithic, up-tight and a process-over-people driven work-culture where people are generally referred to and treated like ‘resources’. Take any ‘typical’ out-sourcing body shop out there and you’ll figure out exactly what I mean.
By small I mean a work culture that supports agility and is susceptible to change; an environment where small teams are given liberty to innovate and create products which make a difference or do important things. 37Signals is just one of the examples because they stared off extremely small.
There’s quite a few other companies out there who are genuinely innovating and maintaining their ‘magic touch of being small’ even as they grow in numbers. Google is a great example of this.
> As you mentioned in your article "magic touch of being small" did you actually try to mean this?
I did explain what I meant by large and small; here’s something from personal experience:
I’ve seen very large organizations with employee strength of less than twenty people. The distance (metaphorically) between every individual was huge and the organization was larger than anyone could have ever imagined. I witnessed its closure and shutdown right in front of my eyes.
I’ve also worked in a very small organization for over six months (for a project of mine). Their employee strength, on the other hand, was over a thousand people in a single complex but yet I refer to them as extremely small. Confusing?
Here’s what I mean by ‘Magic touch of small’ - https://www.thousandtyone.com/blog/HowBigAreYourTeams.aspx.
As the link would illustrate, at one point Amazon was a very good example of the ‘magic touch of being small’ – this other thousand person company that I talk about is another.
Companies which are worth their salt are constantly trying to get and retain ‘magic touch of small'. This includes 37Signals, Google and even Microsoft.
Manav,
> One thing that always rings me is that do we really need to adopt proven methodologies like RUP, AGILE. Isn’t it possible for us to device a methodology that suits our personality, our thought pattern and mostly that fits the best delivery model?
Not sure what you meant by ‘device a methodology’ – if you meant changing / tweaking what you don’t like, sure, people do that all the time with iterative light weight methodologies like Agile (particularly scrum). They take what they like and leave out what they don’t.
Again, you need to be careful here. Tweaking scrum and saying that, you’ll just have weekly status meetings, a big fat ‘Gantt Chart’, elaborate documentation of every single requirement and detailed design documents for every single class would be just bastardizing scrum. In fact, do that and it’s no longer scrum any more. It’s some ‘Frankenstein methodology’ which no one ends up liking.
CMM and RUP happen to be slightly rigid on tweaking and you are no longer CMM / RUP compliant if you attempt to tweak it too much. I personally believe that the whole CMM racket is about being ‘certified’ as CMM and if you lose that advantage by tweaking it, what’s the point of picking CMM in the first place? Organizations that have that level of maturity and need that level of Agility don’t opt for rigid processes and methodologies in the first place.
If you meant no-methodology-at-all and just writing kick ass code; that’s perfect; I’m all for it – (https://www.thousandtyone.com/blog/CMMRUPAndGanttChartsDontBuildSuccessfulSoftwareKickAssProgrammersDo.aspx) but then, in the world where we live there seems to be a solid dearth of programmers who can write anything which qualifies as decently good code and most of the so-called-huge body-shops hiring random ‘resources’, find it difficult to trust competency of their ‘resources’ which is why we don’t see a lot of no process and common sense based software development in the software world.
Not sure what you meant by ‘device a methodology that suits our personality, our thought pattern’ but I think you missed the whole point I was trying to make through this post.
The post wasn’t about Agile or RUP. It was about the fact that when you pick any methodology (or decide to go the no-methodology-at-all route, now that we have that as a third option) what you’re really doing is picking a ‘way of thinking’ and ‘way of working’. You’re basically opting between people-before-process or process-before-people approach to software development. And that’s the critical choice. Everything else is just details.
If you’re a process-before-people kind of a person chances are that you’ll end up bastardizing scrum even if you were forced to pick it up. If you’re a people-before-process kind of a guy you probably wouldn’t opt for a big-design-up-front or process-before-people methodology in the first place or you would just add your ‘magic touch of small’ to it if you were forced to pick it up.
Which one of these approach to software development individuals (or organizations) end up picking is largely dependent on their character, ‘way of thinking’ and ‘way of working’ more than what they read or how much you try to convince them in either direction; That’s the essence of the whole point I was trying to make in the post.
Comments are closed.