Agile Development: Balancing Individualism and Teamwork


News: Agile Development: Balancing Individualism and Teamwork

  1. The success of an Agile project depends on getting the right people on board and working as a team. Now the question is how the individualism and team work go side by side in an agile team. How much both matters and what drives more towards the success of the project and which should be rated more in terms of performance of the team members. Lets have a look at the different perspectives, problems and how we can reach out to solve these. As very well stated : "There is more to building a team than buying new uniforms." - Bryce's Law Consider a team in an agile project where there are people of different experience, age, technical skills and motivations working together towards the success of the project. Lets see what all members have the different perspectives towards it, where the problems start and how the conflicts come into picture. The discrepancy starts when the motivation, expectation, recognition starts contradicting. Scrum Master/Technical Arch: Articulates the goals, give directions, set standards and processes with team and resolve team issues. Should work towards success, he has the responsibility to make it happen. Freshers: Freshers, usually over looked by the team, mostly dependent on other team members. And usually agree with what senior team members tell them to do or to follow. The problem starts when the senior not actively helping out the fresher developers and prefer to do their own job. Usually, the freshers stay quiet thinking of not to irritate/dishonor any senior developer or not to do anything against them because they are the people who will judge them. If senior people starts looking from individual perspective by just doing their job and not looking from team perspective as of thinking of enabling the team and empowering the freshers and help them to get up to the speed etc. do affect the team dynamics. Developers: The real problem starts with the majority of these kind of people working together. How to make all of them work together? You can make process and expectations from all to work together. But how can you change the person's own preference of individualism over team work and vice versa. How will it affect the dynamics of the team and over all the outcome of the goal. In other terms, if there are no conflicts with in the team, does it mean the things are going to its best or there are some real hidden issues or politics. Lets say all are capable of working as an individual because that is why you have got the right people on board. There are different kind of people working together here. a) Capable and believe in team work: These are kind of people who really can do the job and believe to work as a team, taking other together and thinking of achieving the goal. b) Not capable but believe in team work: These kind of people do the team work to over come or hide their in capability to do the task and actively shout for team work so that others help to do the job. Job should be get done whatever way. c) Capable but don't like to work in team: These are kind of people who are capable but don't like to work as a team, who prefer to do the job assigned to them. They are hard to reach and would do others things of their own for the visibility beyond the team also. d) Not capable and don't work in team also: It means you don't have the right people on board. Assuming that we have right people on board, the question is: Who are the right people among "a" and "c"? How it affect the team dynamics? How does it matters to the success of the project? How does it matter to the whole team? Management: Won't like to interfere if the things are going fine. Let the lead and the team handle these issues. And by the time the news reach them it is already too late, damage is already done. Now, what the management can do to resolve such kind of conflicts. And in real terms does the management any how do reach up to these level of conflicts or personal preferences. The point for the management is that whether you did the job assigned to you and what else you did for the visibility beyond the job assigned. At the end if no one would care what the dynamics you had with the team then how to recognize the efforts put the other people in building up the right team. In ideal cases "Recognize individual achievement but reward on a team basis as opposed to an individual basis.". To handle such things in better way the whole team should take it up to the team level first, by having frequent meetings or even one on one with scrum master for such things and talk about what can be improved to work as a team. And in terms of recognition, someone should always take into account the people you have worked with. You can definitely be a good developer but it doesn't imply that you are a good team player. And until unless that recognition is given, it is hard to continue on that path because people's personal preference start changing once the team dynamics changes in that respect. These things decide the work culture you are part of and how you can live it to the true spirits. There are cases in business where you prefer individualism but certainly you can achieve much more as a team. Even at organization level, you should not encourage rugged individualism, in some way it may send the wrong signal to people. There is no straight answer to this because your business depends on both. And there is no right or wrong answer for it, whatever works for the business. But definitely there should be good mix of both individuality and team work to make it success and the right emphasis on which works well.

    Threaded Messages (10)

  2. The team myth[ Go to top ]

    "The success of an Agile project depends on getting the right people on board and working as a team." - As the late George Carlin would have put it: BULLSHIT! You don't have to be a team player to deliver and present your results of an iteration. It is up to a "manager", "project lead" or "scrum master" to figure out which people are capable of doing what in what amount of time. And it is up to him or her to define the metrics that determine if a result is ok or at least acceptable. The worst thing that can happen to project is an incompetent or inflexible project lead.
  3. Re: The team myth[ Go to top ]

    You don't have to be a team player to deliver and present your results of an iteration.
    If you were the only person in your team yes. But unfortunately not all companies/teams have this liberty. That said I am confused what the original article is trying to convey
  4. Re: The team myth[ Go to top ]

    You don't have to be a team player to deliver and present your results of an iteration.

    If you were the only person in your team yes. But unfortunately not all companies/teams have this liberty. That said I am confused what the original article is trying to convey
    Depends on how you define a team player. I've worked with plenty of people who delivered results as part of a team who I would not call team plyaers. There are plenty of prima donnas out there, and when they are actually good enough to justify their attitudes teams will generally accept them. I personally would like to fill my teams with these people. You can get super results from them if you manage their egos. Getting super results from average people is like getting water from a stone.
  5. Re: The team myth[ Go to top ]

    If you were the only person in your team yes. But unfortunately not all companies/teams have this liberty. That said I am confused what the original article is trying to convey
    No, a team player is someone, who will (a) deliver and function best as part of a team and who (b) "passes the ball". A team can consist of and work well with a lot of people who are not team players at all. As an example take baseball (some would disagree of course) where it is totally irrelevant if the pitcher is a "team player". Or soccer: Some of the best soccer players of all time were no team players at all (Maradonna, Gerd Müller, ...) , yet you would crave to have them on your team nonetheless. And it is much the same with software development.
  6. The team myth[ Go to top ]

    It's the standard HR question that always makes me smile - "Give an example of a time when you've demonstrated that you're a team player". The thing is I'm not sure team work is particularly relevant to software development. Some aspects of team work are vital:- Commutincation, resepct, encouragement, critism, commitment to a common goal etc, but I believe team work is much more than this. When playing football (soccer), you need to do all this and more. As an attacker, I might sacrifice my position to draw a defender greating a gap for my team mate to run through on goal. As a left back, I might see an opportunity to attack down the wing, but cannot do so unless I trust a midfielder will cover my place if things go wrong. These things have to happen intuitively, but I can't see the parallels on a software project - the dba doesn't suddently decide to have a go at web design. To reiterate, not team should suffer a jobs worth, who won't talk to anyone, is reluctant to step outside his normal role and won't share knowledge, but providing team members have the necessary skills, share relevant information at the appropriate times and above all treat each other with respect I don't see a problem. I just don't think that's sufficent to be called team work.
  7. The team myth[ Go to top ]

    Sorry to jump in a bit late, was away. Baseball and Soccer, I thought why not Cricket. There are so many examples that shows what happened to teams because of not having the right balance between individualism and team work. One of the examples has been IPL ( 2008. The deccan chargers ( squad, as an individual have performed extra ordinary through their career, have the capability to win the match single handedly and was best team on paper but still at the end managed to hardly win a single match in the whole tournament. If we talk about the Software Development(much more critical in an Agile project), think of different type of teams having members: a) Masters of All: All the team members are experts in what they do. Now certainly they can do the job and that is why we call them masters. But depends they will be able to meet the goals if we make then work in a team. Trust me it is toughest job to make them work in a team and to satisfy their eggos. The above example says it all. b) Jack of All: Certainly need to work as a team if they want to do the job and meet the goals. No other option. c) Mix of both: As you have the mix, you know somehow the job will be done. But here how to manage the team dynamics to effectively and efficiently complete it. Should it be totally driven by Master or make the low level people reach to masters or let the low level people keep making the mistakes or think of it as a team responsibility and put the eggos/individualism aside, start trusting other members and work as a team. Now the other thing is think in terms of management people/Lead and at organization level. For the success or failure of the project whom to recognize/blame. Is it those people who did/not perform well or those who did/not play good team member. Ideal speaking just say that it is team responsibility. No straight answer, but the point is to keep a healthy balance between the two.
  8. Re: The team myth[ Go to top ]

    A lot of good points being made here, I guess it all comes down to the individuals on your team, and your current vantage point. A manager is going to have a different opinion than a developer when reading this thread. I am having a hard time classifying my coworkers in the categories put forth by the author, however we all get managed by the same person, and when the code intersects, we work together to bridge the gap, and we tend to work harder around that time to ensure that we aren't leaving the other guy waiting when this happens. One thing I have noticed, however, is that the original 3 members of the team (I was the 4th to join of now 12 people) have defined the culture of the group for all those that have joined to conform to.
  9. Is this news?[ Go to top ]

  10. What does this has got to do with Java?
  11. What has this got to do with Java[ Go to top ]

    Sweet FA, but at least not another hoax security alert or YetAnotherAPI release 0.3