8

It's great to hear that Code Reviews went smoothly and you are seeing results soon, you have seen it's effective and that means the junior programmer is keen to learn (All good stuff) Few things I would like to suggest which can be done at your end Good code samples from existing code base - You probably have some star quality code in your existing code ...


5

Your premise is toxic. Both teams are putting too much emphasis on who is to blame and too little emphasis on fixing the recurring problem. Currently, your two teams are in an antagonistic relationship with each other. For one to succeed, the other needs to fail. That is the root of your problem. Try to get your two teams to work more closely together. ...


3

Transparency, Visibility, and Emergent Process Design Transparency of the process is the result of practices and artifacts that create visibility, and leverage the inspect-and-adapt cycles of the framework. However, transparency and visibility will not intrinsically help the team complete an increment. For that, you will need to identify the process issues ...


3

Consideration should be given to the nature and size of the organisation, and the number of projects / initiatives being run. If the team is likely to flex significantly in terms of the people working within it, and if there are several (or many) teams all working on different projects, then it may be necessary to consider the reality of having people moving ...


2

Do Pair Programming. I often find that Code Reviews tend to demoralize people, because you criticize (potentially a lot of) their completed work. Even if you are good at giving feedback and the other one is good at taking it, this will be an issue. In Pair Programming, on the other hand, you start a task together from scratch. Let him take the lead, listen ...


2

This is an interesting question, worded well (thanks @CodeGnome for editing) and highly relevant. Unfortunately the answer is, like many questions regarding ideal practices, a firm "it depends". It would depend on the Nature of the Development Team Existing Practices Organisation Culture Exact type of Agile implementation Individual personalities ...


2

In fact, the Project Management Institute has two monograph about the evidence associated to Project Management practices: Quantifying the Value of Project Management. The monographs shows that Project Management practices improve schedule and cost predictability. Researching the Value of Project Management. The monograph establishes a research program for ...


2

If you are trying to assess the scientific validity of the PMBoK, you will not get too far. The PMBoK is a body of knowledge and not even the complete body of knowledge. It is not prescriptive but rather descriptive. There is nothing to measure. However, if you dig deeper into the practices, such as EV for cost control or critical path management of ...


2

Always. You said the word "involved". Involved - yes. Dictate - no. One of the most often unseen aspects of a successful Agile development project is that the team is one cohesive team. Not the technical team and not the business team, but the singular Team. Everyone has a stake and everyone has a say. If I was to ask a different question, how would ...


2

TL;DR Refactoring is a natural part of iterative and incremental development methodologies. However, a high ratio of defects in a product indicates one or more fundamental process problems. Such problems represent a cost to the project by consuming budget, schedule, and resources. High defect rates also create a drag on productivity that increases over time....


1

There is no standard measure of acceptable quality as each organisation exists in its own domain. For example, a startup working with a radical new technology may accept a large number of issues as for them speed to market is more important than quality. A company building medical applications will usually aim for a very high quality standard. Having said ...


1

I'm not sure where you got the idea that "git project managers/software developers manage the versions of a program [...] from the customer's perspective". I use git and I certainly don't have a separate repo for each customer... Anyway, the following works well for my Team: For products that have variations, but will eventually be merged Use git's ...


1

I would suggest, the new member be involved in testing of existing module rather than coding as this would introduce the new members in existing coding practices and standard. Once the new members has a basic idea of the coding practices, it would be best to introduce the new programmer in programming reports or basic forms.


Only top voted, non community-wiki answers of a minimum length are eligible