21

when pushed to do 60, they will deliver 60. This is a pretty meaningless measure in these circumstances. A team could drop quality to deliver more points or simply game the estimation of stories. Story points and velocity were designed to help teams estimate their capacity in a sprint. They are not intended to be measures of performance. If you want to ...


9

Velocity Isn't a Productivity Metric In other words, when they are left to decide how much is too much, they will say commit to 40 points, whereas when pushed to do 60, they will deliver 60. If you are managing to a velocity metric, then you're Doing Scrum Wrong™. Velocity is a capacity metric, and has no utility in measuring a team's productivity. Even ...


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


7

TL,DR The throughput of an outsourcing team depends mainly on culture and expectations on them. Consider both aspects before acting. I believe there are a few aspects that are prerequisites to be understood before entering into the actual solution. Why Outsourcing? First of all, there's a reason why companies outsource to offshore locations. In most of ...


6

Since no one has given much advice in terms of software products, I would just like to put forward that Team Foundation Server 2012 Preview is free for less than 5 users, and is a great resource for managing distributed teams and facilitating communication. To highlight some of the ways it can help you: Request Code Reviews - Any changeset can be shelved ...


6

It sounds like you've got a few layers of challenges. First and foremost, it doesn't sound like you have a team so much as a group of people that have been put together on an org chart. If the different team members can't support each other, then you'll lose most of the benefits of a team and team-based estimation is useless. If that is the case, then your ...


5

TL;DR Communications planning is an essential part of the project initiation process, and some methodologies (e.g. PRINCE2) include it as a formal documentation process for that phase. The specifics of your plan, as well as the pros and cons of any given control, are very situational. Specifics can't be effectively addressed outside the context of your ...


5

It is a poor workman who blames his tools. The false premise underlying this question annoys me; I have rewritten this answer several times to try to take out the withering sarcasm and the ire, but I think that ultimately it is more honest and effective to admit that I am working hard to be respectful while I am annoyed. I have worked on teams that rely ...


4

Getting started with a distributed software development team Welcome to PMSE! You said your team will be doing web and mobile development. Even though your question is very broad, I am taking a shot at an answer. If you have follow-on questions, please feel free to post them here as new questions. Pick a development process - here is the super-short ...


4

It seems to me like you have two issues: lack of knowledge dissemination, and lack of an estimation benchmark. Knowledge Dissemination Currently it looks like all of your developers have a bus factor of one. If any of your developers gets hit by a bus (or quits, or gets fired, or goes on a long vacation, etc.), then what happens to his/her project? S/he's ...


4

I concur with some of the other points made, specifically: Not really a team and sounds more like multiple teams of one. Knowledge dissemination is also an issue. No real benchmark for the estimating. I would add the focus of the question seems to be on finding a tool to overcome...something?? which makes me curious. What interactions are you trying to ...


4

All the team members can agree on some set of guidelines to help. We are following these fun guidelines that are working very well for us: No person can talk for more than 1 minute at a time. Every person in the team must talk. Every person must nominate the name of another person in the team, at the end of his/her turn. The nominated person will then talk ...


3

You can choose to go one of two ways. Detailed, up front requirements. Very precise, not flexible and required a lot of up-front work. Goal based "Stories" that describe what the end user experience should be like. Remember the end user does not have to be the guy on the street. It's who will be using it day to day. Doesn't require a lot of up-front ...


3

If you ask if Kanban is going to help you deliver, it won't. Actually, none of the methods will. There is the project management triangle. If the time which says that you cannot have all the angles - scope, schedule, and cost - fixed. If your scope and schedule are fixed, the only thing is left for you is to hire more people that increases cost, increases ...


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 don't think there is much flaws in process which you mentioned. My suggestion is, as you said team should not have 30 members. Ideally in Scrum, the team should be 7 to 9 members. It includes dev team, testers, scrum master and product owner. I would suggest to divide your team to smaller units and have a Business Analyst who manages the team goals, Scrum ...


3

This is still a very complex question, and I think it is possible that an answer will nail a part of it and miss the whole. I'm still thinking about the problem, but in the interim, I found the following quote today The design specification must be governed differently than the requirements. If the requirements were appropriately governed, and if the ...


3

Your Question, Redefined My main concern is people dropping out and leaving half finished work behind but I'm sure there are other challenges I need to consider. There are many such challenges with any drop-in/drop-out resource matrix. Your question is broad, and not fully answerable in it's current form. However, I think it's answerable if you redefine ...


3

I think there are an infinite number of examples of people who never see the completed result of their work. It would be a unique individual who would suffer morale issues secondary to this and would likely be due to other things. There are three things that have been found to motive us: autonomy, mastery, and purpose. I cannot see how not seeing the "...


3

Remember to include opportunity costs in your cost/benefit analysis of either approach. While the price to get raw information might be lower for crowd-sourcing (for example), it may take more time to validate the data, standardize the format and get the website off the ground. It strikes me that you could mitigate risks by hiring a subject matter expert ...


3

Crowd-Source. With a similar system to the one used here, merits and demerits could boost agreed upon information to a higher rank, calculated alongside a reputation value bestowed upon the actual user who submitted the data. The users should have incentive to participate and interact, like the badges offered here. Vanilla Forums are a great open source ...


3

I have played with some 'spatial' tools for distributed teams since 2009. These can be 2d, or 3d like the tame 'the Sims'. I've watched how other companies use them too, and attended 9 conferences on the topic. I find these tools so useful I got a formal certification in this stuff (one year program, U Washington), and have 200 folks using this stuff for 2 ...


3

While I generally agree with the comment of the first answer (you don't want to be purely punitive; you need positive incentives; etc.), it is possible to motivate people to move in this direction without explicit rewards. What management talks about with the developers is what they think about. If all management talks about is deadlines, that's what ...


3

You don't communicate for the sake of communicating. You do not deploy a communication vehicle if you have no message to deliver, no message to receive, no messenger, or no audience. Part of your communication is the analysis of who, what, where, when, why, and how communications need to be conducted, i.e., NEED. If you are finding they do not want it, ...


3

I'm currently managing 7 teams that contribute to a single project. While we're one large "team", each team does their own estimates. This sounds very close to what you have -- one large team, made up of several smaller teams. This is where your problem can be solved -- recognizing you have multiple teams. Each team should be responsible for their own ...


3

Recommendation: Split the team in into 2 teams Goal: Team doesn't have to take hit of staying late / coming early Prerequisite: Stories teams going to work should be independent as much as possible. Cons: Scrum Master has to repeat the ceremonies for both the teams. Risk: Team alignment on work progress / status Risk Mitigation: Scrum Master shares the Work ...


3

I have 13 years development experience. I worked as an outsource engineer for Weight Watchers from Jordan, and then later in my life I did manage outsource teams myself. I also managed onshore teams. Managing teams when they are offshore can be different, but motivation i don't think its much different specially for talented engineers. Whatever motivates ...


3

The first item in the Agile Manifesto is: Individuals and interactions over processes and tools Your question lists a bunch of tools and asks about more tools, some that are more flexible to use given your new situation with people working remotely. How about turning the problem on its head and think about improving the interactions between people? At ...


3

A few additional suggestions that we've tried with some success: To specify seating order, you can do things like: have everyone roll dice (slack has a D&D dice roller app, use /roll d100 to get a good dynamic range) have everyone say their favorite color then go in spectral order choose the first person by something lighthearted like oldest car, or ...


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