When I walked into my first day at work at my very first organization I literally called my manager ‘sir’. Early on in my career I saw a few ‘friendly managers’ wanting a lot of your ideas and feedback without giving you due credit for any of them when they worked. Then there were others who were primarily not even interested in feedback and ideas. There were days in my career where you felt like you were a part of army of robots working for a boss, who was supposed to be the only one capable of thinking, coming up with awesome ideas or getting anything useful done.

Over a period of time as I lived the yes-sir life I realized how messed up it was. Slowly I turned myself into an opinionated individual who wasn’t ashamed to express his opinions. Long story short – I developed a thicker skin and to an extent a stronger spine to speak my mind.

Even today as I look around I see countless individuals lacking the courage and the conviction to speak their mind at their workplace. If I were to sample the last fifteen organizations I’ve worked at, visited or been at in the past, at least thirteen of them had the problem so blatantly visible that you could hear whispers of dissatisfaction in the corridors even during your first visit to the organization.

Most of these organizations were doing something so blatantly wrong and stupid that even the junior most developer writing HTML knew it but they’d rather prefer to keep their mouth shut. No-one seems to have the conviction to bring the problems out in the open and throw them out there such that they would have to be tackled.

Scott Berkun describes the problem of how problems exist within the corridors of most modern organizations, where everyone knows about them but no-one brings them out or discusses them openly. Scott explains this issue much more articulately than me in his post on ‘how to fight management incompetence’. He explains:

Since my cranky post last week titled Do we suck at the basics? I’ve had an eye out for writing on incompetence and suckage. Over at Harvard Business John Baldoni, author of a slew of bestsellers, had a recent post called How to fight management incompetence. He offers three bits of advice: Link competency to promotion Hold people accountable Keep competencies relevant. Ok. Got it. This is good and sensible, sure. But the platitude part is easy. The real thing missing is conviction. Being accountable takes courage, something that doesn’t come with a degree or years of experience. Plenty of cowards have lurked in executive circles for decades. I believe most people just don’t have the guts to do the thing any idiot knows is right and this includes many managers. How many courageous people do you know? It can’t be more than 1 out of 10, maybe 1 out of 5. There is no special courage pill yet for VPs, so they have the same kinds of spines as the rest of us. The big incompetence crime committed by VPs is leaving incompetent managers in place for too long. My theory: by the time the CEO knows a VP stinks, the whole org has known about it for months. The smart people have been making plans to leave or are working to cover their assess. By the time the CEO gets around to taking action, it’s way too late. And often the action taken is whitewashed: no mention is made of how the VP or middle manager utterly failed (e.g. “Fred has decided it’s time for something new.”) The denial lives on, the lie propagates, making it easier for more denials and lies the next time around. All most employees want is for the people above them to be honest more of the time. Even if things stink, honesty makes it possible for people to maintain their sanity (”ok. So you at least see what I’m seeing. Thanks.”). But it also makes solutions possible, since people are trying to solve the same issues. Bob can go to his boss with suggestions and feedback only if he understand what it is his boss is really concerned about.

Walk down the corridors of any of these modern software development shops and you’ll see hush-hush discussions of things that stink and no-one willing to discuss them openly. Openness and transparency is something you cannot preach to your team. You can only set up transparency and flatness by making it a way of your own life and then expecting your team to reciprocate.  Of course pushing for transparency and success in projects is not as easy as it sounds. It requires conviction, genuine belief and above all a very strong spine at all levels within the organization.

Jeromy Carriere advices managers and programmers to develop a stronger spine by pushing them to turn themselves into ‘intrapreneurs’. He explains:

When I get frustrated with the ponderous bureaucracy characteristic of large enterprises, and long for the hopeful, entrepreneurial and innovative environment of a startup, I lean on a set of principles that try to bring the spirit of a startup, through the actions of individuals with dreams and drive, to any organization. Until recently, I didn’t know these principles have a name – Intrapreneuring. Intrapreneuring is an idea initially formulated by Gifford Pinchot in the 70s, and is based on the idea that anyone can innovate, be entrepreneurial, within a corporate environment. Mr. Pinchot described ten commandments to be followed by the intrapreneur: Come to work each day willing to be fired. Circumvent any orders aimed at stopping your dream. Do any job needed to make your project work, regardless of your job description. Find people to help you. Follow your intuition about the people you choose, and work only with the best. Work underground as long as you can – publicity triggers the corporate immune mechanism. Never bet on a race unless you are running in it. Remember it is easier to ask for forgiveness than for permission. Be true to your goals, but be realistic about the ways to achieve them. Honor your sponsors.

It doesn’t matter what your role is or what it is that you do, chances are that you’re going to make decisions even when you are in a corporate environment with a very limited and well defined role. The decisions could be as simple as picking up variable names or deciding who to promote. Before you go ahead with implementation, make sure the decision are yours and when things don’t go well, make sure that you stand by them for these decisions and take ownership; just like you support your code when it has issues. If these decisions are being imposed on you, speak your mind and express your concerns; in a civilized yet very open and completely blatant fashion.

Long winded meetings where even the junior most person in the room knows the stupidity of the suggestions being proposed and the correct solution to the problem; but no-one in the meeting brings the correct solutions out in the open, blatantly and honestly as everyone goes round and round sugar coating the issue, are fairly common in most corporate environments.

If you work for a software development firm, look around you and ask yourself a few simple questions about the people you can see or think about:

1. How many them are capable of speaking their mind, even with their bosses sitting in the room?
2. How many of them are capable of speaking their mind even at the risk of getting fired?
3. How many of them are capable of giving you their blatantly honest opinions?
4. How many of them are capable of breaking any bad news to you by looking at you in the eye?
5. How many of them have a clear succession plan prepared for the day they are fired or quit?
6. How many of them aren’t afraid to discuss this succession plan openly without any insecurities what-so-ever?

I could go on with the list, but the primary million dollar question I’m trying to ask is simple: how many of them have a strong spine?

If you can name a huge number of individuals who do, chances are you are in an organization that’ll survive the hostile attacks of bad times. If not, chances are, you’re headed for trouble and when trouble strikes, you won’t even know because everyone you’re looking at or thinking about right now, will either be busy sugar coating things or indulging themselves in a CYA exercise.

