We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

28

I have a set of five core principles that drive my project management/ management philosophy. I've had them for many years, even predating my adoption of agile. They are: People, not projects: If you focus on the team, the team will do better. Better team, is a better product. I spend every day of my job trying to make myself obsolete by enabling the team ...


19

I am dealing with a similar situation; previous teams merged into one with subsequent respecifying of roles and grades. Some legacy political forces were in play. As the Scrum Master you are the master-servant of the team including coaching. Many agile commentators forget the master part but the business is paying you to impose your will upon the team to ...


15

In trying to avoid duplicating the excellent comments in other answers, I have thought about some of the mistakes I have made, and offer the following - which probably says more about my own flaws than anything else! Check your facts - never assume. It's amazing how often your assumptions will be wrong - especially when you "think" someone is doing ...


15

When Engineering Problems Become Project Management Problems One of the team members turns in code that is almost always bloated and inefficient, even though it technically works (although, from time to time it doesn't). This is only peripherally a project management issue. It is actually an engineering issue, but it bleeds into project management ...


12

As the saying goes, your team is as strong as your weakest link. A high performing team is about collaboration and communication and a sense of collective success and failure. And an individual who "prefers to work alone" can disrupt that process and inhibit that teaming dynamic you want. HOWEVER, leaders of teams also know that the team is made up of ...


12

I'm going to assume that you are running one of the versions of Scrum in which there is both a "story point" estimation, done by the entire team, and an "hours estimation" done by the individual assigned the work. If it's not, and your only estimation is the story point one, this issue shouldn't arise because the estimation should be done by concensus of the ...


11

Roles and Responsibilities for Team Composition This is an interesting question, because it addresses some of the subtleties of self-organization with agile frameworks. In particular, it highlights the differences between authority and influence. Scrum Team Members are responsible for identifying impediments (e.g. the team doesn't have sufficient expertise ...


9

Some quick ones off the top of my head. Understand the state your team is in. Mature/self organizing teams - Focus on individual relationships and generally just get out of the way. Stable/improving teams - Give them options to learn whatever team skills they are missing to get to the "Mature" state. Set constraints but pretty much let them try different (...


9

Don't do this. Speaking as a developer, this sounds great. We get to rewrite that horrible old spaghetti code from scratch! We get to paid to learn a new language! There's a mandate for quality, so we can actually get the time needed to write good code! ...Oh, and there's the fact that this project will take a year or five. Speaking from a business ...


8

David was right on the spot when me wrote that the output matters (delivered values), so I have nothing else to share than a story. The company I'm working for have several sites, and I'd like to write about two specific sites: one, where the discussions can be as long as they needed and the other where the sponsors behave as you described. Both sides are ...


8

This can be challenging, it is always possible that someone tests well but can't perform in the "real world". In the past when I've interviewed candidates I've prioritized as follows: Personality. You can always train a new hire to become technically competent. You can't ever train them to be a decent human being if they aren't one already. Under this ...


8

Break tasks into smaller details. When this individual gives you an outrageous estimate ask them more details about it. For example, if the task is to Test Feature X, it might involve setting up environment Y, going through cases Z, etc. Then ask them to estimate on each sub-point. You will be able to drill down and ask things like "Does it really take 2 ...


8

TL; DR Personality conflicts and process diseconomies are clouding the real issue. Tracking the proper performance metrics will improve your overall process and provide guidance for addressing issues of team composition. Your Problem Isn't Estimates [O]ur SQA resource...overestimates everything. So what? If your team is using planning poker, or any ...


8

Parts of your question smack more of a workplace issue than a Project Management issue, but I'll answer what I can. Is this common in Scrum teams? Doesn't really have anything to do with Scrum. What you describe above, assuming the problem actually is as you describe (neither exaggerated nor misunderstood/misrepresented), is an issue with the workplace, ...


8

David tackled the psychological side pretty well. I'd like to offer a couple of technical solutions. Test Driven Development: If you have to write the test, before writing the code, then you're going to have better code. It's been proven out thousands of times in the last twenty years. Pair Programming/ Mob Programming: Another, proven out too many times ...


7

welcome to PMSE! That's a good question, and I'd like to share my top 3, in despite of my low experience in comparison to our more seasoned colleagues... I'll try to focus on Manager's top three instead of Leader's top three (which would make another good question). Disclosure: All other answers are quite great as well, so I'll take use of it and, instead ...


7

I would recommend https://trello.com/ Have been using it for tracking activities of my team ( size - 10 testers) It is straightforward, not too clutter or complexity , is free and should tick the boxes from your question


7

I've three games to propose. One. The first one is really easy to play and the objective is to explain the team auto-organization. Follow this steps: Organize a room with chairs and tables causally arranged Form teams composed by two members One is the manager and one is the worker The manager can give the following commands: turn left, turn right, step ...


7

Cowboy coders generally come from one of two places, either an organization that has promoted quick development (usually start ups) or from lack of experience. Coming from an organization that transitioned from a start up and moved on where a large organization bought the company and then hired a consultant to kick our butt, I have experience with a group ...


7

Human performance is complex but one thing is certain: we are not very reliable. There is a lot of material out there to study regarding this topic. There are theories around motivation, theories around the performance curve, personalities, behavior, etc. Too much material to post here. One area I will focus on in my answer is the performance curve. ...


6

There is not tremendous evidence out there that team building exercises actually do anything. So while your team is going through its first steps in its evolution, spending time and money on extra activities will likely have no value in terms of bonding faster, going through the first stages of team development, or having any real change in performance. ...


6

Development is not assembly line work. Some developers take quite a bit longer to develop code than others. It is possible that your developer is, while competent, one who takes longer to develop than others. Unless you are his manager, if he is goofing off or not should not be your concern. Rather you should be concerned that he is meeting resource ...


6

Agile, and in particular Scrum, is about creating a self-managed and self-organized team. Even if in a context different than software development (self-managing teams in a telecommunications company), this paper shows that self-managing teams are more effective than comparable traditionally managed groups that perform the same type of work. Some months ...


6

Here is the thing - the rockstar is rarely a good programmer. Most programmers which are great technically understand the need of teamwork. It is a core part of the job, something you need to understand if you want to have any semblance of true skill on the field. More often than not you'll find yourself working alongside other people, sharing results, ...


5

This is an organic risk of projects, i.e., it is always there, it has always been there, and it will always be there. Trying to dissect this and calculate some type of contingency or buffer is a HUGE waste of your time. The probabilistic distribution of any task is created by a plethora of random variables that can both favorably and unfavorably affect ...


5

This is an opportunity to educate your sponsor. 100% FTE is really somewhere between 45% to maybe 75% truly productive where the balance is unproductive to include socializing amongst other things. 100% truly productive is not achievable and likely detrimental to performance. There is value in socializing but you need to make sure it does not get out of hand....


5

Firstly, the interview as a predictor of future performance has a very low validity. Even structured, it is not helpful or very useful. Testing for cognitive ability and conducting "job tests" are two of the leading indicators of performance, with a validity approaching or around r0.5 (Hunter & Hunter 1984). So creating assignments or test questions ...


5

Instead of explaining, let them experience it! Use one of the many team building games where they will understand during the game that they need to cooperate and organise. Here a typical example: create small groups of 2-5 people have 3-4 such groups give each team an envelope containing a puzzle (20 pieces maybe or maybe some small lego set, etc.) tell ...


5

Your team is the benchmark. If last week you weren't doing Test-Driven-Development, but you all agreed that was something you wanted to change for the next go-round, and you did...there you go. If you decided to give it a go - but didn't - well, you didn't follow through...not the end of the world, but could probably do with some follow-through and ...


5

Help the team to move from storming to norming, see stages of group development. You can achieve this by: Present your observations to the team. Take care that you talk about observations and not interpretation. Highlight the advantages you could achieve if you change your behaviour, e.g. get better results by taking more ideas into account, speed up ...


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