7

This is about span of control. And there are rules of thumb to help an organization decide when it is time to put in a layer of control. Of course, there are competing and contradicting schools of thought on this. You need to research the benefits, costs, and risks of different approaches to see what fits best in your organization for this project at this ...


7

Some points from my side to add to the ideas already expressed: don't promise anything you will not be able to honor, or make it clear that is your intention and may be subject to changes. Even when this could seem very basic when dealing with mature adults, it can be surprising how not meeting these kind of expectations can demotivate someone. consider not ...


7

This is a pretty big question that might create a lot of advice, but I'm sure there are also nuances that we will not get here. There are also multiple questions and challenges embedded into your question so I'm going to answer generally. You are right that grouping by areas of expertise is considered a bad idea as now no one group of people actually has ...


6

Scrum of Scrum meetings should handle dependencies between teams It is not recommended to have planning meetings with multiple teams together. With such a large number of people, team members won't be able to pay attention, as you are finding out. For coordinating cross-team dependencies, you can have separate scrum of scrum meetings. Please see more on ...


6

Experience is a weak indicator for future success (Hunter & Hunter, 1984). So feel free to remove time in chair as it will not hurt you. Age is a zero indicator for success (same study) so definitely remove that from the equation. Your best predictor is cognitive ability, to be able to think critically, to be able to analyze. Since all of your ...


5

You can't compare efforts between marketing and accounting; accounting is non-competitive. I suspect it is an error to try to compare efforts which are dissimilar. The problem set before you is difficult and potentially wicked. On the other hand the only option you can rule out is to do nothing. I suspect that if I were in your shoes, I'd ask the teams to ...


5

I did some experiments in the past and it seemed that those teams were successful, where the members where able to work together before. This setup were way better than the setup when the team setup was based on the necessary skill sets. My suggestion would be to setup teams based on the existing "small groups". People with the same understanding learn more ...


4

If there are truly no advantages in people's existing skillsets, then you have to look at other factors. You need a good mix of solid developers and more wisened developers to ensure success, especially since this is out of everyone's comfort zone. I would first look at your more senior (company-wise) developers and chose the ones who are some of your more ...


4

I would add an additional option: allow your scrum teams to select whatever they want off the backlog. You have given the scrum teams a prioritised overall backlog and they know what they are capable of delivering. If you allow the teams the complete freedom to take whatever stories they want to into their sprints then the overall process should deliver ...


4

We use Trello in a very similar setting and have indeed encountered the same issue. Our current approach to resolve it is to divide the planning into two phases: First, we distribute our velocity over the projects, to plan how much attention we give to each project in the next sprint. Everyone does this for himself, since different people participate in ...


4

Some ideas coming from working in the same environment: Small Changes 1) Shorten the duration of iterations for team A so that they are required to ship product more frequently and in smaller increments. Shortening the iteration will allow for quicker response to changing priorities at a higher coordination cost. You're still doing scrum but basically ...


4

I completely support Mark C. Wallace on his suggestions. Once you have the goals set though, you can't just let them go on "auto-pilot". If you set a goal for the next quarter, and then you don't check in with your teams until the end of the quarter, odds are those goals are going to be missed. It's just basic human nature and why, despite it being field ...


3

I've had 2 experiences in the same company with distributed teams: In the first experience, I was Scrum master and I had 2 members abroad (with 8hrs difference). We just couldn't control how much time they were exactly working on the project and they were constantly pulled onto other projects of the remote location. It didn't work smoothly. In the second ...


3

It's a matter of risk management. Clearly you can start the dependent work early, but doing so incurs risk on the project- How much risk is determined by the a number of factors but two key factors are: The approach you take to defining the interface up front in the absence of the right resources and clear requirements What is the impact of getting it wrong?...


3

I was in a similar situation a couple of years ago. We had a large meeting, because we thought that it was the best way to solve dependencies. We observed that most of the participants weren't listening, because the discussion was irrelevant to them. As a solution, we kept the meetings in the same time but at different places, near to each other. So when a ...