The software development word is going round and round in the infinite loop of failure; Managers and Developers with a strong spine are desperately needed in the software development world. How many do these individuals you know? How many of them work with you? How many of them are in your team?

When you hire, do you make a conscious effort to hire people with stronger spines? When you have hired them successfully do you even appreciate them and give them the due credit they deserve? Next time you’re hiring, don’t just check their technical competence, education qualifications and their IQ level before get them in. Follow your intuitions about the people you hire and try to figure out how strong their spines are before you go ahead and bring them onboard.

When one of your job role includes managing working with a team it is best for you and everyone you work with, if you to have a very short memory.

This post now has a picture and I’ve said what I wanted to say. I’m done. Post over. Thank you for reading. You can close your browser window now. 

-------

Hey wait!

That was a joke you idiot!

You weren’t closing that browser or that aggregator window, were you?

Seriously!

This post is far from over. You know the part where I sell my idea to you even if you aren’t willing to buy it at first shot? That part is still left. Read on, dear reader. Read on and help me help you get convinced that having a short memory, is an asset for you; particularly, If you are a project manager, or in any way responsible for leading a team.

To prove my point, I’m going to talk about perception, stickiness, arguments, shit and finally bring everything together to help you see things from my perspective. Humor me dear reader. I have a point to make. At-least I think I do.

Perception:

Human beings are animals working on perception. Andrew Hunt and David Thomas in their book ‘The Pragmatic Programmer: From Journeyman to Master’ describe the power of perception:

We've never tried this—honest. But they say that if you take a frog and drop it into boiling water, it will jump straight back out again. However, if you place the frog in a pan of cold water, then gradually heat it, the frog won't notice the slow increase in temperature and will stay put until cooked.

Perception is powerful. In a project running at Multiplitaxion Inc, the team made a terrible mistake. When their team lead picked an invalid underlying framework which was built to support resume driven development in the first place, no one in the team argued back.

Needless to say, the project burnt-out very soon and the team was taking way too much time to implement each feature as they struggled with each build push cycle. They were staying late, working hard, making ends meet and struggling. They had played really hard working nice guys but had lost the battle way before it had begun.

They had failed. But that was not their biggest mistake. More than a failed project, they had created for themselves, a sudden jerk of unhealthy perception. They had thrown the management in the bowl of boiling water and they had done it suddenly.

Stickiness:

As human beings we don’t tend to judge other human beings holistically. We either see their good side or their bad side. We either glorify individuals or we demonize them. Have you every been in ‘resource review meetings’ of even some of the best organizations on this planet? ‘He is good’, ‘she is bad’, ‘he is average’ – statements like these, and individuals being labeled as ‘good’, ‘average’ or ‘bad’ is a common practice in our industry.

In most organizations, the perception of failure or the label with the word ‘bad’ has even a larger problem associated with it: it’s sticky.

On a side note, remember that boy who was in kindergarten with you and was punished for naughtiness regularly back then? He was the naughtiest brat in school all the way till high school wasn’t he?

Look at your ‘resource report’ and go look at that guy who had failed in a couple of projects when he joined the organization. Chances are, he is well on his way to yet another failed project.  Doesn’t that sound awfully similar to that brat in kindergarten who remained a brat all the way till high-school?

The perception of failure is indeed sticky.

Arguments:

This one really deserves a post by itself; but the fact is, that if you have a decently smart team from varied background, cultures and pasts they are going to be highly opinionated. They are not going to be afraid starting a fight with you; argue with you; drive you nuts and even make you feel like firing them.

Shit:

Here’s a small part of things I’ve seen happening in my career spanning over years spent in a few organization. Even though these are incidents that have happened in different organizations, cultures and countries they have one common theme which we shall get to soon. Here’s a part of the list of incidents:

1. A particular individual was stealing Office supplies and RAM from the office hardware and ultimately ended up getting caught.
2. A particular individual was billing the client for his groceries and videos. 
3. A particular individual got into a heated mail argument over Java vs. .NET for no particular reason.

I could go on with the list forever but I’m sure if you were reading carefully you may have noticed the common theme amongst these incidents. These incidents were all shitty; but the individuals involved in those incidents weren’t anywhere close to being shitty. I leave you with words of wisdom from Forest Gump – 'Shit Happens'.

Connecting The Dots:

Perception is powerful. Besides being a manager you are one-hundred percent human and chances are that perception is going to have a huge impact on you. You team is going to fail all the time; failure is going to have some stickiness associated with it; People are going to argue with you and make you feel like you really need to fire them; and shit, well that’s just bound to happen all the time.

Where am I trying to go with this?

All I am trying to do is tell you dear reader, that maybe, just maybe, that naughty little guy who was a brat in kindergarten, remained a brat all the way till high school because when he moved from one class to another teachers exchanged feedback and every teacher that followed had a very sharp memory.

In simple words, dear reader, the point I am trying to make here, is that if you lead a project or work with a team, maybe, just maybe, you would be better off having a short memory and wiping the slate clean once or twice for our colleagues. Overcoming bad perceptions, letting go of stickiness associated with failures, dealing with arguments and cleaning up shit is not easy; but then, when I started this post, I never said I was going to tell you that creating an environment where successful teams can blossom is easy. All I said was that I would talk about the virtues of a short memory; and I did.

I’m an idiot with a thick skin and a very short memory; and I’m proud of that. Are you?

If you are managing working with a team consider criticism with empathy and help them when they make mistakes. Once their mistakes are history, consider forgetfulness and wipe their slate clean once in a while.

Ok, now I’m done.

Thank you for reading.

Post over. You can close that browser or that aggregator window now.

During his very early days as a manager for a brief period of time, Pops wrote fairly heated emails to people in his team when they indulged in the acts of incompetence.  Very soon, he realized that those heated emails were creating one consistent output: More Incompetence. That added incompetence of course resulted in more heated emails being sent by Pops. This thing was almost like the infinite loop of failure.

