Internal Competition

Competition is healthy because it's human nature to want to be the winner. Competition is the incentive to work harder - or smarter, and to come out ahead of the other competitors.


That's useful in many areas of life. For example, in schools it drives the serious students to study a little harder, and in business it helps drive prices down and improve service.


When team work is needed, then competition between team members is almost always destructive.


This is true for families; a guaranteed recipe for a disastrous marriage is to have husband and wife compete with one another instead of working together as a team.


In the workplace, the same applies. It's counterproductive when employees see each other as people to compete against. I've worked at many places, and the less internal competition, the more efficient the business will be and more fun it is to work there.


People who are having fun at work are happy to come to work every day and to do a full day's work.


Teams members who are not in competition with each other are happy to help each other. They also have no issues about constructively criticizing each other's work and ideas. This dramatically improves throughput.


When team members compete with each other they may hide information from each other, which wastes huge amounts of time. In extreme cases they may sabotage one another's efforts. That's already destructive behavior and the business is sure to suffer.


Many things contribute to the internal competitive attitude.


Management is where it all starts. If managers compete with each other, that sets the tone company-wide.


If management creates a huge structure where everybody needs a title - and titles become important - then people will start competing with each other for the titles.


Management should channel the competitive urge towards the real competition: external competitors and potential competitors.


Project managers can help, too. The internal competition should be "everybody" against the "deadline". Pretend that the enemy is the deadline or the amount of open bugs, and create an atmosphere of "we will work as a team against the deadline".


Very often two brains are better then one; 2 sets of eyes are better then one, and having people work in ad-hoc teams doing pair-programming can achieve amazing results. If somebody always has to get the credit, then nobody will want to share.


For this reason it's best not to single out employees as "winners" or "employees of the month" unless they have done something extraordinary. It's best to cheer on the entire team as a unit; they'll gladly all go out together for a meal or a day in the sun - and this will reinforce the team spirit.


Another team-spirit killer is individual goals. People will do everything and anything to meet their personal goals, even at the expense of killing a bigger goal, like a team goal. Team-wide goals are fine as long as they do not create friction between teams.


Even between teams, you do not want unnecessary competition. QA and Engineering should be working together to create the bug-free product. Pitting one against the other achieves nothing. It's most productive when the testers and programmers can sit together; one showing how it can be broken and the other trying to fix it.


So what do you do if you absolutely feel that somebody deserves extra recognition? For example, somebody cleaned the kitchen-area and made it kosher-for-Passover?


The best thing to do is to tell them privately how much you appreciate going the extra mile. You could give them a gift certificate without any fan fare. In a healthy non-competitive environment, they will appreciate the privacy as well as the recognition.


Even when punishment is needed, or a post mortem is called for, it needs to be done at the team-level. More about that in a future post.

- Danny Schoemann

Scheduling in the 21st century

Surprise! In the 21st century the art of scheduling - and the joys of creating elaborate Gantt Charts  - is becoming less and less relevant.


Why is this so?


Because  - at least in the software world - projects are being delivered continuously!


As soon as there is something to ship, it can be uploaded to the web, and as improvements are made, they can be tested and shipped as updates.

However, there still are some large projects that need industrial-strength schedules.


The easiest way to schedule a large project, is to find out when the boss wants it delivered. This way at least one person will be happy with the initial schedule. :-)


How long does it take to write new software? The real answer is: "we don't know", since this piece of software has never being written. If it had been, then we wouldn't be writing it again.


Experienced programmers do have an idea how long it will take them; experienced Project Managers will know how to gauge that estimate and how much padding to add to it.


Padding:

• When in doubt, simply double the number and add a week. "Many a true word is spoken in jest" aptly applies in this case.
• As a rule of thumb, (based on years of creating schedules,) I believe that 40% of anybody's time is unavailable. Be it vacation, holidays, parties, meetings, sick leave, miluim (as reserve duty is  called in Israel) and other reasons that prevent people from working on their project.
• The estimate you got always assumes they will be working 100% of the time. Always look at a calendar with all local holidays, check the company vacation calendar and speak to the resource in question.
• Even if there's 100% certainty that none of the above will interfere, you still need to add in 20% for the predictably unpredictable.
• An estimate will never include the following, which need to be added:
• Integration - unless your project is a standalone application implemented by a single person. Every milestone will require at least 1 day of integration, unless somebody can prove otherwise.
• Always get these proofs in writing... this will usually prevent the same person from contradicting you next time.
• Testing
• The testing schedule also needs to be padded, as above.
• The testers will usually need time to learn the system, or the changes to the exciting system.
• Debugging
• Testing almost always uncovers bugs that need to be fixed.
• This will affect the engineer's schedule for the next phase of the project.
• This will require another day of testing, at a minimum.
• Documentation
• If needed, then assume it cannot be completed before the debugging stage.
• Maintenance
• Unless the engineer is new (and you allocate for the learning curve) you will have to add padding for them to maintain all the projects they have ever worked on. We have seen cases when senior engineers get no work done because they have a full-time job maintaining years' worth of legacy projects, and assisting (relative)newcomers to learn all the legacy code.

Now you can try create a schedule, which will be out-of-date before you finish preparing it.

In a future post we will discuss how often to update a schedule.

- Danny

The Quick, Small change

Axiom: There is no such a thing as a quick and small change to a program.

Unless you're a one-man team with a simple program, every change is going to cost you time, debugging and possibly bugs and frustrations.

Let's take an easy change: remove the extra period at the end of a sentence..

This is something a Project Manager may even be able to do by themselves, if they know how to use the Version Control system. (In a future post we'll discuss why you never want to allow your project to proceed without some form of Version Control.)

So, what could go wrong? Nothing... unless you have Automated Test Scripts and/or a multilingual project.

Your Automated Test Scripts may fail, since there's a missing period, based on what they were trained to check for. This should cause the QA person in charge to come banging your door down requesting an explanation as to why a change was made without a Change Request.

If you also have a multilingual project, the translation of the original may be lost. This will either cause an expense to re-translate the sentence, and/or cause the next version to be released with a missing translation.

So now we've learned our lesson, and we first open a Change Request ticket.

Opening the Change Request will take time, as you have to specify where precisely the change is. You will also be notified each time the Change Request changes owners.

The Change Request then will either be assigned to an engineer or a Task Queue. The engineer will eventually stop something she is doing and make your quick fix. Then she will go get a coffee - since she's anyways interrupted - and an hour later she'll be back into her originally scheduled work.

An hour? What was she doing for an hour?

She had to read the Change Request, find the correct file, check-out the latest revision from the Revision Control, make the change, do a Diff on the file to ensure nothing else accidentally was changed, and then Check it back into the Version Control and compile. She then had to assign the Change Request ticket to QA to be tested and the Automated Scripts updated. By now she has completely forgotten what she was working on, and will have to get back into her original project.

QA now has to read and understand the change, update the test plans, sanity check the change to their code and to the product, and assign the Change Request ticket back to you.

That's a lot of time for a tiny change.

If your Change Request also involved changes to the logic or the flow, then you can be almost guaranteed that it will affect something else. This means that besides for a tiny change, the programmer needs to check the overall logic, as well as related functions that may be affected. If the programmer did not think of all possibilities - and adjust them as needed - then QA will open bugs, and then your tiny change becomes a mini-project.

So how do you ensure that as few changes as possible are made? That's where a full Functional Spec with exhaustive Use Cases is useful; more about that in another post.

- Danny