• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
How good is your software development team ?
 

How good is your software development team ?

on

  • 567 views

 

Statistics

Views

Total Views
567
Views on SlideShare
558
Embed Views
9

Actions

Likes
0
Downloads
6
Comments
0

2 Embeds 9

http://www.linkedin.com 5
http://www.lmodules.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    How good is your software development team ? How good is your software development team ? Document Transcript

    • 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,
    • 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.
    • 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.
    • It is the whole "development team and process" that is often good or bad, irrespective of any specific problem area.