As I watched the productivity of my team go down I felt awfully sorry and completely responsible for that productivity drop. I had always loved computers and working in a team but for a brief period of time I had violated the fundamental rule of good teamwork and leadership. Instead of criticizing myself first, I had criticized others and had almost taken the first step towards hiding behind the excuse of their incompetency. As an effect, I had made the workplace a little less fun for others; and that in any developer’s or manager’s work-life, is the equivalent of a criminal offence.

One of my first organization happened to be a place where when a project failed, we had an open meeting involving all team members. This was an occasion where everyone indulged in CYA exercise, followed by a blatantly open finger pointing exercise and someone would be fired. Having seen a culture like that when I jumped over to a different organization, I had resolved to myself that I would appreciate human beings and grab every opportunity to create a healthier environment everywhere I went and whenever I could.

For a brief period of a couple of months I forgot that resolve and committed the stupid mistake of ruthless criticism. Then almost with a sudden flash of light, I remembered how it felt to be on the receiving side of this criticism. My strange experiences from those firing meetings and my past organization to an extent rescued me from falling in the pit of prickdom right in time.

Since then I’ve seen almost magical changes and examples of incompetence change to core competency more than once. I’ve seen individuals on the verge of being fired by managers turn to one of the most critical team members by a mere change of role, by simple acts of encouragement or a little bit of honest support.

For me I learnt this lesson the hard way though; it took difficult experiences in my past organization and some soul searching followed by sudden realization to finally help me understand. I was lucky to have been through this learning experience in a very short span of time.

Having said that, however, this post, doesn’t end with Pops living happily ever after. After all, dear reader, as much as you might like this blog, I do realize perfectly well that you don’t care about me or my past. This post, of course has more to it than just a little story from my lousy past.

Years later, even today, I see countless managers with years of experience behind them, conveniently indulge in act of shattering criticism, sending flame mails, hiding behind the excuse of their team’s incompetence, putting in no genuine effort of fixing the core problem and spending no or very little effort to genuinely help their team.

In fact, it almost seems like a fashion statement to announce glamorously, that putting in effort to help and mentor incompetence, even if there is a possibility of being able to fix things easily, by the use of simple motivation, guidance or change of role, is not worth a good manager’s time.

John Maeda in his post about being the good boss hits the nail right on it’s head. He explains:

When a team succeeds at achieving a lofty goal, the good boss credits her team members as being the reasons for success instead of herself. This "boss behavior" enables the team to trust their boss as one who enables their own careers over the boss' own career. When a team fails at achieving a lofty goal, the good boss owns the failure as her own and doesn't blame the team. This boss behavior enables the team members to take creative risks with their work, and not feel they will be penalized by their boss when/if they fail. Both boss behaviors require the core attributes of the boss as: 1) being self-assured but not an *sshole about it, 2) keeping the larger goals in mind with priority over the issues that are just local to herself, and 3) facing each day with acceptance of the challenging responsibilities that comes with being the boss.

It’s a well laid out post, which comes straight to the point; but just in case you weren’t reading between the lines, let’s simplify this for you:

If you lead a team and the team fails, it’s ‘your’ fault. You’re supposed to accept that, and take all the blame for the failure on yourself. Simple.

Most managers in our business find simplicity at that level scary. Almost all of them find it difficult to digest the idea that when you’re leading, CYA is not an option. This is precisely why failure postmortems and root-cause-analysis for failed projects are so common in our industry. Scott Berkun describes how most managers suck at the basics:

In management / design / business circles I know for certain of one reason. Flat out hubris. For an executive to say: “This project sucks because I have failed to organize this team effectively”requires a huge amount of humility. Much more humility than is required to say something like “Our innovation infrastructure needs to be redistributed to support the new rate of change”. Or some other bullshit that sounds complex, makes him seem smart, and entirely distracts people away from what might solve the problem: identifying the problem in the simplest terms possible.

In the world of software development most managers are taught the blame game, right when they are young and budding management students, business analysts or programmers taking their first fumbling steps at managing a team. For most managers, blaming the process, an individual’s incompetence or the whole team’s incompetence is an easy excuse for all failures; including theirs. I’ve hardly ever seen managers personally attached to team members, spending genuine effort in trying to help them find their core competencies and coming forward to blatantly own up failures and take responsibility when things don’t work out.

I’ve hardly ever seen managers lending constructive one on one direct verbal criticism followed by genuine help. I’m not talking about a generalized you-need-to-get-better-at-coding-email followed by be-careful-next-time-email followed by I-am-going-home-but-check-in-the-code-and-email-me-the-status-as-soon-as-possible kind of criticism here.

I’m talking about the blatant and precise your-use-of-object-orientation-in-the-administration-module-sucks said with empathy, followed by a joke, followed by lets-go-out-for-a-cup-of-coffee, followed by lets-stay-late-and-refractor-together kind of constructive criticism. Or for that matter, let’s-meet-during-the-weekend-and-fix-this kind of constructive criticism; and that dear reader, irrespective of what they tell you, is not a waste of your time; it’s what you were hired to do; especially If you were hired to lead a team. If you weren’t specifically hired to do that, I suggest that you do it anyways.

If you work with a team, don’t criticize ruthlessly; if you lead a team don’t play the blame game; and remember, it doesn’t matter what they teach you in management schools or tell you at your workplace, if your project isn’t cruising along successfully, it’s always your fault.

If you must criticize, do so constructively, followed by empathy, followed by genuine help. I can’t teach you how to do that. What I can do, however, dear reader, is end this post abruptly and rather dramatically, leaving you with words of wisdom worth pondering on, from one of my all time favorite movies. Here’s Wishing you, good leadership, healthy teams and a good life.

In one of my earlier posts I basically advised that team members liking each other is the secret sauce of successful teams. Hand picking team members and creating a culture that is open, transparent and where most team members like and truly respect each other is a dream come true for most managers consulting around the planet. In reality most of us have to move from one client to another or one organization to another as we consult and work with multiple teams and deliver projects or products.

If you lead work with a team, and if you’re not as lucky as I was thrice in my career, chances are that you probably inherited a part of or the whole of your team from their previous manager when you joined your organization.

