14

All work is probabilistic. It has an extremely improbable best case result, an extremely improbable worst case result, and an extremely probable most likely result. That probabilistic distribution is driven by both random and non-random variables and a PM, no matter how talented, can do absolutely nothing about the random variables and can likely affect ...


9

Routine remains the same Scrum Master's routine remains the same even after the team gets well adjusted to Scrum. It is possible that Scrum Master may have to spend less time on individual duties but the overall responsibilities & expectations remain same. Some of which are as follows: Identify and remove impediments in team's progress Help and foster ...


8

The Scrum of Scrums should happen after the daily Scrums because otherwise it would be hard to answer the three questions there. In case there is an important decision, the ambassador shall go back to the team, and explain in 3-5 minutes. Anybody from the team shall be able to represent the team in the SoS because they pay attention during their Scrum. ...


8

Management Owns Cost-Overruns A Developer estimates between 70 to 100 hours for a task. Due to the urgency of the task and the developer's unavailability, a far less experienced developer is assigned to the project. The new developer takes 200 hours to complete the task. This is the agency's responsibility 100% of the time. Whether the estimate was wrong,...


8

Is it my job as solution architect to learn all these laws and see how they apply to the software we are going to make or should this be a task for somebody else? If you don't want to learn the laws, you are basically asking to receive complete requirements with everything perfectly laid out for you, so that in turn, you can then lay out a technical ...


8

Yes, a project manager is responsible for completing a project on time. However, "on time" is a date that will often move during the life of the project, and it is the agreed date that the PM should be measured against - not necessarily the original date. The initial date may be agreed by all concerned, however requirements may change, issues are ...


8

To answer this effectively, it is important to split roles, job titles, and skills. Scrum has absolutely nothing to say about job titles, so we can actually resolve that fairly quickly by saying: as long as a particular "job" does not expressly conflict with Scrum, it is "allowed" in the Scrum framework.That isn't to say that particular ...


7

Firstly, you could use different methods/frameworks to run projects. Scrum wouldn't necessarily be the solution here as your prime concern is around the line in responsibilities between these two, both different and both required, roles. As well as getting the right level of communication set up. I have grasped something from the tone of your question that ...


7

Even if you - as solution architect - get a list of "we need x, y z" and you describe how this should be implemented, you still need to be aware of the laws related to security, privacy, scalability and more. E.g.: if the law says you need to use a Secure Connection, then your "solution how to communicate" needs to deal with SSL and/or ...


6

There can be no general answer to this. Multinational or public companies do vary greatly. Software developed by such companies varies even more in size, type, purpose, usage, life expectancy etc. In general, the bigger, longer used and maintained, more complex the software is, and the more people are involved (at the same time and/or over the long term), ...


6

Well the answer is really "It depends" mixed with "Why do they need it?" and "What's the least you can get away with?" This is really about interviewing your stakeholders and doing a 5 Why's type analysis. Find out why they need something, so you can then work to meet that need with the minimum work on your part or even not at all because it doesn't apply. ...


6

That project needs to be released in 2 months, but we estimated around 6 months of work on it. So we need to get more people working, so that we can fit in that time period. Adding more developers will not solve your problems. Study of The Mythical Man-Month by Fred Brooks is recommended. Also Testing & Verification should happen alongside of the ...


6

There are two sides to this - laws and regulations. I would not necessarily expect someone on a project team, regardless of their role, to be an expert in either law or regulatory requirements. I would, however, expect an organization to have access to experts in these fields, either as employees or some kind of contractor or consultant relationship. I would ...


6

A project manager has the overall responsibility for the project's success. But what is project success, you may ask? Many executives see project success as delivering software on time, on budget and packed with features, which history has shown, time and time again, that for most projects it's impossible to do. Even if you have the right kind of people and ...


5

