Something that never ceases to humor me is how managers still believe that scaling people on a project will increase the productivity by an equal proportion. We all know the old saying, “You can’t make a baby in a month by getting nine women pregnant”, but the question is why do we still practice this bad habit? Is it because we do not recognize the the law of diminishing returns when it occurs?

I have talked about Brook’s Law before and that adding people to a late project makes it later, so as not to repeat myself I want to look at this from a different perspective and instead of telling how to avoid it, ask the question why this phenomenon slows efficiency and creates a Claustrophobic Team.

Claustrophobic people show anxiety and panic when they fell they are being locked in or their personal space is encroached; however, this encroachment can happen at many different levels on an overly staffed team:

Intellectual Space Encroachment

The DBA doesn’t want anyone else to touch the database without 7 written forms of consent because that is his job and space. The project manager who wants you to call every time you need to use the restroom. The client who does not want to be told a more productive process work flow.

We have all been on a team where people like to protect their intellectual sandbox. We fence these spaces primarily out of:

• Fear of not being needed or under utilized
• Ego and the need to be important
• Self esteem and the need to be appreciated

Everyone wants to stay busy and when people stack up on each other intellectual boundaries tend to be less respected and therefore encroached. As long as the work is getting completed in any one sphere attempt to respect the roles of individuals even if they do create a slight inefficiency as the inefficiency of having them work against you is greater.

Virtual Work Space Encroachment

For the software developer, you can read – code.

I have always had the belief that collective code ownership is just as a dangerous extreme as team silos. There is always some level of expertise in particular areas of the application and thus pseudo ownership, buy anyways I digress…

To many people working in the same area of the application can create a huge amount of churn. This overhead can be as simple as extra communication or complex as continuous code merging. Two people working in the same class file is a headache, three people working in the same file is just mayhem.

Especially in environments where intellectual thought is being transcribed, people need a few degrees of freedom in which to explore and modify. Unless you are pair programming, having more than one person work at a time on the same section of an application may start to become disastrous.

Physical Space Encroachment

Whether you realize it or not physical space encroachment happens a lot in claustrophobic teams. Just because you still have your desk and the office hasn’t become “standing room only”, does not mean that you aren’t feeling the pressures of encroached personal space:

• Increased communication means more people interrupting you whether through email or a face-to-face chat
• Kanban boards (and online issue trackers alike) become overloaded, hard to navigate, and harder to interrupt visibility
• Offices can become more densely populated when consultants or other workers come in to aid.

So what is the answer to all of this? Well, I am going to be very cliche and say – it depends.

Different businesses, teams, and people all have different thresholds of team claustrophobia and need to be dealt with accordingly. However, it is the responsibility of the team lead to recognize the symptoms of an overly staffed team and realign project expectations while not moving more people.

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Are You In A Claustrophobic Team?

If a man is offered a fact which goes against his instincts, he will scrutinize it closely, and unless the evidence is overwhelming, he will refuse to believe it. If, on the other hand, he is offered something which affords a reason for acting in accordance to his instincts, he will accept it even on the slightest evidence. The origin of myths is explained in this way. – Bertrand Russell

When applied to business, this quote shines so much light on why there can be a resistance to change. Attempting to make company changes with a push mentality rarely works and really requires the pull model of a crafty salesman.

Just remember that when trying to pull people into your way of thinking, you need to be selling them solutions to their problems and not yours.

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

A Man Who Goes Against His Instincts…

1. When Chuck Norris throws exceptions, it’s across the room.
2. All arrays Chuck Norris declares are of infinite size, because Chuck Norris knows no bounds.
3. Chuck Norris doesn’t have disk latency because the hard drive knows to hurry the hell up.
4. Chuck Norris writes code that optimizes itself.
5. Chuck Norris can’t test for equality because he has no equal.
6. Chuck Norris doesn’t need garbage collection because he doesn’t call .Dispose(), he calls .DropKick().
7. Chuck Norris’s first program was kill -9.
8. Chuck Norris burst the dot com bubble.
9. All browsers support the hex definitions #chuck and #norris for the colors black and blue.
10. MySpace actually isn’t your space, it’s Chuck’s (he just lets you use it).
11. Chuck Norris can write infinite recursion functions…and have them return.
12. Chuck Norris can solve the Towers of Hanoi in one move.
13. The only pattern Chuck Norris knows is God Object.
14. Chuck Norris finished World of Warcraft.
15. Project managers never ask Chuck Norris for estimations…ever.
16. Chuck Norris doesn’t use web standards as the web will conform to him.
17. “It works on my machine” always holds true for Chuck Norris.
18. Whiteboards are white because Chuck Norris scared them that way.
19. Chuck Norris doesn’t do Burn Down charts, he does Smack Down charts.
20. Chuck Norris can delete the Recycling Bin.
21. Chuck Norris’s beard can type 140 wpm.
22. Chuck Norris can unit test entire applications with a single assert.
23. Chuck Norris doesn’t bug hunt as that signifies a probability of failure, he goes bug killing.
24. Chuck Norris’s keyboard doesn’t have a Ctrl key because nothing controls Chuck Norris.
25. When Chuck Norris is web surfing websites get the message “Warning: Internet Explorer has deemed this user to be malicious or dangerous. Proceed?”.