When I first worked with an inherited team at Multiplitaxion Inc, I realized how different it is from hand-picking every single individual in your team based on your core values and your very own selection criteria. Internal frictions, ego issues and complexities within the team were way too high to get anything done.  It almost felt like having walked into a fifth grade class room with students fighting with each other.

While it is tempting to setup a strong hierarchy of rules, Jurgen Appelo in his post Real Agile Teams can Flocking, makes a valid point that Agile Development is more about setting constraints than it is about setting rules. He explains:

People often try to solve problems by introducing rules in an organization, in the form of "When situation X occurs again, you must do Y." I admit that I am sometimes guilty of such behavior myself, though I am convinced that it is not the best approach. It is better to leave rule selection to individual team members, and instead focus on imposing the proper constraints. Agile software development should be about setting constraints, not rules. It has been discovered that the flocking of birds can easily be modeled on a computer. This behavior, which is also apparent in many other kinds of animals, emerges through the application of a few very simple constraints: Don't leave the group; Don't bump into each other; Fly in the same direction. Specific implementations of these constraints are often used in the movie industry to create computer animated birds, bats, fish, penguins, you name it.

Jurgeon believes that modeling flocking of birds on a computer is much harder when done through a set of if-then rules than it is done by constraints and so is setting up an organization or a team. According to Jurgeon, it’s not about rules, it’s about the constraints:

It's Not About Rules, It's About Constraints The mistake people often make is that they directly try to "program" team members by giving them rules to follow. "IF you receive this type of document THEN you must perform that activity," and "IF the customer wants some new requirement THEN you must start this-or-that procedure." But the power of complex systems is that agents can manage their own rule selection process. People must restrict themselves to setting constraints, and then allow team members to solve their own problems. Agile software development is the natural approach to manage software projects. It sets constraints like "collaborate with the customer", "allow frequent changes" and "only deliver stuff that works". And then it's up to the team to select and implement rules like "IF the customer cannot travel THEN we do our demo using Skype," or "IF there's change request THEN we create a new branch in source control," and "IF someone breaks the build THEN he must wear the funny rabbit ears."

It’s rare to find teams you genuinely and truly like working with; so much so that you see them as a part of your life rather than just colleagues. In order to land up with a team like that stars have to align and you genuinely have to be really lucky. If you’re not that lucky however, or if you’ve inherited a team that has a little bit of friction, don’t lose heart. Setup the basic constraints in place first; then give the team the basic freedom, flexibility and trust to form their own rules. Chances are that things might work out.

Who knows, you might even end up finding a few colleagues you genuinely start liking to work with over time. While Jurgeon, in his post, re-words the constraints for agile teams and considers them slightly different from the constraints of a flock of birds, I personally think the that original constraints for the flock of birds work for Agile teams as well. Team dynamics are stupid simple, you don’t exactly require the IQ of a genius to get it. You can literally be as half witted as a humming bird and still get it all right. The only thing you have to know well is flocking together.

Remember; Don’t Leave the group. Don’t bump into each other. Fly in the same direction.

Everything else, including all your process and rules, is just details.

Flock on people. Flock on.

My stand on Project Plans and Microsoft Project Files in particular makes me sound like a person who does not believe in planning. More than one individual found my post on project plans; more specifically my ideas on this topic controversial and threw a few punches at me on the topic while we got into a heated debate comparing Agile with some other big design up front methodologies when it came monitoring a project status. My point however, was that the debate didn’t weigh both methodologies objectively.

While Big Design Upfront methodologies like Waterfall, focus on tracking the project status, light weight methodologies are more about tracking the project’s progress. Weighing both of them on the same scale doesn’t seem to make sense. The argument presented was somewhat on the lines of:

See when you compare quality in Agile Projects vs. Quality in CMM or RUP projects the quality of CMM and RUP projects is much higher purely because during all this time Agile hasn’t even been able to come up with one decent standard to measure project status.

The fundamental realm of Agile turns out to be slightly different. Measuring the project status in terms of percentage has never been the strong hold of agile methodologies like scrum. Having said that if you’ve never used agile before and are curious about ways to track your projects ‘health’ and progress using agile, multiple ways exist. Burn down chart happens to be just one of them. Wikipedia does a lousy job at giving details about burn down charts:

A burn down chart is graphical representation of work left to do vs. time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. It is useful for predicting when all of the work will be completed. It is often used in Agile software development methodologies such as Scrum.

With a methodology like scrum you want to monitor progress of:

1. Your current sprint.
2. Your current release.
3. Your final product.

Deciding the definition of done is fundamental to the success of any scrum project. Once you have frozen on the definition of what defines a feature as ‘done’ or ‘complete’ you would typically start by listing out your use-cases, user-stories or plain old features and sub-features.

A typical scrum project that you work on would generally consist of work items in the form of these use-cases, user-stories or plain old features and sub-features. Now if you were to plot point of features ‘remaining’ to be done on the Y-axis and the number of days on the X-axis and you were to get that done every single day of your project you would have something that would look like this:

And that my dear readers, is a simple burn down chart.

Going by the basic concept the burn down chart is a rather simple idea which has more to do with ‘wisdom’ than it has to do with knowledge of how to build it. Just like I’ve gone ahead and drawn the burn-down chart for a sprint, you could do it for a release and call it your release burndown. Learning how to draw burn-down charts is a matter of acquiring information which is rather easy to acquire but analyzing your burn-down charts is art of wisdom, not just knowledge of the data and how to transform it into a burn down chart.

If you keep monitoring your burn down chart sprint after sprint and release after release you will realize that you team, has a finite and well defined velocity. Trying to ‘push and pressure’ your team to ship faster than their natural velocity can be suicidal. Let’s monitor a team at Multiplitaxion Inc, who, with their natural velocity, have a burn down chart that looks somewhat like this:

On a side note, burndown charts in real time are hardly ever a straight line, but that’s not the point. Humor me. I have a different point to make and the actual shape of the burndown chart hardly matters.

The management at Multiplitaxion Inc, aren’t really happy with this velocity because the competition is catching up faster; so they panic, pressuring the development team to push harder. Given the team leader’s highly complying nature and optimism he agrees and the team starts to work ‘really hard’. They create a little bit of code litter and add a little bit of a code smell, break a few good practices and ship faster. The code ships and the burn-down chart, compared to the one with their natural velocity, looks much like:

