12

During our last project, our team composed of young software engineers made a product which contains much more bugs than other teams. We have a senior engineer who was part of the team, but isn't much involved in the development process as he has been promoted to manager. He just reviewed the team's code for the first time and found a lot of issues.

This team has shown strong capabilities in the past, but the result of our last project got me worried. What the team members said about this last project:

  • It is more complicated than our previous ones: lots of requirement change, complex interactions with the database, complex UI, new technologies...
  • Not enough time, too much pressure
  • Hard to understand the requirement (however we made sure everybody understands the requirements thoroughly during the project)

I trust my team, they are really good people. What can I do to make them improve their output?

Improve this question
12
  • 6
    How are you managing bugs? How are you managing the development cycle? What priority is there on quality? If you can't measure it you can't manage it.
    – Jane S
    Commented Jul 1, 2015 at 3:03
  • Most of the bugs popped out at the end of the project. The senior engineer said it was due to bad code.
    – Brainless
    Commented Jul 1, 2015 at 3:13
  • 2
    Are you doing code reviews? Pair programming? Perhaps utilising a methodology like Agile may also help, if you are not already. Instead of a monolithic testing effort at the end, you can test after each iteration and push bugs back into the backlog to be addressed.
    – Jane S
    Commented Jul 1, 2015 at 3:15
  • 2
    Can you track when these bugs were introduced? That should give you an indication of the cause so you can try to plan around it. Don't be afraid to manage upwards (as early as possible) if the timeframes are too tight and introduces the risk of additional bugs!
    – Jane S
    Commented Jul 1, 2015 at 3:34
  • 1
    Note that the subject line really should be how to help them 's improve quality, especially if you're arguing it wasn't entirely their fault...
    – keshlam
    Commented Jul 1, 2015 at 4:36

2 Answers 2

Reset to default
15

To coalesce the comments into an answer, it seems as though the issue isn't specifically your team, but rather a management issue and having difficulty managing towards a tight deadline that led to rushing the final sprint. From the comments above:

We are using Agile. The team has been doing code reviews regularly (without the senior engineer). Their opinion about the code contradict the opinion of the senior engineer. For them, the code is ok. QA tested at each iteration, and as I said, it is only at the end that a lot of bugs appeared.

It sounds like you are doing the right things within the team. However:

I would rather believe that the last iteration was rushed. QA have done a great job in the past finding highly non trivial bugs. They got praised from other teams

It's easy to say that the problem revolves around that point, but looking deeper the issue is one of not necessarily managing the scope of each previous iteration to ensure the timeframe was realistic and not put undue pressure on the last sprint.

So how do you avoid this? Well, what you need to do is to track your progress against your delivery date. How many modules are left, and will it fit based on your current burndown rate and planned iterations? Do you have to make allowances for any bugs you've come across? If there is a discrepancy, raise it as early as possible so that you can either reduce scope or push out your deadline.

Your team seem to be doing the right things with regard to code quality. Where the issue seems to lie is in managing your sprint planning and tracking against your scope and delivery date.

Improve this answer
1
  • 3
    Good answer. I would add that since the senior engineer (now manager) has found issues that the young team did not recognize, it would be prudent to involve the/a senior engineer in each of the iterations to review the code and mentor the younger ones. Hopefully the company organization would facilitate that type of involvement. Better code reviews will slow down the team velocity (for a time) but would pay off in the long run.
    – Kent A.
    Commented Jul 1, 2015 at 11:07
5

I would involve a senior person much earlier in code review in this case. We require code review before code can be pushed to QA. And then I would consider taking the code review advice and developng training from it if ther are consistent problems. But the single most critical piece in improving the qualit yof juniors is to not fix their code, but to make them fix it. They will learn more from doing the actual fixes once problems are identified. Make sure to explain why the items identified are problems instead of just flagging them.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .