views:

1079

answers:

17

I suggested the testing and functional teams to use Freemind map for jotting the functional flows and test steps. There was some paranoia but our module took it up and the QA teams were surprised to see near zero review comments. There was misconception among the team that there are doing more work. I assured them that by the time others would complete their work along with comment fixes, we would be going out for team lunchs and we did. The real returns came when the developers started refering to the created document in their discussions.

So share your contribution(s).

+18  A: 

Use source control.

artknish
Agree. While many developers take source control for granted, many cannot imagine what a productivity boost it really is when you start using it. Took a while for our embedded developers to get really used to it though.
OregonGhost
I can't imagine a serious team not using source control already, so this wouldn't even have occurred to me.
Tanktalus
Actually it was a small company and we were just getting started. I also suggested and implemented automating the build. It was good old days though not very long ago.
artknish
@Tanktalus > I can't imagine the number of teams that I failed to convince. Now I have power to impose it <cue manic laughter>
Martin Beckett
4 words that give you 15 votes up! congrats Vito!
SDReyes
+10  A: 
andy
+1  A: 

During crunch time a daily status meeting limited to a half hour worked well. The limited time frame forced people to focus and communicate effectively. When a topic arose that required more time, we tabled it to get through the remaining times and let the team members who were not involved in the larger issue go work on their items.

David Robbins
+9  A: 

The third time rule:

When customer asks for some feature for first time, it gets just ignored.
When customer asks for same feature second time, it is put into long-term To-Do List.
When customer asks third time, - it's implemented.

This simple rule filters out about 90% of unneeded or just occasional requirements and lets the team to concentrate on topic.

Only if customer asks for the feature more than two-three times, this feature is really worth to be implemented.

Note: Customers must be aware of this rule being applied to the project.

Thevs
This sounds like it could either result in a perfectly balanced product without feature-creep, OR a really frustrated customer!
Max
It also filters out too worried customers :)
Thevs
BTW, the customer will be even more frustrated when he get feature-bloated, or icnonsistent product.
Thevs
It does also assume you ever reach the point of having 3 customers!
Martin Beckett
@mgb, not necessarily as one customer may make the same request over and over again.
JB King
+9  A: 

Unit testing. Without a doubt, and in particular the use of TDD. After the initial paranoia (and it is to be expected - see the Satir Change Model), the team caught on. Productivity soared. Morale soared. And unsurprisingly, so did the product quality (and I assume user satisfaction, but Product Management didn't tell us that...)

Yuval
+8  A: 

Automation.

While the process of building the product was already automated (via make), the process of creating product images (CDs or DVDs) was not. Nor the testing, nor the test management (producing reports to keep manager-types happy), nor the unit tests.

I'm still working on it, but over the years, I've managed to "steal" resource to automate things (by "stealing" I mean "I told my manager I was deferring work s/he has assigned to me and doing this first" as opposed to "I asked my manager to let me work on automation").

I've met with varying degrees of success. I had the test management completely automated at one point (well, as automated as it could be without the tests themselves being fully automated), but then I moved on to the next item, and testing got reassigned to another team who then proceeded to completely munge it up.

I do find it a constant battle, however. Some co-workers think that a one-off manual process is fine. I take every opportunity, however, to beat them over the head with the utter lack of foresight, when (not if) someone asks us to do it again. Even when they originally told us it would never be requested again.

Tanktalus
+5  A: 

Akin to Srikanth, one of the first major changes I implemented was a move from Visual SourceSafe to Subversion. While the team to my knowledge had never suffered from database damage (knock on wood), I felt that the lock-modify-unlock cycles were severely hampering productivity, and making some changes basically impossible to commit in time ("sorry, I have this file checked out exclusively on my desktop at home"). Plus, many useful tools are available for Subversion that aren't for VSS. Everyone is certainly quite happy about the change.

Sören Kuklau
+6  A: 

I banned the use of System.Threading (except in cases where the entire team could be convinced it was necessary). This significantly cut debugging time, and produced more stable applications.

MusiGenesis
What were you using it for that it was so pervasive as to require banning?
Yuval
I wasn't the one who was using it, and there was no legitimate reason at all for it to be used. New programmers frequently use threads because they've been told that multi-threaded apps are "better".
MusiGenesis
A common anti-pattern that I ran into was that these guys would call a function by kicking it off on another thread, and then poll in a do loop until that method completed. Yes, I know this makes no sense.
MusiGenesis
+2  A: 

Have fewer meetings - cut down to one or two meetings per week.

Vivek
Please, how long did that last one week? My buddy used to (probably still does) have 12 meetings a week to talk about the same project.
Martin
@Martin: eek, did you get some work done?
PoweRoy
+4  A: 

My team had just done a 100+ hour task of my own design that we (and our customer's bosses) thought would be really useful. We all looked forward to it, and we told our users how great it was going to be. When it was deployed, surprise surprise: Our users didn't get it, weren't interested, misused it, etc. We had to tweak it until it was pretty good, but it would have taken a rewrite to really do a good job. Now the users are stuck with it and, while they use it effectively, I wouldn't call them happy. Nor is the customer happy – having to tweak cost them more than they initially bargained for.

I learned this: Carefully define the problem you intend to solve before you define requirements or start coding. That way you solve the right problem. To do this, get the users involved with problem definition. Get face-time in person if you can and just hear them out, and work to define the precise problem they're having. Usually they will tell you their symptoms. Your role is to figure out the root cause and the simplest solution. This will make the users happiest and will probably save your customer some money.

Kevin Conner
"If I'm going to chop wood for 8 hours, I going to sharpen my axe for 6"-- Abe Lincoln
David Robbins
thanks for the quote! that is dynamite
Kevin Conner
the quote is: If I had eight hours to chop down a tree, I'd spend six sharpening my axe. -- Abe Lincoln.
Christopher Mahan
+2  A: 

Use Comments

Techmaddy
+2  A: 

Having lunch together has seemed to be a good thing that I'm not sure who suggested it, but it has provided a few good things. There is the comraderie and friendship factor so that each of us works hard so that the team looks good, pitches in for each other and we have each other's backs, and it provides times for some humour to come in that can help break up what can be a rather dry kind of work when it comes to funny stuff in the office. I know there are places like "The Daily WTF", "XKCD", and "SharkTank" but that kind of thing doesn't happen where I work. No, no sirreee ;)

JB King
+6  A: 

Have a bug/feature request database and don't start on anything until it's entered in the database.

You'd be amazed how many "high-priority" features aren't important enough to create a change request for.

Dour High Arch
+1  A: 

Use Resharper ...

Martin
+2  A: 

Set deadlines.

This is was obviously for a much more informal team. But we were finding the work we had to do invariably expanded in the time we had to do it - ie without a due date it took forever.

Just a couple of milestones with due dates sped things up greatly.

Luke Lowrey
+1  A: 

Do not debug for IE6.

Petr Peller
I wish. There is still a larger portion of users still using ie6. However, when I design websites, I do the bare minimum with ie6 unless they pay me more to do it.
revil
+2  A: 

Introduced a Wiki. Used it for knowledge sharing, technical documentation snippets, faq, managing checklists and status tracking. Once people start seeing the benefits, it really took off.

Gurpreet