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


11

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

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

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

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


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

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

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

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

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

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

As a Scrum Master I always like to promote swarming: The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done. Swarming works ...


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


5

TL;DR The canonically-correct solution is to put someone with business analysis skills onto the Scrum Team in a Developer role, and then cross-train the whole Scrum Team. Cross-pollination of skills enhances the capabilities of the Scrum Team and the Developers, and builds T-shaped people. Including someone skilled in business analysis on the Scrum Team also ...


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


4

Have you clearly communicated your problems with this person? I know I've assumed many times in the past that someone "just doesn't get it" but they really didn't understand what was important to me because it wasn't clearly communicated back to them. If you do confront them about their communication style I would make sure to use a lot of "When you [their ...


4

"Collective code ownership" does not mean that everyone on the team gets a say on every line of code that's written. The code is still written by individuals (unless you're pair programming), and they are making the decisions they feel are best at the time. The point is that no individual "owns" a section of the code. If John wrote the Foo module, and for ...


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