3

The more I read this question and think about it, the more it seems that this is really an issue of you working in an environment where there is limited information about a project's progress and therefore where informal relationships take the place of a clear reporting process. Rather than dwell on the problem, let me propose a potential solution. You ...


3

I think there are two problems here. I cannot improve on David Espina's description of the Span of Control problem; the second problem has to do with accountability. The PM is focusing on the areas where his technical skills are most applicable and failing to exert effective project management over the project. I think the H/W vs S/W issue is a ...


2

The project should be sub-divided as you suggest only if it is so complex and/or critical for your organization that there is business value in having the added overhead. For example, I've worked on US govt projects that have had multiple PMs overseeing different aspects of the overall project just because the workload was that big. I think anytime you have ...


2

You may need to amend the scope of your meetings so that they are more efficient. One approach would be to have a series of smaller meetings: The first meeting in the series (and of a sprint) would be inter-team with key team leaders who have the knowledge and authority to speak for their teams. At these meetings you could talk about their issues, review ...


2

Why This Isn't Your Problem This isn't your problem. Whether or not a project succeeds (and most don't) is the responsibility of senior management, although management may delegate day-to-day operational responsibility for the project to a product or project manager. Since you've already notified the accountable person that you feel the process is broken, ...


2

I am currently looking after three projects; A, B, and C, which solutions are being developed by three different teams as follows: Project A - Team Green Project B - Team Blue Project C - Team Yellow Our sprints are 3/4 weeks long commencing at the same time for all projects. Projects A and B have several dependencies of Project C. Likewise, Project C ...


2

Make sure you are communicating. Make sure the Product Owners responsible for A understand the dependencies that B is relying on. Work with them to get agreement on prioritizing the items that are needed for the teams working on B to be able to make progress. If necessary, escalate this to whoever is in a position to care about both A and B succeeding. Be ...


2

Communication is key I was the Scrum Master for 2 teams in Hyderabad, India (contractor), one in Montevideo, Uruguay (contractor) and one in Washington DC for a previous company. The time difference with Hyderabad is 9.5/10.5 hours. Here are some best practices that we developed over a period. You may not be able to implement all these. Strive to get there ...


2

I'm not all that familiar with the details of ITIL. When I've run across it, what I have usually found is the process was stagnating the origanization. What I would advise is flip things around, instead of laying in a large process (with all the documentation, training, ramp up, etc), start where you are and develop something from there. This falls under ...


1

If you use Microsoft Excel and want to have an easy transition to a tool that allows you to aggregate data and display them in dashboards, then I suggest you try Smartsheet. Smartsheet looks like Excel and has some (but not all) of Excel's functionalities. What it adds is that you share the sheets, and you can easily display data in dashboards. With ...


1

Project will assign the resources at their max units as defined in the Resource sheet. If you want to assign resources at different amounts, you'll need to enter the units manually. What are the resources' max units?


1

Lots of facts that need to be brainstormed. I will focus on the bullet points to hopefully give you enough to think about. In some way it feels like I had the same issues a several years ago. Workload is not even across all resources of the team: Try to figure out the root cause of it. My problem was that the each individual was the owner of a specific area ...


1

Erin has some great general answers. I'd like to add a couple specific suggestions based on the set of projects I've been running. The situation is similar to yours in many ways(needing to use a set of people to handle ongoing maintenance, small change request, and new development... and needing to bring new members on from time to time). The usefulness of ...


1

As with most questions, the answer is "it depends". So a couple of questions - Are the teams/dependencies heavily inter-related? Are there central points of contact for each team that could attend and then relay information/decisions? And most important - what's the history of the projects/teams? do you foresee issues in decoupling the team meetings? You ...


1

If the goal is to reduce meeting planning time, then hold a single meeting and timebox it. A single one hour meeting fits the goal better than three one hour meetings. However the question text hints that there may be more constraints on the goal. I think the answers provided by others are correct, but if I were in your shoes, I would hold three meetings ...


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