Hot answers tagged

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

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

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


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


9

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


9

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


9

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


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

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

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

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


7

Notwithstanding my comment about the proper exchange, you are dealing with a normal problem of 1) prediction of future performance, and 2) how to attract good employees. The first problem is a huge problem. Predictive indicators that we tend to use are not that predictive. One of them is experience. Experience is one of the most widely used criterion, ...


6

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


6

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


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

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

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

Building on Marcin's response. The Guerilla guide to interviewing (latest version is best!) is very useful. It helped me a lot when I first had to evaluate technical staff for hiring few years ago during an expansion spurt (I was hiring electronics development and embedded programming, not just general purpose coders for enterprise software) I'm not 100%...


5

Formal Definitions At this time, there are no formal definitions of maturity across agile methodologies. However, the Capability Maturity Model Integration (CMMI) framework uses five levels to define process maturity: Level 1 - Initial (Chaotic) Level 2 - Repeatable Level 3 - Defined Level 4 - Managed Level 5 - Optimizing If you're looking for a formal ...


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


5

First of all, with 8-9 developers, each having 1-3 impediments, it seems like the team is not really working together towards the same goal, but working very efficiently towards several goals. (and thereby losing real productivity). Second, the Daily scrum is the last responsible moment to raise an impediment, but nothing prevents the team from quickly ...


5

Summary They are mostly very talented individuals, but how can you use the tools Agile offers to help them have their freedom but also work with others? You are conflating things which are not orthogonal. Agile frameworks are based on teamwork and collaboration, so you need to consciously select for that in your team composition even more rigorously than ...


5

I see two problems here. our salesman likes to promise everything to everybody This is a clear example of siloing. The salesman is putting the Sales department's goals before the business's goals. That needs to stop. There are various ways you could approach this. The simplest (and what I would suggest trying first) being simply approaching the salesman ...


4

I recommend the Agile/Scrum approach You can slice this many different ways but I recommend the Agile/Scrum approach: Don't have any sub-teams within the dev team. Team members may have deep expertise in one of the areas (Design, Dev, QA). However, let them make a team commitment to completing the work and operate as a cross-functional team. This means ...


4

I strongly support J's suggestion: you have a delicate situation, and write things down might help a lot down the road. What you might be looking for is a RACI Matrix where you need to specify two very distinct roles your mate will cover: client / product owner and developer. Also, this diagram will make things easier to understand who should make the ...


4

Create stable scrum teams of about 5 to 9 people per team To create stable scrum teams, follow these recommendations from Roman Pichler: First, carefully consider who should be on the Scrum team. Find the right individuals to play the product owner, ScrumMaster and team role... Having the right individuals on board is most likely the biggest success factor ...


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