Hot answers tagged

21

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


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

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

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


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

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

Even If It's Not Trolling, It's a Recipe for Creating Disastrous Outcomes This is (at best) tangentially on topic as a project management question, and may possibly be trolling. Even assuming good intentions, it's hard to see how the prevailing literature and extant best practices don't answer your question. Assuming you are a project manager, and looking at ...


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

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

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

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

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

A good project manager is a good facilitator. Someone who can guide healthy conversations and help the team get to, remember and follow through on their commitments and decisions. Taking a people focus I'd advise two key areas: 1- Who does what, by when: At the very basic, that's all project management is, tracking who is doing what and when it should be ...


4

What if the majority are wrong It can happen of course. I would expect any issues that arise from a wrong decision to be raised and discussed at retrospectives. Hopefully the team would then recognise the error it had made and adjust. Why chose technical correctness over people correctness Why indeed. The team should discuss the pros and cons of the ...


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


4

It sounds like it would be a good time to have a 'Retrospective of Retrospectives'. Start with a reminder of the purpose of having a retrospective and what the team is trying to get out of them. Review how the team has had retrospectives in the past, what went well, what can be improved etc. It may be the format of the meetings that is the problem, and ...


4

This is a change management issue. Unfortunately, successful management of change - particularly negative change like what your organization is going through - has to start well in advance of the change. If this hasn't been done then you are looking at picking up the pieces. And you can't pick up the pieces by yourself. The key is getting several levels of ...


4

Yes, put them together. There is only one way the teams will ever get shared knowledge, by sharing. It's also the only way you'll ever get to continuous integration/ deployment. Example: In a previous organization, we eliminated the HR job of QA. All the existing QA people were moved over to a development path. They did not share the same skills as the ...


4

I'm usually in the opposite position - when developers want to do so much refactoring that it starts to encroach on delivering business value. That being said, refactoring is a process like any other, and I have had teams fearing process change. It's about convincing the team to come with you. The link that you have pasted tells your team why refactoring is ...


4

Find someone else. In agile it's all about team performance, not individual performance. Adding an individual to the team who doesn't fit in can really affect the rest of the team. If you can choose between a technical rockstar and a teamplayer (with just enough technical skills to do the job right), it's an easy choice to make. Be very explicit about ...


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