1. How good is your software development team ?
By : Kinshuk Adhikary Email : kinshuk_in@yahoo.com
Introduction : Most development managers would say "Oh, they are excellent". Or the
other extreme, "They are just bad, why can't I find the right people".
It is easy to establish if your team is really good or bad. Sometimes in the course of a
single day. You have to just put your antennae up and listen to the right signals.
[Note : The below is more applicable to Indian development teams, total sizes 50
developers or more. The size is important. For a total size of 20 developers the
dynamics are different. For sizes 5 or less, it is probably already an excellent team, no
question. In good software development, small is often beautiful.]
Microphones in the wash-rooms : Install them. You may hear this kind of sentences :-
(a) "Ugh!, there is no work to do in this place, man. Just login, sit around, google..."
(b) "No one knows how it works. The guys who made it left long ago..."
(c) "Why so many meetings ? These guys just waste our time..."
(d) "So many emails ! Half the times I can't even find the right one..."
And many others. Let us analyze each sentence carefully.
Sentence (a) : Do not blame the developers for "lack of work". It is the task of a lead or
manager to usefully manage those inevitable slack periods. Most such techniques
revolve around "creating interesting work for developers to get excited by". Not easy if
you are not a developer yourself :-)
Sentence (b) : It is important to find out "why those old guys left". If there is the slightest
hint of "they were bored doing nothing", the problem is back to (a). It may also be a
question of bad development practices, low documentation levels.
Sentence (c) : Physical meetings once in 3 days (or more) is probably fine. Typically, a
developer needs at least 1 hour to "warm up", get into concentration after a disturbance.
Managers need to closely monitor "how many disturbances". Effective work time is often
as low as 1 hour in many companies, due to a noisy environment, too many arbitrary
meetings. lack of role clarity. The key is in a word called "zone".
Sentence (d) : A clincher, really. It just indicates no formal development "process" at all.
Emails are useless as a collaboration tool. You will be better off using chat or jabber :-)
The army barracks concept : The acid test of your development process is this :
Is it like an army cantonment ? When a soldier is transferred from one location to
another, he does not have to ask people where this is, where the canteen or mess is,

2. where the pay office is. Almost by feel he knows where 80% of the stuff will be, and what
he is supposed to do next.
Much as I hate the misused word "process", I have to use it in this paragraph. What is a
process ? Simple, it is a set of repositories, preferably version managed, and a set of
tools, and an overall "process definition", an XML say, governing the workflow.
A process definition as a "Word document" is a complete bore to all developers. But a
process that is semi or fully automated, is heaven. In a good development workplace,
machines are supposed to do all the routine work. No people should be needed.
A good process takes care of the mundane, leaving the developer's mind free of "all that
nonsense". Focus then comes squarely on to the "deliverables". The deliverables are (i)
code (ii) design artifacts (iii) maybe, just maybe, some short Word documents. Important
note : Emails are NOT a deliverable. Communication is a need, not a production item.
Numbers can be obtained from a time-and-motion study of the person who is at the
"generation point" for all of these concrete outputs. If 80% of the developer's time is not
on these deliverables, then maybe the "process" is actually impeding real work, not
helping it along by making things smoother.
Unit tests : This is another area where jargon is amply applied, but very few teams do it
correctly. Units tests "show up" a development team's real strengths as nothing else
does. It is a very complex area, and its merits are understood properly only in stormy
weather. Also, it costs effort and time, so most teams just ignore it or do lip service.
Many development managers (yes, even in this day and age) think that "unit tests are
supposed to be written by a tester". Isn't that funny ?
And quite a few delegate the writing of unit tests "to the lowest rung newbie developer on
the team". Nothing can be worse. If such is the case, you are better of discontinuing unit
tests altogether.
Issue tracker : Many development managers give this answer "yes, we have just
started using JIRA". A bit of hesitation, and the words "just started" being a clue.
Issue trackers are a "maturizer" for a development team. Use it, and every member of
the team grows to a new level. From progressively a newbie developer, to a productive
developer, a team lead, a manager and so on. Neglect it, and everyone stays more or
less on the same level, irrespective of their paper roles and "talk talk".
While easy to install, effectively guiding and building good habits around task and issue
trackers is tricky, and most teams make a mess of it. They hide it of course.
How well you integrate your issue tracker with the rest of the team tools is important too.
I am aware that both the above points have several finer aspects. "Not for our kind of
development" is a common rebut. However, for every situation there are answers. Unit
testing and issue tracking are the cornerstone of any structured development process.

3. It is all about actually doing it a few times. After that, it is a no-brainer :-)
A whole list of other indicators (you can add your own too :-) :
Do you have daily builds ? Forget continuous builds, but just daily ones ?
Does your version repository talk to your issue tracker ?
Does buying a "50$ license" for some arbitrary unknown "developer's tool" over the
internet cause tremors in the upper management levels ?
Do your developer's often write "scripts" , templating stuff or others ?
Do you do "project management" on different tools than "issue management" ?
How do your testers communicate with your developers, and what profile of people
handle that interface ?
When you "standardize" the development environment, how widespread is the
dislocation to existing development efforts ?
Knowledge and skills : In a good development team, skills and knowledge grows.
Whether by outside acquisitions or by internal generation, this always is the higher level
measurement of a dev team.
This growth is crucial to meet increasing challenges and increasing complexity.
And if knowledge and skillsets are not growing, then numbers of people etc. are all false
indicators. Nothing else really matters.
Knowledge transfer is another much misused terminology. It never happens so
simplistically. Think of it more as "knowledge osmosis" happening across a semi-
permeable membrane, and you will be on the right track.
Architecture and design strengths : The qualities of design and architecture (yes, I
am not calling them skillsets) are the pillars of a dev team.
Good dev teams interact smoothly with their design folks and architects, which means,
the communication is seamless, the artifacts easily understood.
But most important is that developers understand what the designers and architects are
trying to do, and respond in code. Likewise, architects and design folk understand what
the developers can or cannot do, and do not live in some ivory tower, or come up with
too much specification or too little.
Conclusion : The effort of this article was to convey the message "it is easy to identify a
good team versus a bad team".
Individually, developer's by themselves are rarely good or bad, they can be misfits in a
given problem/solution area and good fits for others.

4. It is the whole "development team and process" that is often good or bad, irrespective of
any specific problem area.