33

As a Product Owner or product manager, you shouldn't be too concerned with the details of how the development teams are working on a day-to-day basis. If you believe that certain aspects of the way of working are leading to risks in the ability to build and maintain the product, you should be able to raise those concerns, but you shouldn't attempt to direct ...


12

Just don't call it agile. Often the resistance to agile ways of working is associated with the terminology. It is not uncommon for teams to 'hate agile' when in the past they worked in a flawed agile implementation and learned to dislike it. They now associate the terminology with bad things. As a Product Owner you can't dictate the way the development team ...


9

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 ...


7

It is hard to say anything without more details. You just mention there is a potential problem with the level of specialisation, but you don't make clear whether that is a real problem or whether it is just a concern that you have. It is also not clear what the typical size of a project/assignment is for the organisation, which can make a dramatic difference ...


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. ...


5

You have said a few things which are legitimate concerns for the development team. Agile teams are supposed to be self-managing but your team apparently is not because developers are having work allocated to them individually. You say that the product team are intervening and apparently your developers don't feel in control. These all seem like symptoms of ...


3

As a Product Owner maybe a goal oriented approach could lead to change in behavior. Example goal Reducing time to market: To be able to compete with competitor X we aim for a time to market of less than a week. Delivering a couple of end-to-end features in a week might be a real challenge for a group of hero-coders. The group could now self-manage and adopt ...


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

Aim for cross-functional teams in the long term Welcome to pm.stackexchange! As @Sarov suggested, you should reorganize into feature teams. In the meantime, here are some suggestions for better coordination: Ask the two teams to publish their plans in a visible whiteboard: Just by making their plans transparent, they will be motivated to resolve diverging ...


3

one team is waiting for another one Teams should be cross-functional! If you have one person working on the back-end and another person working on the front-end, make sure these people are on the same team! Make sure they're communicating daily and kept apace of each other's work. If you're currently dividing teams by discipline, re-organize them to be ...


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....


2

Welcome to the real world - I have seen what you are describing to a higher or lesser degree in all agile or not-so-agile teams I have ever come in contact with. The thing is - and devs can be awfully short-sighted about this - that with good people, this will just work splendidly. Too splendidly, in fact. All is well until one of your key persons (and ...


1

By all means, the very first thing that I would do is to "talk to them." They are developers with a not-insignificant amount of experience working with the very thing that you are now going to be managing. If they are objecting, why are they objecting, and exactly what are they actually objecting to? Using a minimum of "Agile terminology,&...


1

Beware of falling into the "We are doing Agile and we are doing Scrum" trap! Far too many people think that rigidly following a set of procedures is (1) the only allowable form and (2) means they are achieving the intent and goal of Agile. I recommend reading all of "Joel on Software" end-to-end, and also thecodelesscode . Now, ...


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