Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Some team members just wait until the stories they are most likely to work on will be discussed and only then they participate. Otherwise they just play with their phone and don't listen.

In some way I understand this position. Why listen to a discussion about a feature you are unlikely to help develop in the Sprint or ever?

What do you think we should do?

share|improve this question
9  
How large is this team? –  JeffO Feb 10 at 15:39
8  
@JeffO hit the nail on the head - this is a classical problem of oversized team. Oversized team = undersized individual authority/responsibilities = undersized individual engagement. A right sized team will mean that everything you guys talk about effects everyone in the room. Alternatively you're siloing responsibilities too much - why listen to a discusion about a feature you are unlikely to help with? A right sized team which doesn't silo responsibilities should have everyone likely to work on every feature. –  Jimmy Hoffa Feb 10 at 16:37
7  
Phones off, with no exceptions. Simple meeting common sense. –  user1019696 Feb 10 at 19:38
4  
@user1019696 to be fair, I could get a phone call from my wife that my kid busted his leg at any time. There's a big difference between "phones off" and "don't be ****ing with your phone in the middle of a meeting, because it's simply disrespectful." –  Jimmy Hoffa Feb 11 at 11:00
3  
@jwenting you speak of an era when there were company secretaries, there's been no such person at a company I've worked for years - they'd have nothing to do. And no, it can't wait. Especially not for work, sorry but family > work. That said, I maybe get a call in the middle of 1 in 30 or 40 meetings (maybe??) of which I probably answer 1 in 30 or 40... It's not hard not to be a jerk with your phone. If people need them disabled or removed from their persons to avoid being a jerk, maybe that person's just a jerk. –  Jimmy Hoffa Feb 11 at 11:13

5 Answers 5

Stop code ownership. Make it equally likely for anyone in a team to work on any given task.

There will almost certainly be some kick-back on that, because developers get comfortable with a specific area of code, and with other people not looking over their shoulders. Also, management will see a problem with work taking longer than it might normally, because there's always a learning curve.

But it really is in everyone's best interests. Being indispensable is a two-edged sword. It starts becoming more difficult to get time off, in the evening, at weekends or to take holidays. And code-ownership is bad for a company because, when someone leaves, it costs more time than you've ever saved on small bits of knowledge transfer.

share|improve this answer
4  
+1 Absolutely. There's a false impression of efficiency when you think coders are just another part of the assembly line and then wonder why a project gets set back because one of the cogs needs to be replaced. –  JeffO Feb 10 at 15:26
3  
@JeffO which is pretty much the standard among software development company management in my experience, considering developers to be identical parts in a machine that can be instantly swapped out for another carbon unit... –  jwenting Feb 10 at 15:53
3  
@jwenting which makes them perfectly suitable to be outsourced, too. I don't see why developers assist in this attitude. –  GrandmasterB Feb 10 at 16:33
1  
@jwenting Thats the point of agile. To change this kind of view on things. –  Euphoric Feb 10 at 17:10
    
@Euphoric in my experience the end result is the reverse, managers seeing people even more as assets that can be just swapped out on the fly, like requirements... –  jwenting Feb 11 at 7:30

Their disinterest is just a symptom. The problem is you're not distributing work evenly to all your team members. Ideally every team member should be picking up any new ticket not restricted to certain project areas.

share|improve this answer
3  
That's nice in theory. In practice, especially on large projects, the system can be large enough that it's impractical for every team member to have enough knowledge of every part of it to be productive when working on it. –  jwenting Feb 10 at 15:11
    
@jwenting - it just seems like this team is very certain they will never be required to work on other parts. Although one person can't know everything, that doesn't mean they should learn as little as possible. –  JeffO Feb 10 at 15:23
    
@JeffO true, but they can't be expected to be able to actively participate in planning things for areas they have no knowledge of. Listen and learn, but keep your mouth shut. And maybe use your cellphone to make some photos of the planning board :) –  jwenting Feb 10 at 15:51
1  
@jwenting in practice on large projects you need to distribute the work more! It is not that everyone has the same knowledge, but they're equally likely to work on the any particular area. Allowing excuses makes the team members more likely not to adopt new areas. –  Dave Hillier Feb 10 at 21:12

Do you invite the right people to your meetings? If you've split the system into areas of responsibility for subteams, why invite all subteams to every meeting?
For example if you have a frontend team, and a backend team, keep the planning sessions for frontend work to members of the frontend team. Maybe invite someone from the backend team as a liaison in case a task crosses team boundaries (but if that happens frequently, you may wish to reevaluate the split of responsibilities between your teams).
Ideally everyone should work on everything, but in reality that's often not practical unless your system is really small and simple, resulting in everyone knowing every part of it thoroughly. In practice of course many systems are large enough that to expect every member of your organisation to have enough knowledge of a planned task to be able to give valid input during planning sessions (let alone be equally productive working on every part of the system) is just not realistic.

share|improve this answer

What is your sprint duration?

Longer sprint durations lead to

  • More work to plan in the sprint, which leads to
  • Longer planning meetings, which leads to
  • Higher difficulty for team members to stay focused, ...
  • Team members get bored

So if if your sprint duration is more than two weeks, try working in shorter sprints.

If it is difficult to get the stakeholders to commit to shorter sprints, then you could skip some of the formal meetings, e.g. only have the sprint review after every 2 sprints, instead of after every sprint.

share|improve this answer

Sounds like a motivational problem - why don't some people care about the project they're working on? Maybe its because the team is split into the 'organisers' and the 'left outs'.

So involve everyone, instead of 1 or 2 people taking charge of the planning sessions, you engage everyone - make different people take charge of each session, preferably make different people take charge during the session. Rotate it all around. I know this can seem difficult because there's always someone who wants to fuss about and organise everybody but they are the problem here.

Here's an idea: when planning choose a person at random to take charge of each story. At random. Record who was responsible for the planning of it too, so next sprint you can tell if they did a good job of getting a good consensus of estimates and task split. That'll make them pay attention, and will also give them a reason to engage with the project.

Remember, the problem isn't them, its you and the way your planning sessions are done. So when someone else takes over a story plan, they get to chose how to go about it there should be official way of proceeding. (ie don't sit back and continue to force your organisation upon them by proxy)

share|improve this answer
    
Good ideas. Hopefully people won't see this as waste of their time. –  Eugene Feb 11 at 10:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.