Now if you are a young and budding project manager you’re thinking:

Hey Pops, The management is happy, the team is happy and the sky is blue with the sun shinning brightly. The development team took their butts off their chairs, stopped playing video games and worked harder. So what? After all no-one was killed. In fact people got praises and promotions for successful implementation.

That’s perfect. Right?

Wrong.

The sprint ends up being what I refer to as a ‘successful failure’. This example is a classic example of the first window being broken and the broken window theory kick in.

The next sprint, the team needs time to clean the code litter they created, but the competition is catching up, the team lead is acting like a prick and pushing them harder. Now even their old natural velocity isn’t enough to clean up the litter done in the previous sprint and reach the feature complete mark in the given time. They ‘work harder’, create more litter and soon the broken window theory starts to become prominent.

The next sprint takes a little more time only to result in a little more pressure from the management followed by some more litter to seed up the development in the following sprint.

Over a period of time, the code becomes complex to maintain and extend. Features start taking more time to build and the pressure from the business just keeps mounting up. Sprint after sprint more litter is introduced in the code base and the code keeps getting more and more complex. Iteration after Iteration the burndown charts start looking somewhat like:

This continues till someone realizes that features are taking too much time to build, it doesn’t even make sense continue to the project and pulls the plug.  If you’ve witnessed projects being shut down because development of features was taking too much time the above chart in action is exactly what you’ve witnessed.

Once you get a general idea of your team’s velocity and can ‘see’ it on a burndown chart, keep a close eye on the burndown sprint after sprint. If you see you burndown chart becoming unexpected steeper it doesn’t always mean your team is ‘working harder’. In fact, every time you see the burndown chart going any steeper than the team’s natural velocity you need to stop and ask yourself the following questions: 

1. Has the team moved to a radical and more efficient technology?
2. Have more efficient team members have joined your team?
3. Have the features that are being built become blatantly simpler because of change in requirements?

Net-Net you need to keep questioning till you can find a way explains the sudden steepness. If you can’t, the same team usually does not become much more efficient overnight and the steepness might be an indication of people panicking and the broken window theory being kicked off in practice.

Periodic glances on burn down chart are much better than policing your teams with a Gantt Chart. Monitor your burndown charts every now and then and every time they sway on either side, coordinate better.

When I was asked to join a team of recruiters in their recruitment drive in one of the top-notch colleges I discovered how utterly screwed up their recruitment process for hiring college interns was. Almost a hundred students showed up for the recruitment drive. By the time the selection ended that evening this team of recruiters had recruited for their company, what they referred to as the ten best-of-the-best students.

If you ask me the recruitment team had done just as good as they would have done had they written the names of the students on really small post-it notes, stuck the post-it notes on a dart board, blind-folded one of the recruiters and asked him to throw ten darts, hiring students whose name the dart hit.

Saying that they would have done just as well as hitting a dart-board with eyes blind folded isn’t such an exaggeration as it might seem. When you’re hiring from a decently good college that admits students who had studied computers for the last five years, the laws of probability kicks in and you tend to pick ‘some’ excellent candidates. If you randomly picked ten guys my guess is that you would end up with a pie that looked somewhat like this:

This interview drive was quite a long day consisting of questions on the line of:

1. If you had three balls and were not given a measuring scale to weigh them how would you find the heaviest ball of the three balls?
2. If you had a cake and an irregular piece had fallen off from the side how would you divide the cake into exactly two equal halves?
3. How would you find the number of cigarette shops in town?

The parade of funny-questions continued all day and then in the evening when I was told that we had picked ten best-of-the-best-guys out of that drive I looked blankly at the person telling me we were done and after a lot of thinking I said something on the lines of - “Ok. Let’s go home.” 

During the recruitment drive I had approached one of the recruiters and asked him to let me talk to all hundred guys in a room and see which ones of them participate in a group discussion and have opinions of their own. I was told I couldn’t because it wasn’t on the agenda and I had to mention what it is that I was going to speak on. The ‘agenda’ had consisted of one written exam after another on topics like IQ, English and a couple of other exams.

I considered the recruitment drive nothing more than a practical joke both on the organization and on the candidates. When it ended, I was glad it was over; but then the same drive brought up some really important questions about how I recruited my team members, the kind of recruitment I had just witnessed and how distinctly different both approaches were.

Most organizations around the planet seem to give way too much importance to IQ and theory while recruiting but the fact remains that Software Development is a rather practical craft. A huge part of it is done in small and tightly knit teams where not everyone happens to be the smartest of the lot but everyone contributes in the orchestration adds their very own Niche to the mix of successful implementation. Contributions range from developing or testing and goes all the way to being a catalyst.

Using IQ as the only measuring scale of how good a contributor you will turn out to be sounds like a rather impractical thing to do. After all, as sizzling as the idea sounds, IQ does not guarantee applied intelligence, results or success in the real world.

Michael Brotherton makes some rather interesting point in his rather opinionated post, where he describes ‘Why Mensa Is Stupid’:

Here's the latest piece of evidence, a 47 year-old Mensa member who is auctioning off his hand in marriage on eBay. I can't tell if he thinks he's a steal at the $100k "Buy It Now" price, or he just doesn't value his life that much. He's offensive, too, and in my opinion a lazy bastard who should get off his butt and make a better contribution. I qualify for Mensa (my PSAT score twenty years ago was plenty, and every similar test since). I don't belong to Mensa. I like doing some of the puzzles and games they do, but if that's what being part of Mensa is all about they could drop the qualifications. What's the point to having a "smart club" and keeping others out except to feel elitist? I don't have a problem with people feeling elitist, per se, although I think they're shallow and people so dang smart should go out and do something more productive with their lives! I've got a PhD, use the Hubble Space Telescope among other facilities, and write novels on the side. I usually don't have time to sit around doing puzzles with people I've chosen to be with based on their SAT scores. I like people of many sorts, and don't pick my friends based on test scores. Marilyn Vos Savant, "smartest person in the world" and Mensa poster-girl, writes an insipid column. Is that the best the "smartest person in the world" can do? I like to think our best and brightest on this world would contribute something a little more valuable than she has. I mean, she's supposed to be the "smartest," after all. I may not score as high as she does on an IQ test, but I know underachievement when I smell it. There are a lot of different intelligences, and a lot of different skills. Some great chess players are kind of stupid when they don't play chess (Bobby Fischer comes to mind). Some hunters I know have "wood smarts" that leave me in awe. And there are brilliant artists whose Verbal and Quantitative SAT scores would impress no one, but whose spatial sense would let them toast most Mensa members on many a puzzle.

