Unique, like everyone!

This applies to any software project development methodology but has higher chances of occuring in RAD or agile developement. Some examples where it might apply:

-Development of a new product.

-New version of an existing product.

-Added feature-sets.

For the sake of example, we’ll take the following scenario:

Your CEO thinks the company’s major software product needs a facelift and decides  to go for it! He has a meeting with the CTO and convinces him to get the visual designs from an external web-designer, so that it looks really REALLY sesky! Next thing you know, the tech team gets the front-end designs and some half cooked tech specs and are told to get to work, straightaway..

Meanwhile the CTO thinks its about time, the back-end also gets major upgrading, from the old patchy code to a new framework based object oriented code.. This is to be done while the product also gets certain new features that would make into a seperate product if developed independently..

Here’s how they ruin it:

Hire new guys, specially for the project:

Since this is gonna be a lot of work, the management decides to expand the tech team and hires a couple of devleopers. Since they only want  the cream of the crop. CEO makes sure he interviews the guys themselves so they get the absolute best.  The new guys get a couple of training tasks for the first two days and are then assigned to teams on the new developement work.

Requirements are never final:

The product management team takes their time in determining how they want the new features to behave. They beleive they’ll figure it out while the team covers the initial front end designs.

Change development style:

Before this, the whole tech team worked as a single unit. But this is a new beast and needs to be tackled in parts. So, there are as many teams as the major portions the upgraded product will have (say 4). So you have 4 teams each working on one part of the product and two of those teams contain the new guys paired with the experienced guys.

Shuffle teams, everybody has to bear someone else’s code:

At the end of first week, CTO checks back and finds very little work done. He thinks the new guys are not picking up enough, so shuffles the teams and tries to put them on relatively easier tasks.

Inconsistent progress monitoring:

CTO switches from ‘Trust the devs in everything‘ to ‘Don’t trust anyone‘ during the 2nd week, and ‘tells them to provide him daily progress reports since there has been little progress the first week; he is told, devs are having major issues with the new framework. He lets the team be for another week so they get the hang of the new framework. CEO starts to get impatient and decides to monitor progress himself. He is worried, why the 9-man  team can’t build up a nice and simple interface, that took the designer guy just four days! He thinks people are chilling out and are not focused enough, so he tries the stick and carrot philosphy: He gives all the carrots to the team-lead and tells him to shove the stick up the rest of the team’s arse! Meanwhile the President thinks he needs to take some action. He tries to find out the slow movers and decides to fire them. Apparently that’s his way of motivating the rest of the team. He lets the CTO know of his intention.

No time to settle:

CTO thinks the teams aren’t gelling well so reshuffles them, supposedly for the last time! Once again people are put onto something new having worked halfway through something else. Everyone is finding it difficult understanding the dynamics of the new module they are to work on. Meanwhile, the project management team has figured out how they want one module to behave and dispatch updated specs to the team. This results in changes to the GUI.

On-job leadership training:

CTO thinks he should give team the team-lead some effective leadership lessons so he gets the best out of others. He tells him to stop coding and start monitoring and helping people.

New requirements conflicting with older ones:

The project management come up with specs to the 2nd module and this inspires some modifications to the 1st module as well as the 2nd module’s pre-decided GUI.

The development environment isn’t suitable:

The team realizes the new framework doesn’t adequately support the processes they need to run. The CTO, who built the framework himself, starts tinkering with the framework whenever it is found wanting.. So now the framework is evolving alongwith the actual product.

Apply pressure though indirect stakeholders:

The CEO, CTO and the president think they need to get individual steps done, one by one and start telling the team what to do every hour! The team thinks, management has gone crazy and complains about the project management team’s lack of response regarding specs for the3rd and 4th module. The management makes it clear to the tech team that the project is a matter of life and death for the company and hence the team.

Increase work rates:

The teams needs to spend more time and energy till they get it done. While more time doesn’t necessarrily get more done, the management thinks it shall help the team focus on one thing only, the product. The team is required to work 16 hours a day and the weekends.

Release dates decided by management:

Management gives a specific deadline to meet, which is niether realistic nor timely. They believe the product has to launch by that time and the tech team will have to make it happen, no matter what it takes.

No Quality Assurance:

Since the management is monitoring progress themselevs, the QA team is sidelined. The bugs they report are not paid attention to, since the tech team is preoccupied building and fixing individual components pointed out by the management.  The QA team complains they have already reported what the management is reporting and it would be better if their bug lists are caterred to, since the management will point out the same things sooner or later AND that management has no clue about functional bugs that are being sidelined since everyone is focusing on the frontend. The management meanwhile, has totally forgotten they have a QA team, which is better equipped to test the product.

Loyalty and work-rate associated to performance:

The management believes one who spends more time in office is more loyal to the company and as a result of more time spent will perform better as well. This is just a gut feeling of the management who have NO other standard performance appraisal method implemented. This means that every member in the team is prone to being considered disloyal and incompetent if they can’t manage the same work rate for any reasons. The management knows that a comfortable environment is not the best way to get the best out of the team as it will allow them to slack off and that exteneded sit-ins are needed to get the job done.

-

If  after all this, you still manage to deliver the product on time, its important to know that it was all due to the management’s personal interest. Also, now that you have got the software 2.0 and are not gonna have any major development during the next 6 months, fire the new guys so the rest of the team stays on their toes.

Also on a side note, delay bonuses and raises, to make sure any disgruntled employees leave before you reward the left over team (, if there’s any)!