Got any more? Comment them below…

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

The Ultimate Top 25 Chuck Norris “The Programmer” Jokes

ROFL, I think I peed my pants laughing so hard. The truth is funny…

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

The Vendor Client Relationship (In Real World Situations)

This is pretty big news for those who like virtual kanban boards tied to an issue tracker. Here is the press release that will be released:

San Francisco (Business Wire) June 1, 2009 — Today Atlassian announced the acquisition of GreenHopper for JIRA from Pyxis Technologies. With over 900 customers globally, GreenHopper for JIRA adds key agile project management capabilities to JIRA, including release planning, task management and burn down charts.

agile @ Atlassian
Atlassian is already well known by agile software development teams for providing tools that complement agile practices, including Continuous Integration (Bamboo), Code Reviews (Crucible) and Code Coverage Analysis (Clover).

According to Mike Cannon-Brookes, Atlassian CEO and co-founder, “We want to give agile developers a seamless approach to project management within JIRA. GreenHopper is hands-down one of the best tools for agile project management and we’re thrilled to bring the product on board.”

In tandem with the acquisition, Atlassian has launched a new minisite called “agile @ Atlassian” to share perspectives on agile software development and explain how Atlassian engineers use agile software techniques themselves. Visit www.atlassian.com/agile

Pyxis Technologies is a preferred Atlassian agile training partner.

Great Integrations

GreenHopper for JIRA is generally available with three Atlassian product offerings: JIRA, JIRA Enterprise Hosted and JIRA Studio.

“The impact of GreenHopper for JIRA’s customers will be substantial,” according to one customer, Cody Burleson, “GreenHopper vastly improves the ability to prioritize and visualize priorities in JIRA and this is something every JIRA user can appreciate regardless of any particular purpose of use – whether that is bug tracking, trouble ticketing, project management, Agile development or anything else.”

GreenHopper comes fully integrated into JIRA Studio, Atlassian’s agile development suite, at no additional charge. JIRA Studio integrates popular Atlassian products as a hosted integrated service, including JIRA, Confluence, FishEye, Crucible and the Open Source source control manager, Subversion. The entire suite starts at nly $25/user/month.
GreenHopper can be purchased as an add-on for JIRA Enterprise Hosted and JIRA standalone software. Pricing for GreenHopper starts at $350 for a perpetual-use license.

JIRA is used by more than 12,000 organizations for bug tracking and software project management. Customers include Adobe, Accenture, American Express, BBC, Boeing, Deutsche Bank, Lockheed Martin, Nikon, Oracle, Rackspace, Sony, US Navy, and many others.

For more information, a free evaluation, or pricing, visit http://www.atlassian.com/greenhopper

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Breaking News: Atlassian Acquires GreenHopper

A) Yes
B) Yes, but not without some changes
C) Why do you need to know?

For some reason, people are offended when people answer a question with another question; however, it is my belief that unless the question was given in great detail the answer may not be 100% correct (or correct at all for that matter).

A bad habit most developers have (myself included) is to be hasty in responses by non-developers. Rip off your headphones, respond in the most terse answer, put headphones back on, and turn back to your screen. Regardless if you are being disrupted, or you are having a bad day, here is why you want to engage most questions with another question:

Hidden Agendas Are Revealed

First and absolutely foremost, asking the question why is a defensive move. More times then not, when people ask questions in a vague, hurried, or terse manner it is to hide or cover the real question they are attempting to answer. And why are they hiding these details? Most of the time it is because they don’t want to know the real answer to the question, they want to validate the answer they most want whether it is the truth or not.