Michael is rather correct when he comments on different intelligences. The idea of appreciating diverse set of good qualities and not just labeling someone as good or bad dawned unto me when I saw a struggling developer being heavily criticized by his manager as a ‘mediocre performer at everything he does’; moved to testing and become one of the best testers I happened to work with. The notion that IQ defines intelligence and someone who has a high IQ should be good at everything is just stupidly absurd.

Malcolm Gladwell in his latest book, The Outliers breaks the myth of mapping IQ to success:

In 1921, Terman decided to make the study the gifted his life work. Armed with a large grant from the Commonwealth Foundation, he put together a team of fieldworkers and sent them out into California’s elementary schools. Teachers were asked to nominate the brightest students in their class. Those children were given an intelligence test. The students who scored in the top 10 percent were given a second IQ test, and those who scored above 130 on that test were given a third IQ test, and from that set of results Terman selected the best and the brightest. By the time Terman had finished, he had sorted 250,000 elementary ad high school students and identified 1470 children whose IQs averaged over 140 and ranged as high as 200. That group of younger geniuses came to be known as the “Termites” and they were the subjects of what would become one of the most psychological studies in history.

Malcolm then goes on to describe where the Terman experiment of the gifted with high IQs went wrong: 

He (Terman) fell in love with the fact that his Termites were at the absolute pinnacle of the intellectual scale – at the ninety-ninth percentile of the ninety-ninth percentile – without realizing how little that seemingly extraordinary fact meant. By the time the Termites reached adulthood, Terman’s error was plane to see. Some of his child geniuses had grown up to publish books and scholarly articles and thrive in business. Several ran for public office, and there were two superior court justices, one municipal court judge, two members of California state legislature, and one prominent state official. But few of his geniuses were nationally known figures. They tended to earn good incomes – but were not that good. The majority had careers that could only be considered ordinary, and a surprising number ended up with careers that even Terman considered failures.

Malcolm refers to this excessive dependence on IQ or intelligence and mapping it directly to success as the ‘Terman Error’ and offers practical advice on how to judge individuals when you cannot be just relying in IQ as a measuring scale for an individual. He offers the ‘divergence test’ where candidates are asked to write down as many different uses of objects like ‘a brick’ or ‘a blanket’ as a better alternative. The divergence test requires not just the use of intelligence but imagination in as many ways and in as many directions as possible. He then analyzes results from one of the divergence test and uses it for his assessment of an individual named Poole:

It’s not hard to read Poole’s answers and get some sense of how his mind works. He’s funny. He’s a little subversive and libidinous. He has the flair for the dramatic. His mind leaps from imagery to sex to people jumping out of burning skyscrapers to very practical issues, such as how to get a duvet to stay on a bed. He gives us an impression that if we gave him another ten minutes he’d come up with another twenty uses.

Malcolm then compares the results with another individual with a much higher IQ level and questions our fundamentals of selections based on IQ and Intelligence:

Florence’s IQ is higher than Poole’s. But that means little, since both students are above the threshold. What is more interesting is that Poole’s mind can leap from violent imagery to sex to people jumping out of buildings without missing a beat, and Florence’s mind can’t. Now which one of these two students do you think is better suited to do the kind of brilliant, imaginative work that wins Nobel Prizes?

Malcolm seems to highlight the fact that a high IQ does not seem to equate to more success. If you are the kind of the guy who had a traditional outlook to intelligence and success you should get yourself a copy of Outliers. A very interesting read which challenges conventional wisdom with research and data rather ruthlessly.

So much for IQ; and while we’re at it let’s also challenge the to-recruit-the-best-hire-from-best-of-the-colleges thought process shall we?

Janet Rae-Dupree challenges the conventional wisdom that hiring the best of the students from best of the colleges always works out well in her The New York Times, Unboxed article:

“Society is obsessed with the idea of talent and genius and people who are ‘naturals’ with innate ability,” says Ms. Dweck, who is known for research that crosses the boundaries of personal, social and developmental psychology. “People who believe in the power of talent tend not to fulfill their potential because they’re so concerned with looking smart and not making mistakes. But people who believe that talent can be developed are the ones who really push, stretch, confront their own mistakes and learn from them.” In this case, nurture wins out over nature just about every time. While some managers apply these principles every day, too many others instead believe that hiring the best and the brightest from top-flight schools guarantees corporate success. The problem is that, having been identified as geniuses, the anointed become fearful of falling from grace. “It’s hard to move forward creatively and especially to foster teamwork if each person is trying to look like the biggest star in the constellation,” Ms. Dweck says.

A couple of years after the college drive I was genuinely curious about what happened of the the bunch of these elite students who had been recruited after they had been labeled ‘the best of the best’ so I thought I’d call up the managers in the organization they were working in and find out. The results were interesting:

1. Two of them had turned out to be good and productive.
2. Three were pretty average and were decently productive.
3. Three were mediocre and were struggling to keep alive.
4. One of them was fired because of gross misbehavior and use of random abusive language in office.
5. One of them wasn’t confirmed because of bad performance and decided to quit.

By the way, any guesses on how many other employees who had been picked without any IQ test had been fired by that hundred person organization that very year? Just one.

Net-Net, the recruitment results would have been similar had the recruitment team downloaded names with three years of experience from a job portal and started throwing darts at the names with a blind-fold.

So much for using IQ and Educational background as a measuring scale for success and the people you want on your team. If intelligence and IQ are your only measures of success, you might be leading your team into the classical ‘Terman Error’ and throwing random darts completely blindfolded while pretending that you are picking the ‘best-of-the-best’.

