Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What are some of the things that a team should do to get better as a Software Development group? The group is involved in doing intranet development/general support for various internal groups within the company?

share|improve this question

closed as too broad by gnat, Dan Pichelman, GlenH7, thorsten müller, mattnz Sep 20 '13 at 8:21

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

What areas are you looking at targeting? Code quality, estimation, teamwork, etc.? Definition of "better" is probably the first step. –  Ethel Evans Apr 21 '11 at 20:35
Certainly at a higher level than the code. Estimation, teamwork - certainly Yes! Probably better so that we can do what we are doing more effectively. –  Piyush Mattoo Apr 21 '11 at 20:38
Is your team supporting only the application you are writing or is the support role more of general support? –  Dave Wise Apr 21 '11 at 20:43
The support includes supporting both the applications we write and general support as well. –  Piyush Mattoo Apr 21 '11 at 20:45
One more question from me, also - what software development paradigm do you use currently? A form of agile, or what? –  Ethel Evans Apr 21 '11 at 20:45

5 Answers 5

up vote 2 down vote accepted

I think a good place to start might be researching Agile techniques. Scrum specifically has a couple of techniques that I think could help you. I am a fan of Scrum, so I would recommend taking a look at the rest of the method as well, but these are the specific features that come to mind from your question. If you like how these techniques sound, I recommend you pick up a book on Agile methods / Scrum and see if the rest of it sounds useful as well.

  1. Regular retrospectives. This is a regular meeting (often monthly) to reflect on your work since the last retrospective as a team. Team members answer the questions, "What worked?" and "What didn't work?" Often this triggers ideas for processes the team can try to fix issues, and helps the team retain and consciously recognize good habits and useful processes.
  2. Tracking estimates vs. actual progress. Make estimates of your work ahead of time, then compare how fast things actually get completed. Scrum uses a "burndown chart" (Googling this is left as an exercise for the reader) and I think estimating a chunk of work at a time as a team, then tracking actual progress is a very useful exercise, but even tracking on a personal level will help. Estimating as a team has the benefit of allowing your team to figure out their velocity, which is the amount of estimated work your team can do over a period of time even with their normal emergencies, interruptions, efforts to stay up-to-date, etc. This could be especially useful for a team that does both support and delivers functionality, since it can be very hard to get a picture of how much new functionality and deliverables your team is able to accomplish when they are getting randomized a lot with support needs.

My experience with the entire Scrum method has been that it takes a team 3 to 6 months to see improvements, but then the entire team starts to "gel" with reliable estimates, improved morale, and less overtime with more results. I haven't had much experience with other Agile methods.

share|improve this answer

While the things mentioned in the other answers are more important and should be applied before what I'm about to suggest, there is one thing missing that works very well in my experience: Hacking Day or Hack Day.

What this is is basically that once a year (or more, but bosses typically don't allow that :)) you take one day and spend it as a team working on something completely separate from the daily projects/products. One week ahead, hold a short brainstorm to determine what direction to start thinking in and on the Hack Day, work as a team the whole day to make a complete working tool/application/site/script/whatever.

For example, typical things to develop on a Hack Day is a visualization to accompany your product, or that gives insight into how people use the product, or that provides a radical different perspective on how users use your website, or... It actually doesn't matter much what you do, you could even just try porting your application a different platform/language.

Regardless of what you end up doing, it does tend to:

  • Strengthen the team spirit by focusing on something with a limited scope together for a full day.
  • Give interesting new ideas on what types of features can be cool for your product from an engineering point of view.
  • Facilitate learning by removing everyone from his daily work and clearing the mind.

In my experience, visualizations are usually nice because they give you something cool to show at the end of the day.

share|improve this answer

If you insist on code reviews and lead them conscientiously, then you can be sure that your group is improving steadily. Besides finding bugs of all kinds in the code under review, the process has important ancillary benefits. Here are a few off the top of my head:

  1. Most important, imo, is that code reviews promote egoless programming.
  2. Reviews tend to instill good programming practices that pay off in later projects. For example:

    • always check the return code from every function;
    • it's always int main( int argc, char **argv )
      never `void main( );
    • in a conditional, always use curly brackets; forget the sloppy shortcut that says you can omit curly brackets if the consequent statement is only one line. This one principle will save countless hours of debugging later.
  3. Reviews can promote a standard coding style and make all programs easier to read. Like:

    • to indent, use two (three, four, eight) spaces, never tabs;
    • } else {
  4. Reviews educate the team, especially newer members, on standard coding idioms.

  5. Reviews help to rank group members' abilities.

If you don't bother with code reviews, then the quality of the code your group produces will never improve; and you'll be fighting constant fires. Who wants that?

share|improve this answer

Another good start might be to see how you well you guys do on the Joel Test, and see if you can improve your score.

share|improve this answer

I'd probably start with your users - what would the user groups like to see improve?

There's always budget - how can you do more, with less? That comes down stuff like:

  • Bug analysis - is there a type of bug that you could prevent by changing your practices
  • Estimation/efficiency - how are your estimates and how long is work taking - are your estimates off, or is your work less efficient than it could be?

CMMI intense companies often have more metrics than these, but I always those are the best in terms of common sense. Often trying to improve these areas will highlight other things that could improve - like team work could be enhanced by better reviews to prevent bugs.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.