29

I'm working as a project leader in a team of 5 developers and myself and taking the role of analyst. Within the company, we've been applying the agile principles for several years.

Some of the principles I value most are self-organization and self-improvement, probably because I did work in a strong hierarchical environment before where higher levels were thinking for you.

But my team doesn't seem to be bothered too much about it. They like the way they are working. Missing deadlines, going over budget, poor quality, it is always caused by others, solutions are never searched in the team itself. Retrospectives often lead to endless discussions about blaming others but introspection on our own team-performance is lacking. In bad days I think that my developers are just spoiled kids not remembering how it was in the old "waterfall" times where developers were just code monkeys. But then I sound as an old man, isn't it.

My first reaction is to switch in micro-management mode which I know is probably the worst solution, but are there better ways to encourage my team to be more organized?

Improve this question
2
  • 1
    As this topic has been migrated from progSE a few hours ago, worth to remember you can also find great insights within the 'Motivation' tag here in PMSE: pm.stackexchange.com/questions/tagged/motivation
    – Tiago Cardoso
    Commented Dec 15, 2011 at 11:48
  • Is your team, and you, proud of product that you build? I have similar situation and put a little blame on it (not because blaming others is cool&easy).
    – Bartek Kobyłecki
    Commented Dec 15, 2011 at 12:27

10 Answers 10

Reset to default
10

Ownership

If a programmer takes ownership of a project, they desire to see it succeed--they look for ways to improve it and make it better--they try to tackle the tough problems.

It sounds like the problems you are having are stemming from a lack of ownership of the project. When this happens, a developer will blame others, not care about the project, not work well with other team-mates, not communicate, etc.

Ultimately, you'll need to get the team to have a sense of ownership in the project.

A related post about team ownership.

Improve this answer
3
  • 2
    I like the theme of Ownership but don't necessarily agree with what you are saying about a single person taking responsibility for a given "aspect". This is considered a bad thing in Agile development, where all developers should be as familiar with as much of the application as possible. Certainly not all people have the same strengths, however I should be able to assign database related tasks to any developer in the team.
    – maple_shaft
    Commented Dec 14, 2011 at 20:14
  • 1
    @maple_shaft Yeah, I think you're right. I ripped that junk out. Also, I found an interesting website about ownership. Although geared towards a virtual team, I think it's universally applicable.
    – Richard
    Commented Dec 14, 2011 at 20:22
  • I think the fact that you were introspective and reconsidered your answer enough to edit it demonstrates EXACTLY the kind of attitude that the OP is lacking on his team, and the kind of person that I like to work with ;-)
    – maple_shaft
    Commented Dec 14, 2011 at 20:26
9

You're on the team too. If you can see specific issues, why not bring them up? If you want others to be introspective, show them how by being introspective yourself. It's a little ironic to complain about how others complain about others.

The fact is, there are a lot of factors outside a software development team's control. Recognizing what those are and bringing them to the surface is important. However, the next step is to identify constructive ways to mitigate those factors. For example, if someone you need input from is unreliable, move tasks that involve them up in the schedule and follow up with them more than normal. People can deal with things outside their control if they know they've done everything they can.

Improve this answer
7

Whatever you do, do not micromanage!

That is the single worst thing you could do. You will put a lot of stress on them, on yourself, you will kill the potential productivity of the team, and you make yourself the bottleneck on the team.

I am not saying your team is a bunch of whiny kids, and I certainly am not saying that they are useless, but my experience is that about 4 of 5 developers in the field today are not self-motivating, self-starting and need strong leadership and guidance to be productive.

They are likely not feeling strong guidance on requirements or they are lacking technical leadership or both. The fact of the matter is that they are blaming others because a leader isn't present to take charge of the situation and none of them are willing or ready to step up and assume that role.

A lot of it is human nature too. A strong individual with a penchant for growth is introspective and can admit his/her faults and consider how to improve them. A weak person does nothing and blames outside forces out of their control for all of their failings.

You need a stronger team, or a really strong leader.

Improve this answer
5

There are no consequences for not performing in your organization, so what do you expect? There can be valid reasons for a project being late. They should be presented to the leader when they are recognized, so you can do something about it before it is too late.

The leader has to know what is going on and be able to spot excuses. If you have too many execuses for not getting your work done, then maybe the underperforming developer and your team need to part ways.

Agile has nothing to do with it. If this is making their job more enjoyable than the 'waterfall days', then they should be motivated to work harder/strive to be improve.

Look for those doing the right things and acknowledge it. No need for "Employye of the Week" posters or stickers on their cubicles. Get your work done; good things happen. Don't get your work done; bad things happen. This is life.

Improve this answer
1
  • You said just the right word... 'consequence'. Without it, changes in behaviour will have to be magnanimous on the part of the offender.
    – JoeGeeky
    Commented Dec 17, 2011 at 23:50
2

I would start with one-on-one meetings with the team members individually. Highlight concrete examples of where the blame rests with the member and not on the external sources. And in general discuss any areas where there is opportunity for personal growth.

Quality issues are a great example. These should lead right back to the contributor who created the defect.

Overall team goals are not necessarily their concern (in a healthier environment they should be, but the blame game makes it your problem, not theirs). Budget/deadline issues ultimately fall on the project manager. Again, these would need to be related back to specific areas of concern with the individual and how they contributed to the problem (such as underestimating a task, lost productivity, impact of defects, etc).

Improve this answer
2

Create an incentive structure that rewards them for solving problems. Then give them the responsibility and opportunity to succeed (or fail).

Improve this answer
2

There's a great for programmers, called The Clean Coder. It's very motivating, and calls for taking responsibility for what you write.

Improve this answer
1
  • This is a great book, but I'm not sure giving the devs reading assignments is really a solution. With that said, I wish more devs embraced the ethics of this author.
    – JoeGeeky
    Commented Dec 17, 2011 at 23:53
1

I think you may want to take a look at this question, really similar. It does not cover the part of considering you're already in a wrong situation, but more about the motivation on the self-improvement.

https://productivity.stackexchange.com/questions/1206/how-to-motivate-people-to-self-improve-themselves

Improve this answer
0

Thank you for the great answers.

I have taken a number of actions based on them:

  • I'm considering my contribution to the team and how I can improve
  • I appointed a new lead developer bringing lot's of experience into the team
  • I scheduled a one-to-one meetings with the team members.
Improve this answer
0

Try http://www.openagile.com Should help with teamwork and general problem solving skills by promoting repeated cycles of Action-Reflection-Learning-Planning.

Also check out "Software for your Head"

http://liveingreatness.com/the-core-protocols.html

  • Team = Product (your product has whatever qualities your team has)
  • Decider (move a group immediately and unanimously towards results)
  • Resolution (how to get unanimous decisions in a team)
  • Perfection Game (replace negative feedback with positive feedback)
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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