Remember, there are multiple kinds of intelligence and no single test, not even the divergence test, can measure for sure, who will work out for your team and who won’t. You have to get your best, and trust them to do it for you and then if they make mistakes, learn from those mistakes and get better the next time. As much as organizations crave for one simple answer in the art of recruitment, fact remains that there is none.

If you’ve been reading this far, dear reader, all I’ve done is attempted to sell the idea that neither college nor IQ scores can guarantee that you hiring the best. If you’re ready to buy the idea, it would mean that you now need to get your best guys and ask them define the best that joins your organization.

If you don’t buy the idea and feel that reaching out for the best of the colleges and hiring the guys with the highest IQ can solve all your problems associated with quality of recruitment, I offer you a big round dart board, lots of post-it notes, a sketch pen to write names with, a few darts and wish you good luck at hiring.

If you've been a regular reader of this blog you probably know my stance on Gantt Charts. I've often went out of my way and said that it's a team of competent programmers that builds applications and not your software development process and Gantt Charts. This post is not about reiterating any of those posts or my opinion on Gantt Charts. I am here; on the other hand; dear reader; to tell you that project plans and planning as we know it traditionally has already become utterly useless in the world of software development.

Don't knit your brows and frown on me just yet. Don't call me a just another happy-go-lucky Maverick out there dying to write code every time he sees a problem. Yes, I do understand the importance planning in software development and as important as you might consider planning to be; I am here, to tow with the idea that maybe; just maybe; planning in software development is not as important as most of us make it seem to be. I am also here to suggest, dear reader, that maybe there's something other than planning plays an important part in deciding the success or the failure of your next project.

Joel Spolsky in his article describes how he and Jeff Atwood started out with Stackoverflow.com without any plan what-so-ever:

Then one day this guy named Jeff Atwood called me up. Like me, Jeff had a blog, on which he mulled various programming topics. He wrote well, so he was attracting quite a following. He had begun to put advertisements up here and there, and was making a little bit of pocket change, so he started thinking, Gosh, I can do this for a living. It sure beat the heck out of his day job working at a California company called Vertigo Software, which is where he was when he called me, asking for advice. "Hey, I know exactly what you should do!" I said. And I told him the idea about the Q&A site with voting and editing. A site like this would need a lot of smart programmers to ask and answer questions. Between our two blogs, we felt we could generate the critical mass it would take to make the site work. Jeff liked the idea, so we decided to make it a joint venture. We named it Stack Overflow, after a common type of bug that causes software to crash -- plus, the domain name stackoverflow.com happened to be available. I had no idea if the site would work or exactly how it might make money, and I didn't have a ton of time to put into it. I have pretty deeply held ideas about how to develop software, but I mostly kept them to myself. That turned out to be a good thing, because as the organization took shape, nearly all these principles were abandoned.

Joel admits Jeff and him committing six mistakes but ends the article with a positive note and a rather happy ending described in his own words:

I advocate a fairly simple method of creating software schedules. At the very least, I think, you have to make a list of all the things you plan to do and how long you think those tasks might take, and only then can you reasonably start work. Jeff kept telling me, "It's going to take six to eight weeks." I knew there was no chance that would happen, given that Jeff pulled his timeline completely out of thin air, but I humored him. In reality, it took about twice as long as that, which wasn't that bad, but it was still a 100 percent overrun. In summary, Jeff and I made six major mistakes. Oddly, though, none of it mattered. In August, Jeff unveiled the site, and instantly it lit up. Programmers used the site to pose their technical questions, and more important, they got great answers. The voting system worked well - you could see that the answers to a given question were getting sorted with the best at the top of the rankings.

What Joel and Jeff lacked in planning they made up with something that is much more important. That something is called coordination. They had started their conversations and pod-casts on the idea of stackoverflow.com even as they were taking their first steps to building it. The community was involved with not just selection of the name but designing the logo for the system as well. With a coordination level this high you hardly need a detailed project plan.

Clay Shirky, in his talk on Institutions vs. collaboration at TED describes how modern day collaborative systems like Flickr and Wikipedia are overcoming challenges institutional setups have faced for years as these institutions continue to rely heavily on planning while the modern day collaborative systems rely on coordination. Clay explains in his TED talk on Institution vs. collaboration:

What Flickr does is it replaces planning with co-ordination and this is a general aspect of these cooperative systems. You would have experienced this in your life whenever you bought your first mobile phone and you stopped making plans. You just said, "I'll call you when I get there."; "call me when you get off work"; that is a point-to-point replacement of co-ordination with planning. We are now able to do that kind of thing with groups; to say instead of, "We must make an advance plan. We must have a five year projection of where the Wikipedia is going to be" you can just say - "let's coordinate the group effort and let's deal with it as we go because we're now well enough co-ordinate that we don't have to take on the problems of deciding in advance what to do.

I've always compared software development to fighting a war and irrespective of how well your war plans are; in the midst of confusion and panic solid communication and co-ordination should be your primary tactic and is your only chance against continuous defeats; not an elaborately detailed project plan. Both your project plan and your dead-lines will change every single day; and that to be honest, doesn't matter.

If all of us in the world of software development understood the importance of communication and coordination it would be much more easier for us to realize just how much un-due and non-deserving importance we tend to given to project plans when clearly, they are nowhere close to being that important.

For your next project, try spending lesser time creating a detailed plan, fixing deadlines which run two years in the future and then panicking. Instead, try building a concrete relationship with your client and if they ask for the delivery dates two years from where you stand, talk about the first sprint, where you are trying to get to when the first sprint ends. Once you've told them all where you will be when your first sprints end, tell them; "I'll call you when I get there".

After all, when you “get there”, chances are, that the rest of your project plan might not even be relevant at all.  Software Projects change all the time and all we need here is some good old coordination; not a whole lot of planning. As far as software development is concerned planning is just one of those things that is highly overrated.

Gantt Charts are impressive artifacts conveying a huge deal of information intended to send out a perception of control to everyone involved with the project including the people who sign the pay-checks; sometimes technically refereed to as the 'stake-holders' . As a Project Manager, you typically make a Gantt Chart to flaunt this false illusion of control by documenting it in the form of a very technical-looking artifact.

