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


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


7

My day to day job consists of sprint planning, user stories, coaching, being involved in software architecture, reports, sprint retrospectives, user acceptance testing, managing resources/ stakeholder expectations etc etc Wait a second. Why are you doing software architecture? You are managing the project. Your technical people should decide on the ...


6

Nothing in Project Management is Free It is usually very difficult to explain to management that it will take time to repay technical debt and that the team will be even slower refactoring rather than delivering features. You already know the answer: you can't create a bigger pie by carving it into more slices. Ultimately, a team has a finite amount of ...


6

The first counter to 'this requirement will be easy to deliver' should always be ask politely to list down the risks involved. Such unfounded claims are done by people who want to boast or want to challenge the team off a cliff. The art of war in such situation is to transfer/overload ownership by asking counter specific (not open-ended) questions to the ...


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


5

I am a developer and after reading the discussions going on here I would like to answer from my perspective. One thing I have really appreciated about non-technical project managers is the fact they think their dev team is amazing because they pull off the feats they do. They also ask a whole range of questions to understand. In contrast when I have had ...


3

I'll give the same answer I gave in the "Non-Technical PM" question. It applies equally here. In your specific case, you need to educate senior management so you have their support. And then you need to give the team more visibility into what you do day to day. Make it clear that they would have to share this work if you were to do coding work. 3 down ...


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


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


2

What you need to uncover is the driver behind the 'this will be easy' rhetoric. Is it innocent optimism? Is it designed to keep sponsors interested in funding this project? Or is it designed to insulate themselves against a risky project such that they can point to another group or individual--such as you--when and if the project goes south? No matter ...


2

Stakeholder analysis can get as sophisticated and detailed as you want to make it. There are practitioners that specialize in this and this effort can get quite exhaustive, time consuming, and expensive, but very valuable. Since you are new to the PM role and do not have experience with stakeholder analysis and management, you can design an effort that is ...


2

Mapping stakeholder interests is an always-ongoing activity. It should never be complete, merely reviewed. Organisations revolve staff through Projects and Programmes constantly so stakeholder maps should be updated as often as required. Asking Directly As a Project Manager, you will receive very little guidance about how to run your project and that level ...


2

One is tempted to do these to manipulate dates for just-in-time work: Install pump -SF-> Deliver pump; Construct platform -SF-> Platform pre-construction meeting; Commission Eqpt -SF-> Energize equipment. Although this gets the dates where you want them, the logic flow is reversed from reality. This messes up critical path and other logic analyses. Some ...


2

Use SS with the number of days lag you need. Then load the duration of the succeeding package so it will end the same as the preceding task. When you baseline, the finish dates will end like you want. That is the only time when you need the ending dates to match. After that, your finish dates need to move based on how you load actuals, which is how you ...


2

Here's a simplified, idealistic example of what is usually happening in this situation: Management has Team A that they think has a velocity of say 100 story points/iteration. Management thinks Team A can deliver 100 pts of business value stories each iteration. In reality Team A is is always pressured to provide more and really they can do 90 pts of ...


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

It sounds like you are half in and half out of the techincal side of things. I would advise removing yourself from all technical descisions, discussions, architecture, 'trying to make things easy' etc Concentrate on the timeline, budget and customer acceptance. Set challenges rather than specifiying solutions. re the bitchy dev. They need to be told to act ...


1

Overall, I think the answer to your problem lies in more transparency, but to get that, I think it may help to re-frame your issue a bit. It sounds like there are two things happening here and I think there's value in looking at them separately. The first is that the development organization needs time for things other than coding new features. This may be ...


1

Quick Answer: During each sprint planning meeting, discuss technical debt issues and create a placeholder card in each sprint with 5-8 or so story points that will be used to address re-factoring. You can do this as well for releases. This is a way to incorporate technical debt in your teams planning and the best way to describe it to management, is ...


1

I don't know that software package, but it does not make logical sense from a scheduling point of view. Consider the case where your development is ten days long and testing is also ten days long. But then you need to do more testing so make it 11 days- With both SS and FF constraints the package will not be able to move either the Start date or End date to ...


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