Asking them why slows them down and causes them to validate themselves. Most importantly, it removes you as the scapegoat. After all, the developers said we could…

Shows Interest In The Problem

Engaging in a meaningful conversation is perceived as high value activity to others because it shows sincere interest in helping them to solve their problems. As a result, you will be perceived as a high value employee because of your interest.

You Become A Valued Team Player

If you are perceived as a high value employee because of how you interact with the team, it only leads to believe that you will become a valued team player. Valued team players are generally liked and as a result promoted…and all because you answered questions with questions.

Answering questions with questions is only perceived poorly by those who are attempting to hide something whether it is illegal, immoral, stupid, or their own ignorance. Overcome all of these pitfalls by taking the time out to dig deeper and provide real helping hand.

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Why Are You Asking Me This Question?

There is nothing so useless as doing efficiently that which should not be done at all. – Peter Drucker

Personally, I don’t see to many instances of premature optimization any more; however, I do see premature abstraction all the time. Let the situation pull you to a solution, don’t push your solution on the situation.

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

You Never Should’ve Done It…

In my previous video – Features Do Not Exist (Only Benefits), I went on a bit of a ramble about how a cup got me all wound up. Well, the cup is back but this time with much better wording:

When choosing a foam cup over paper or plastic, we considered the environmental impact of raw materials, manufacturing, shipping and disposal. We believe we have made the most responsible decision but we’re in search of an even better alternative, If you have a viable, alternative option with a smaller environmental foot print, please email your idea to cafecup@samsclub.com. Together, we can create a more sustainable Sam’s Club.

Lesson learned – wording is everything.

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Marketing Ideas To Help Sell Your Ideas (Sam’s Club Cup Pt. 2)

As we all know, perhaps the largest communication problem between a client and the developer is the misinterpretation of requirements. Client verbalizes what he/she wants, we believe we have the same mind’s eye of the scope and implementation of those ideas, and thus go merrily on our way down the wrong path.

For example, let’s say we use the simple example of the task – “Build Me A House”. Without a shadow of a doubt, the very first question that needs to be asked is – “How many bedrooms?”.

Unfortunately, alternative (and less important) questions are prioritized ahead of the basics:

• What materials should we use?
• What is your budget?
• What is your time frame?
• What about details X,Y,Z?

Do not read me wrong, these are very important questions to ask, but they are important questions to ask after the most important question of all – assuming I don’t have all the information, roughly how big is this thing?

About now I am assuming you have 2 outstanding questions; why prioritize the rough size question above all others and what is up with this stupid bedroom analogy?

Why prioritize size and complexity before questions such as budget and time? Simple, knowing the size and complexity will trigger a defensive response when the answer to all other questions are not inline with the size. For example, assume we know the budget and time frame when presented with a size or complexity that does not match, instead of being defensive and pessimistic it is common for us to become optimistic and believe we can get it done under those constraints. This of course is a huge mistake.

As for the bedroom analogy, the underlying moral of the story is – find estimation cornerstones. In houses, you make huge assumptions on roughly how large a house is based on how many bedrooms it has. 4 bedrooms? Probably 2 bathrooms, 1400-2200 ft, and a yard….just a guess, but you see my point.

Without a doubt, you will be able to find those weird 2 bedroom mansions, 4 bedroom apartments, and standard suburbia 4 bedroom houses with swimming pools and marble kitchens; however, those are the exception and not the norm. By asking how many “bedrooms” you should be able to make a huge amount of assumptions up until you get hit with a modification that breaks the norm. These “normality breakers” however are commonly very out in the open (nobody expects a house builder to come in on time and under budget if you neglected to mention the swimming pool and sun room, therefore it gets mentioned).

There are tons of estimation cornerstones (some which I myself am experimenting with) such as:

• How many Epics / Themes can I detect early on? (for those using user stories)
• How many Roles / Persona have been mentioned?
• How many integration points are needed?

Depending on your environment, there might be a completely different set of criteria you might look at as a “bedroom”; however, I do believe that you will always be able to find at least one. The client budget and time frame is always on the forefront of the discussion; however, those are variables that [regardless of what they say] are mutable, their need for a 3 bedroom house is not.

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

How Many Bedrooms Did You Say?

I really look forward to doing this again – what a great cause!

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Codesqueeze Charity Kickin – Room To Read