After years of building Gantt charts, a few years ago, I came to one conclusion:  Like most project artifacts of the traditional days, Gantt carts are useless, built to impress and pamper false egos of Project Managers who build them and the stake-holders who ask for them. In most cases, an elaborate project plan in a Microsoft Project file is a symbolic representation of a non-technical-and-traditional project manager screaming at the top of his voice, in a desperate attempt to make a statement that even he contributes 'something' to the project.

Jeff Atwood compares the picture of the Gantt Chart above to the Traditional Waterfall Model. After all the above picture does seem to have striking similarities to something we all recognize.

Besides the fact that Gantt Charts look and act like the planning strategies deployed in traditional waterfall and other Big Design Up Front methodologies; Gantt Charts and Microsoft Project are considered useless by Agile practitioners around the world for multiple reasons:

Reason #1: Microsoft Project Plan And Gantt Charts end up sounding like a Know-All-Document

Ever worked with a Microsoft Project File? By It's very nature Microsoft Project expects that you would know every single task involved in the project, every single sub task in the task, the start date for the sub-tasks and the end dates of the sub-tasks. If you don't type them in, Microsoft Project inserts question-marks making the document look incomplete.

Reason #2: Microsoft Project Plan And Gantt Charts encourage Micro-Management

When you have every single task and sub-task, itemized with an end date attached to it, it's easy to sit in your management-ivory-tower, find out who isn't meeting his deadlines and act like a Prick in a desperate attempt to make the project move faster by speeding things up.

Reason #3: Microsoft Project Plan And Gantt Charts Encourage Status Reporting In Percentage Complete

The Percentage Complete field sits boldly on your project plan sheet tempting you to update the value on a regular basis. Everyone likes to report that they are ninety percent done where Agile clearly pushes for a mutually agreed definition of done.

Reason #4: Microsoft Project Plan And Gantt Charts glamorize the idea of dependencies and concurrencies

While kick-ass programmers are always scratching their heads on how to reduce dependencies Gantt charts clearly seem to suggest that everything can be classified as having a dependency on something else or being an activity which can be executed in parallel. Everyone knows the perils of multitasking. Besides, agile practices like Extreme Programming have always pushed the idea of developing and testing in isolation using mock objects followed by continuous integration rather than integrating in the end.

Reason #5: Microsoft Project Plan And Gantt Charts propose and push the idea of 'resources' and gives you a tool for Policing

When you have every single task broken down at a micro level and you have twenty individuals at your disposal, it's tempting to assign a task to an individual who is idle just because he is idle. Gantt charts, to some extent, tempt managers to see their teams as isolated resources which can replace each other The idea of not considering strengths and weaknesses of individuals is one of the biggest mistake you can make as a manager. It is the kick-ass programmers who get the projects successful; not the Gantt Charts.

Besides having an 'end date' associated with every single sub-task encourages the traditional project managers police their team.

Simply put, for managers who have nothing to contribute in a project, Gantt charts make them feel good about their existence by convincing themselves,  that they  are, in some way, contributing and adding 'some' value to the project.

Even as I type this, I can literally visualize a young and budding Project Manager, who has been recently told how awesome Gantt Charts are and how they are this amazing and cool time proven way to represent their project. I can visualize this young and budding project manager reading this post and going:

Hey Pops, are you telling me that Gantt charts are inherently evil and that Microsoft Project is a crappy piece of software that no project manager on this planet should be using? Are you trying to tell me that Microsoft Project and Gantt charts are evil tools developed to satisfy the ego of project managers and they cannot be put to any good use what-so-ever?

No, not really. That's not what I'm saying here. To be fair to Microsoft Project and Gantt charts, they aren't essentially evil if you keep your project plans at a very high level and assign them to individual team leads.

Having said that, when you keep you Gantt charts at a level that is this high most Agile practitioners don't see the purpose of having the Gantt chart in the first place.

Just like the double-click-and-write-code model of Visual Basic 6.0 and even the current code behind model of ASP.NET,  Microsoft Project and Gantt charts provide you with an constant temptation of taking the wrong path and give out the I-know-all-signal to your clients instead of making them your allies and admitting up-front how little you actually know. Microsoft Project and Gantt charts in particular, gently nudge you to micro manage every single task item, introducing more problems then the ones they claim to fix.

The problem with Microsoft Project and Gantt chart, dear reader, is not that these tools are anti-agile; the real problem with Microsoft Project and Gantt charts is the approach and the thought process these tools seem to take aren't inherently the best approach and philosophies who want to run your agile projects on.

In his class post on 'The demise of the Gantt Chart in Agile Software Projects' the author David Christiansen believes that the approach and philosophy of the Gantt Chart can negatively impact Agility. David explains:

So, perhaps building software in a certain order isn’t really required, but surely it is more efficient to do it a particular way, right? I’m not one to favor the idea that there is always one best way, but it does seem intuitive that it would be more efficient for 5 different developers to be working in parallel on 5 different features if they were all building the features into a clear and complete application architecture. That way they could, for example, take advantage of existing persistence and security mechanisms instead of inventing those wheels themselves in their feature code. Recognizing that, the good PM will develop a project plan that has the architect building the architecture first and then the developers showing up to build the features next. Of course the architect will need to know the requirements of all the features in order to build the architecture correctly, so the analysts will have to show up first to get the requirements right… Before you know it, you have a project plan with the standard set of phases all lined up into one gigantic critical path - which looks really cool on a Gantt chart. Let’s go back to the roots of the scenario though. It assumes that the persistence and security mechanisms correctly support the needs of all 5 feature areas being developed. That, in turn, assumes that the requirements of those feature areas were captured accurately AND that they won’t change notably, which assumes that the users can articulate the requirements properly to begin with. Those are all assumptions that research (citations) has shown to be, well, problematic at best.

Of course, some kick-ass developers and managers around the world might be capable of resisting the temptation and getting the Gantt charts to become Agile; for the rest of us mere mortals, survey results show that the trick is to throw your Gantt Charts out of the window and move to simple collaboration, high level planning, a kick-ass team that likes working with each other and iterating faster.