What slowed down development on your project and how did you overcome it?

Question

Is there anything that slowed development down on a project you worked on and if so how did you improve it?

1. We recently introduced continuous integration to solve the problem of a constantly broken build.

2. To increase code quality we introduced code reviews.

3. The client was constantly changing the static data (lookups) so we introduced a change control process around it.

4. Communication with our offshore colleagues was difficult so we introduced office communicator

I would be interested in hearing about things that slowed your team down and how you got round them.

Answer 1

Reading Stackoverflow.com and trying to figure out answers to users' questions consume quite an amount of time. Oh... wait...

Answer 2

Some things slowing down the project:

• Multi-site (offshore) communication (sometimes even distributed team). I tried to set up time boxed conferences (status, requirements clarification) and with strict control of things to be discussed. Of course, with meeting minutes in the end, so no further discussions on what has been decided.

• Continuous changes from the customer. They tend to be verbal, asked directly to the development team, fragmenting the development/testing team. I use to force a single point of communication when it comes to changes - the change control board. The handling of the changes (analysis, technical solution, planning, etc.) is done and in this control board. The conclusions are documented. The small changes are planned and handled as a bulk, for the sake of efficiency.

• Updating technical documentation - this looks like a slowdown from development perspective, but it usually pays back on other activities (handling changes, discussions with the customer, onboarding, etc). So it must be done :). What shouldn't be done is to put too many details adds little value. However, the right degree of details... there's no rule to find it out :).

• I almost forgot: "Analysis - Paralysis": thinking too much (on a technical solution). Having second thoughts, etc. This will definetly slow down the development as a whole. Adopting a pragmatic attitude might help.

Answer 3

Our biggest productivity loss is when developers don't reach the point where they are "programming in the zone".

Developers can be exponentially more productive if they don't have distractions and just zone into what they are doing.

Answer 4

Number one far beyond anything else: Failure to adequately or accurately determine requirements.

Cascades into failures to estimate timescales correctly (obviously), an inability to handle change (because you weren't in possession of a full picture at the start), and increased change requirements (actually original requirements manifested as change because you didn't pick them up initially).

A lot of this can be mitigated to an extent by a mutual understanding that you are in an adaptive, formative cycle (i.e. agile), the really destructive thing is when you think you have good information.

Answer 5

Personally, I found that over zealous project managers has caused very slow development in the past. PM's who need very accurate specs written and meetings to cover the project etc causes lots of problems and sometimes you just need to tell them how little you are getting done. Also, I have found that client mind changes has lost me a lot of time in the past and I am working on a sign-off process where clients will get charged for wasted time when they change their mind.

Answer 6

If a large chunk of development happens offshore then

1. Make sure your offshore colleagues have the best hardware/software resources available. I have seen this to be a serious cause of productivity loss. The offshore contractor will provide its developers outdated versions of development tools. Their development machines will have poor configurations (RAM size etc.) causing serious productivity losses. Based on the requirements, ensure that both offshore and onsite developers have the same software and hardware available for development.

2. Moreover, network issues across continents will really slow down development. In many projects I worked for, offshore teams were connecting to databases located in US slowing down development/testing dramatically. It's a big demotivator when for ex. firing a single select query takes several seconds to complete.