Oooooh boy... Where to start.... If you're almost finished but you're "stuck" on testing and debugging you are definitely doing something wrong in the first place. Waterfall much? If you, or your salespeople, have sold a 6 month project to be done in 2 months you're in the hole already. None of these problems are actually related to your project management ...


5

No, it can't. In the RACI format, the Accountable person is the one ultimately answerable for the correct completion of the task. It is also the one who delegates the work to those marked as "Responsible". As such, there has to be only one accountable specified. See: https://en.wikipedia.org/wiki/Responsibility_assignment_matrix


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

TL;DR There is a lot more that's structurally wrong with your situation than you think, and based on your tone and framing you yourself appear to be part of the problem. Your company appears to have an immature organizational structure without mutual respect between roles, and various people involved in this situation seem to be communicating poorly. Only ...


5

Scrum is based on an empirical process control system. It assumes that not everything is known and that knowledge will emerge over time. Trying to specify every acceptance criteria in exact detail may not be possible and may take way more time than needed. It's not possible to know all acceptance criteria in advance. Instead, Scrum explains that the ...


5

I agree with the other two answers, but I'd phrase it slightly differently. The Project Manager's primary responsibility is to manage the expectations about the project's completion date. This can involve Working with the project team to ensure that work is accomplished to bring the project to completion at/under/near the estimated completion date. ...


5

From what you are describing, it looks like: You want your team to be (more) self-organizing and proactive in doing the work, and engaging in conversations with you (the PO) when they spot something missing. You want them to be more Agile. Your developers are more accustomed to being told what to do and to receive detailed task for which they don't really ...


4

There is a difference between an estimate and planning value. An estimate is a probabilistic range and should include variables such as less qualified resources doing the work plus about 1,000 other aleatory and epistemic variables. Therefore, the proper estimate should have been 70 to 200+ hours. In this range, you need to chose the planning value, say ...


4

The RASCI being developed is intended to highlight the support model going forward. From my perspective a RASCI encompasses all aspects of the project including handover. It can do both, or neither. RASCI is just a tool to get agreement and understanding on who is responsible for what and at what level. If it's useful to have as part of your project (lots ...


4

There are two main ways I know of that work. First, a possible answer is 'The Product Owner' (or someone/someones with the same responsibilities). Namely, someone who knows the customer's requirements. The second option is to allow anyone to add Stories, but to have the Product Owner (or equivalent) vet them. Of course, that's only for Stories (...


4

You could treat his submission like any other pull request: give him feedback like you would any other code review. If he understands the conventions of your team, if he knows your team doesn't put code into production without acceptable test coverage, then he might take the feedback seriously and improve the code. Code quality is, however, only part of ...


4

Besides for dns's suggestion to add it to treat his submission like any other pull request and test it thoroughly, you also need to add values to your concerns. Create a document explaining the cost, in man hours, of each concern: We'd have to rewrite everything That means X coding hours, X testing hours and X debugging hours. It's not great code That ...


4

I can only speak for software projects. The team as a whole ought to be responsible for success and timely delivery. If you are dependent on a PM to get the project done on time then you surely have a dysfunctional or disengaged team. If you wanted to single out one person having a greater part of the accountability for success then it should be the Product ...


3

The answer is in your project charter. It all comes down to scope. If your scope included not only the development of the product but also the original business case of that product--which found a 20% ROI--then your project would have a PM who would have this type of expertise and that PM's project budget would include the business analysts and other ...


3

I am reading three separate and distinct issues: 1) current team is "stuck" in testing and debugging; 2) new project with an initial target of six months and now a commitment to a target of two months; 3) fear of a stretch role. 1) What does stuck mean? If during your testing you're finding an abnormal amount of defects and defects skewed to a high ...


3

What happens when there is conflict (priorities, dependencies, technical standards etc.) between 2 or more teams? That's what a SoS meeting is for - not necessarily to resolve the conflicts, but to identify them and coordinate and facilitate the resolution. How do the multiple teams maintain a co-ordinated direction when different team members may attend ...


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