Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
Currently we are facing some problems with our Team Lead regarding work assignment hierarchy and responsibility of work done. It is generally seen if some targets are not met by the team the Team Lead openly starts blaming the team and sometimes pin-points some of the developers. Further during the allocation of work to the developers the Team Lead does not properly explains the work to be done but expects us to complete it completely.
The worst part is that the Project Manager and Team Lead are real cousins and the Project Manager always takes the Team Lead side when such issues are put up to him by the developers.
Please guide what best can be done by the developers to make a healthy work environment.
Thanks in advance.
This is double sided, and very objective. It might depend souly on what kind of person the Team Lead is, and if they are open for discussion/questions.
The team lead should be openly addressed about this, BUT also, if a developer is unsure about what to do they should ask.
It never hurts to ask questions, you will be amazed at what you can learn.
Well personal relationships should not not be related with professional life. The developers should first of all organize a meeting with team lead and put forward their issues in a healthy and explanatory way. Also keep in loop the Project Manager with your views. Do not wait for anybody to make a healthy environment for you... start yourself in this direction.
One should be able to adapt to various environments and culture that is different in different organization. Always be with the flow.
I'm not sure that you can avoid conflict! The challenge is deciding what to do so everyone can learn and not too many people get hurt.
A well-run team should run itself. That is to say, the team lead's role should be to get a good framework in place so the team can decide on priorities, techniques, methodologies and even process by talking together.
So good managers will ask team members "OK, so what would you do?" They'll then get the appropriate support put in place so that can happen.
I'd suggest that as a group you
Regularly get together (perhaps weekly) to review progress and learn from mistakes made in implementation.
Make sure that all tasks are given to the team as a whole, not to individual developers. Everyone should know the high-level summary of a job.
Get together daily to very quickly summarise progress. Keep this meeting limited to 10 minutes.
In these meetings it's best to avoid blaming people. Blame the code instead, or the process, but don't get personal.
And if your company culture allows it, try reading up on some of the literature around agile project management: there are many parts of that process that are designed to avoid conflict of this nature. However, it can be quite a hard shift for some organisations to devolve quite so much power to developers...
If possible, schedule a meeting with the Project Manager and Team Lead. Openly discuss the issues in a mature and positive light. Tell the Team Lead what you do like (as a group), and tell him what you think can be done to improve quality, expectations, deadlines, etc. If critical requirements are habitually missing, let him know that. Although his cousin is the Project Manager, his answers may be guarded and he could get defensive no matter what the real circumstances are.
Ultimately, in my opinion, the PM/TL relation is a formula for disaster. If the problem is the Team Lead, and the Project Manager is part of that problem, then the next logical step is to go to the PM's boss.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I've been working on a CodeIgniter project with a friend of mine for almost a year now. We feel that our development process isn't as effective as we wanted to be, and currently we're not employing any software development methodologies. We're 2 man team, looking to have more people to work with us in the future, but we don't have enough people to start on scrum.
Right now, we're both working on this project on the side, would be nice to know which methodologies are best for us, to get our development going faster and more efficient.
Agile and Scrum won't make you faster or more efficient:
Since you tagged this with agile and scrum, I thought I'd mention this: neither agile nor Scrum has as its goal faster or more efficient development as you ask for in your question. In fact, changing to these approaches involves a significant learning curve, but if practiced well contributes toward very low defect rates, software that meets the customer's needs, and a development process that responds to changing requirements. Used long enough, Scrum can provide good data about roughly how much work a specific team can get done in a period of time.
Still, you might benefit from some practices:
All that said, there are a couple practices that may want to try:
Pair Programming and Test Driven Design (TDD)
Continuous Integration
TDD is not easy to learn, especially on your own. See if you can attend a CodeRetreat or similar event.
If you aren't already using a modern software change management tool (SCM) like Mercurial, git, or subversion, get one and learn how to use it.
Get regular feedback from "customer"
If you don't already know (you didn't say in your post), you might ask yourself who you are making the software for. Can you frequently and regularly demo it to that person and get feedback? Find out what they want next and put those items at the top of the backlog.
Try to make your product incrementally useful
Rather than making big product-wide changes, add small useful amounts of functionality. Your design will drift but if you have sufficient automated tests in place you can refactor as needed.
I'm curious why you say you don't have enough to do some form of scrum?
You're both on the team, one of you can own the process and the other or both of you can be the product owner. You do your daily scrum so you can know what each of you are doing - picking the work from the backlog you agreed to do. And as you add members you'll already have an established practice they can integrate into.
You can work in 2-4 week sprints, do sprint planning,review, and retrospective regardless of the number of members.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I realize that this is a subjective question, so I've marked it as a community wiki. I think that it is pretty specific to programming teams, though, so I've posted it here as opposed to somewhere else.
I'm leading a small game development team (four people) as a side project. We are a disjoint team, with everyone in different places, but we do have some of the mainstays of an organized team.
Source Control
Continuous Integration
Bug Tracking
Document Workspace
Regular Meetings
Calendar / Schedule
How do you keep your small, disjoint teams on-track? I tend to agree with Joel's opinion about when and how to micromanage and know that my team is motivated, but it can be easy to fall off-course when everyone isn't connected in a physical way and doesn't see what other people on the team are doing. Suggestions, feedback, or criticisms are welcome!
Edit: I'm managing the team; I'm not looking for automated tools or anything to do my job for me, just ideas for approach or process that might help everyone feel more "connected" and involved.
You need a Team Leader with specific skills.
Motivator: You have to keep your team Motivated. This is really hard to do, and requires a special personality. Without this skill, small teams like yours are hopeless.
1a. Request thoughtful answers to a controversial question and then after 7 minutes accept one of few answers and go on to something else. This shows that you take the long view and is highly motivating to your contributors
Intelligence: For small projects like this, it's best if the Team Leader knows something about everything. If he knows something about everything, everyone is going to follow him.
Objective: Remaining objective is very key.
Organized: You have to be the most organized out of everyone, because when things get chaotic, people run. And I would say in small projects, this is the skill that most Team Leaders lack.
I have been part of several small projects. I would guess that 90% of them fail. I would say it's primarily due to the Team Leader lacking in certain skills.
BTW. Good Luck. I couldn't be a Team leader. :)
Be a Leader: How to Change People Without Giving Offense or Arousing Resentment from "How To Win Friends and Influence People":
Begin with praise and honest appreciation.
Call attention to other people's mistakes indirectly.
Talk about your own mistakes first.
Ask questions instead of directly giving orders.
Let the other person save face.
Praise every improvement.
Give them a fine reputation to live up to.
Encourage them by making their faults seem easy to correct.
Make the other person happy about doing what you suggest.
Those are my suggestions for some helpful tactics, even if they are rather old as the book was written in 1936.
This is an interesting article about that very topic: Gaming the System.
A manager. Someone has to keep track of where folks are at and how their progress fits in the scope and time-line of the entire project. There isn't really a good way to automate this. It must be done by a human.
Edit When I worked for a game industry company, we always had to meet certain milestones to get payments from the publisher. As the manager you can break down each persons tasks into milestones as well. This way you can track the progress of each developer without bothering those who are on track with their features. It also makes it easier for the developer to know what their deadlines are in nice bite size pieces. If they are consultants, you can even pay them upon meeting their milestones. Money is great motivator ;) Another great motivator is to make all milestones open to the whole team. So if one person falls behind, others can jump in and help her meet it.
I've worked in large and small game development teams for many years and I think the most important thing you can keep in mind to hit milestones and stay on track is discipline.
Game Development seems to suffer immensely from the desire to add more and more features or focus too much energy in something that's just not that much of the final experience. Your best tool for keeping the team on track is the word "No"
So far I've been on the development end of this equation, and by personal preference rejected attempts to place me in a managerial position. Techniques I have observed are:
Set very, perhaps impossibly short deadlines. Developers will be so rushed to achieve the goals that they won't have time for any distractions. They won't have time for refactoring, cleaning up code, indenting, code review or anything else either, but as long as their code compiles they can reach the milestone and worry about debugging it later.
Have a technical project lead so dedicated to the project he'll crack the whip on all others until they produce maximum (visible) output. Also, he'll work lots of overtime and encourage others to do the same.
Weekly meetings, all hands. Some of the information exchanged about what other folks are doing and what they've learned can actually be useful.
Provide standardized equipment, software and development environments. They may be awkward to work with and developers will hate it, but at least they won't end up playing with their configuration when they could be coding.
Have a business-savvy administrative project lead who can keep customers off the developers' backs and filter requirements for them. Anytime a customer "helps" it delays progress by many hours.
Daily standup meetings done properly help a whole lot. If you keep it to:
1 what did you do yesterday?
2 what are you doing today?
3 what problems are you having?
it should remain quick and helpful. Keep in mind #3 is just to state it not to solve it. That is done after the meeting and is facilitated by the development manager or project manager.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
In the course of my career I've noticed that developers working on new functionality are, as a rule, more cheerful than these assigned to troubleshooting and fixing bugs.
Good tips on keeping business support a happy? Organising business support in the way that team's morale isn’t hurt?
If we start with the assumption that the reason for new function developers being happier is that they get to feel proactive or in control and the troubleshooters are reactive and pushed around by the users one answer comes to mind:
Create a model for those doing troubleshooting to fixes to generalise these from point fixes into broad, consistent fixes for a class of problem. This puts them in the situation of creating new code, even if not new functionality, and they get to think a problem through and anticipate and avoid problems rather than playing whack-a-mole.
In fast moving environments it may also be possible to rotate people through the job descriptions by have them follow their feature from new development into fix and realease and hopefully into version 2 of the feature.
Our organisation has a substantial amount of support work and we've got hit with this problem really hard. The motivation on support teams could dropping down exponentially over the time if you don't do it right.
The principles which worked for us were:
Choose the right people. Some people are happier doing new stuff. Some people are actually much more suited to a steady no-nonsense job. It means that you should have two teams - one for development and one for support. Developers only stay on a completed project until they pass their knowledge to the supporters.
Choose the right leader. Good organisation is make or break here. A good leader would help to organise good relationship with the product users and at the same time will care for his team.
Rotate. We try to keep the support people on the project for a period of less then 2 years and then move them to something new. This helps maintaining proper morale and ensure that their skills don't rust.
Relationship with the customer. Make sure that the support team know how valuable they are. The customers/users should occasionally visit the team or the team should go on-site to have a face-to-face session with the users (a friendly dinner or lunch will also help)
I have seen this too.
There are few approaches that I can think of:
1. Give some thought to selection process.
Not everyone have same career aspirations. While some people are always dying to work for the latest technology and challenging projects, there are others who are content at a stable work environment. Picking the person with right KSA (Knowledge, Skills, Attitude) is always central to good person-job match. In this case, you just need to put more stress on the Attitude part.
2. Choose the right lead
Team leads play crucial role in controlling the motivation and morale of the team. There must be an open and frank channel of communication with team lead and upper management. Ideally a person from the senior management should be made the owner of the team in formal organization chart. Team lead should actively try to foster a team-culture that suites the nature of the team.
3. Rewards
Rewards off course are key tool for managing motivational issues. Just make sure the person receiving the rewards understand that the nature of job was also taken into consideration in decision to reward. If this point is not addressed, it is likely that the person will not take this factor into account when perceiving internal equity.
Following Bell's suggestion, consider letting new or junior developers cut their teeth on fixes. Promote them from maintenance to the feature team based on their performance and ability.
Healthy competition is also a good motivator, but it must be managed to remain a positive influence.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Or they (team members) need someone to keep pushing?
Edit:
The above line was supposed to be sarcastically funny. Sorry to throw you guys off.
I am talking more in the lines of distributing that work within the team, and not having one person assume and/or perform project management activities.
You may not need a project manager as an exclusive role (depending on the size of the project in question) but you do need someone to track activity and make sure everyone is reaching their objectives, and assign extra resources to bottlenecks. In a large project, this is a full time job, and you would need someone just for that. In smaller projects, one of the team members can do this in addition to their other contributions. Of course, the project manager is, in fact, a member of the team, but I assume by team members you refer to the computing group.
Its definitely doable, if you have a team that self polices itself. I've worked on projects where the team seemed to be more in tune with the time lines than the manager...
Also, I'm sure that there are plenty of examples small/medium size open source projects that get released without an official project manager.
depends on the team, and how they work together
i've worked with agile teams that self-organize, mutually-motivate, and deliver promptly, all with no project manager
i've also worked with teams that had project managers, business analysts, quality assurance teams, network administrative teams, database administrators, et al, that delivered late and with less than optimal quality - mostly due to the "can't say no when the client is your boss" factor
Can they: Yes certainly. There are particular personality types that will work on time with little or no supervision.
Is this a good idea: Probably not. The type of people who are going to function at a high level in this type of setting are very few and far between. Once you have more than 2-3 people working on a project you will start bringing in people who need supervision. At that time a) one of the programmers will become the defacto project manager, b) the person will not contribute to their full potential or c) you won't ship :)
Yes, at least to some degree, as I explained in my recent Meeting-avoidance for self-managing developers conference presentation.
It's less about pushing and more about planning the way forward. Somebody has to figure out what order things are going to be built, what the dependencies are, what resources are needed, etc. If it's not done by a dedicated project manager then the team will have to do it themselves.
It's possible.
It's just not very likely.
However a bad PM can definitely prevent a team functioning predictably and delivering on time.
I think it's likely the team will arrive at a destination, but with no acting PM or PM, who knows what that destination will be.
The PM keeps people on target, on schedule, and then adjusts when the target moves and the schedule is missed. Relying on a team to group communication is probably destined for trouble in more cases than not.
It depends on who are the members of the team. If the team is filled with newbies or bums there's no future for the project, but if it's got motivated programmer who are focused and respect their goals, they can deliver more than what's expected.
Take Jo Peabody for example, he employed a team of programmers, let them run amok and earned some million dollars (At least that's what he claims in the book he wrote after he became a millionaire from Tripod). The book was 'Lucky or Smart'
So like I said, it depends on the team.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
There are numerous Agile software development methods. Which ones have you used in practice to deliver a successful project, and how did the method contribute to that success?
I've been involved with quite a few organisations which claimed to work in an 'agile' way, and their processed usually seemed to be base on XP (extreme programming), but none of them ever followed anywhere near all the practices.
That said, I can probably comment on a few of the XP practices
Unit testing seems to prove very useful if it's done from the start of a project, but it seems very difficult to come into an existing code-base and start trying to add unit tests. If you get the opportunity to start from scratch, test driven development is a real help.
Continuous integration seems to be a really good thing (or rather, the lack of it is really bad). That said, the organisations I've seen have usually been so small as to make any other approach seem foolish.
User story cards are nice in that it's great to have a physical object to throw around for prioritisation, but they're not nearly detailed enough unless your developer really knows the domain, or you've got an onsite customer (which I've never actually seen).
Standup meetings tend to be really useful for new team members to get to know everyone, and what they work on. The old hands very quickly slack off, and just say things like 'I'm still working on X', which they've been doing for the past week - It takes a strong leader to force them to delve into details.
Refactoring is now a really misused term, but when you've got sufficient unit tests, it's really useful to conceptually separate the activity of 'changing the design of the existing code without changing the functionality' from 'adding new functionality'
Scrum because it shows where the slackers are. It also identifies much faster that the business unit usually doesn't have a clue what they really want delivered
Scrum.
The daily standup meeting is a great way to make sure things stay on track and progress is being made. I also think it's key to get the product/market folks involved in the process in a real, meaningful way. It'll create a more collaborative environment and removes a lot of the adversarial garbage that comes up when the product team and the dev teams are separate "silos".
Having regular retrospectives is a great way to help a team become more effective/agile.
More than adhering to a specific flavor of Agile this practice can help a team identify what is working well and adapt to a changing environment.
Just make sure the person running the retrospective knows what he/she is doing otherwise it can degenerate into a complaining session.
There are a number of exercises you can take a team through to help them reflect and extract value from the retrospective. I suggest listening to the interview with Linda Rising on Software Engineering Radio for a good introduction.
Do a Google search for "Heartbeat retrospectives" for more information.
I've been working with a team using XP and Scrum practices sprinkled with some lean. It's been very productive.
Daily Standup- helps us keep complete track of what and where everyone is working on.
Pair Programming- has improved our code base and helped remove "silly" bugs being introduced into the system.
iterative development- using 1 week iterations has helped up improve our velocity by setting more direct goals which has also helped us size requirements
TDD- has helped me change my way of programming, now I don't write any code that doesn't fix a broken test and I don't write any test that doesn't have a clearly defined requirement. We've also been using executable requirements which has really helped devs and BAs reach requirements understandings.
kanban boards- show in real time where we are. We have one for the Milestone as well as the current iteration. At a glance you can see what is left to do and what's being done and what's done and accepted. If you don't report in your daily standup something pertaining to what's on the board you have explaining to do.
co-located team- everyone is up to speed and on page with what everyone else is doing. communication is just-in-time, very productive, I don't miss my cube at all.