Everyone works differently, and everyone wants different things from the manager. Some want to be given a task, then complete it, then be given another task... and so on. Some want to know the big picture and be left to manage their own time and priorities within it, and only be told when something material changes. And others will be at different points between the two extremes. No tool can resolve this for you, because you are dealing with people who don't fit into with an idealised model. What I would do is have a regular but short team session. 5 to 15 minutes should be plenty. Have this daily if that works for you, or less frequently if you prefer. If you are using an agile methodology (scrum) then you should be doing this anyway. At that meeting, give the headlines, listen for warning signals, and as appropriate, hand out the day's tasks. Follow up specific issues and concerns on a one-to-one level outside the meeting if necessary. By the way, if you are accepting revised requirements or changing priorities on a daily basis, something is wrong with either the team's work, or you have a flawed relationship with your customers, or you need to think again about the way that you react to external influences. Question: do all issues and change requests come through you, or direct to the person in the team who is best able to deal with them? If they all come to you, ask yourself why. Why should you act as a buffer? Wouldn't it be better to set out guidelines for the team to help them to prioritise, and let them work within these guidelines, without you having to get involved all the time? If you must have tools, try using a spreadsheet of "must do" tasks that you print out and stick on the wall every week. Have sufficient slack within this to allow you to accommodate new, unplanned demands, and use sticky notes to capture these and move them around as priorities change. Software solutions are possible, but the physical act of moving yellow stickies around a sheet of A3 paper gives a sense of ownership, for reasons that I can't quite understand. It also conveys a sense of urgency if they all start piling up against Friday afternoon...!

Should we explicitly vote for a leader? For a so small number of people probably a leader isn't necessary. You can decide everything together with a simple voting system. A leader probably will make the other two feel not so happy. What are tips for making sure that it isn't only one person doing everything? You should try to share the work based on your singular capabilities and excels. If there is someone among you excelling in something in particular, let him do the job. You can opt for having each person do a different task, or helping each other. Personally, for only 3 people I would suggest to focus on different aspects of the work. Remember though, that everybody is part of the project, no matter which things he/she is doing or how much of it. Every opinion o suggestion has the same importance as those of other people involved in the project. This is the most important thing to respect.

An effective status report tells your project stakeholders in a clear, concise manner where the project is at and how well it's going. Its main objective is to inform, and to be effective it needs to be factual, up-to-date, and easy to read and understand for your audience. Medium: email is fine for small projects, but for larger projects that have multiple streams of work it can be too limited: email calls for fairly short pieces of information (1 page or so), so works as long as you are succinct. Dedicated PM tracking/reporting tools or office documents (e.g. MSWord, MSExcel, MSPowerpoint) allow more details and more options in terms of presenting information (graphics, formatting, layout, etc.). Frequency: I find weekly status reports work well. Unless required to do so, nothing more frequent or you'd spend your time working on your status report (and wouldn't have that much to report on). Anything less frequent (like monthly) and your project loses visibility. Content: An effective status report requires to-the-point, factual and clear statements, regardless of the medium you are using. It is about what is happening now, so focus on what's just been accomplished and what's coming up, highlighting any key problem areas that may affect progress. Here is an example for structuring your content: Report Header: Project name/ID, PM name, Date of issue. Project status: a short statement saying where the project is at and how it is going against plan. You can also use a RAG (Red/Amber/Green) indicator to show progress (not to plan / at risk / on track). Show last week's vs this week's status so your reader can immediately see how things are evolving. Key achievements this week: list key tasks worked on this week and any milestones or task completion achieved. Key activities next week: list key tasks to be worked on in the coming week and milestones to be attained. Top risks and issues: list any significant risks and issues that are affecting project progress. Try to keep it to 5 items or less, keep it short but always provide an indication of resolution plan/action for each problem. Other recommendations: Unless your are required to do so, I'd recommend you don't include budget information in the status report; typically this information only concerns a few people, it may be sensitive data and you will often not have much update week-on-week (accounting is typically done on a monthly basis). To be effective, the format and content of the status report need to fit its audience. As Thomas said in his answer, his supervisor wants one page so that drives how things are reported. In other cases you may have stakeholders or supervisors who want to see a certain amount of details or content, in a specific format. It's good practice at the start of the project to validate with your supervisor/sponsor how you will report on your project. The status report is to inform, so don't use it to resolve issues or address specific problems. Don't use the status report to announce bad news: if your project is in trouble, don't wait to communicate about it. Be disciplined about issuing the report: it gives visibility to your project and also shows that you are on top of things. It's also very useful for you as a PM to keep track of how things are going and provides you with a formal, regular communication channel.

Since you said "informally", I'll mention my technique, which isn't fast. I organize a programmer's book club. It gives me a reason to socially hang out with developers outside of my office every once in a while. I figure next time some asks me if I know anyone who can write code, now I'll be able to say I do. I suppose many of the people I have ever hung out with or met at a potluck are also programmers, but generally, when the expert who knows everything about C++ meets the expert who knows everything about SQL administration meetup each other, they talk about the weather and football games. They generally won't necessarily realize that the other is a programmer or if they're any good.

A few ideas how to keep momentum in long-term projects: Frequent releases. Try to release often. You can introduce time-boxing, e.g. Scrum sprints, to create a sense of urgency within the team. Measuring performance. Measures like velocity in Scrum or cycle time in Kanban shows basically how fast the team is running. If you measure it over time you can make a point in keeping the pace or even improving it over time. Continuous improvement. Don't make it about project and project only. In one of my previous teams where we were working on a long-term project we focused on improving the way we worked which was a) motivating and b) helped us to keep momentum. Try new things. In long-term projects there are usually a lot of space to try new things out. Think where you can give people freedom to decide on technology, practices and methods they adopt. Make it great learning experience and not just building yet another project. Bring fresh blood. Adding some fresh blood usually helps to restore enthusiasm and often brings new ideas. This can affect people attitude pretty much. In such a small team it can be difficult be even short spell of some fresh faces can help much. Move people out of their comfort zones. Usually people end up doing tasks they're familiar with. One would focus on database the next one will deal with business logic and another will cover GUI (or however the work is split). Encourage people to work on areas they aren't that familiar with. Maybe it's not about optimizing productivity but would bring some challenges to people, thus motivate them.

You definitely want to train all team members. You could potentially do a "train the trainer" type setup where a few key individuals get trained and then train the rest of the team, but your results will be much better if everyone gets trained. You will also probably want to at least give overview training to anyone else that typically interacts with the team so they are familiar with the changes as well. Our agile adoption process was doing alright before we brought in an external coach, but once we brought in an external coach to formally train and coach the entire team and provide overview training to others that typically worked with the team, the team really took off. It made a world of difference just taking that time to get everyone on the same page, and having the outside perspective as well.

I think that before identifying bottleneck you should identify a "bottle" - what exactly you're going to achieve. "Agile" is a very broad and vague definition. Instead of promising your client "to make his organization totally agile" try to give him answers: What metrics/measurements will be introduced What are current values of these metrics How these values will be changed after your consulting How they will affect client's business values What is the forecasted ROI? In other words, how much will it cost.

It is said that it's better to ask for forgiveness than to ask for permission. Every now and then, we believe we can't make decisions and are asking for permission and get rejected. The reality is we often can make these decisions as long as we take full responsibility for them. We can use technology X but if it ends up adding more mess to the project we should be ready to take bullets on our chest. When I say "we" I mean both: project leaders and project champions you ask about. This approach is like alcohol -- it should have "use responsibly" message attached, but it works very well. Senior managers most likely won't make many decisions on level you point in your examples unless directly asked. If you ask, don't be surprised you sometimes hear "no" as an answer.

First things first.... the PM should always be listening to the opinions of the team. They are key stakeholders in the project and the best way to keep them engaged, motivated and productive is to foster good and open communications. You may have to work harder at communicating with those with little knowledge of PM than with others. I'm in a field that doesn't have a long PM history, and a lack of knowledge of PM in the teams leads to unnecessary impacts on scope/cost/time. This is mainly due to not paying attention to proper configuration management, change and communications practices. I've been trying to alleviate this by hosting weekly PM awareness sessions, and have noticed a reduction in problems with those who have been regular attendees.

There's no such thing as appropriate level of understanding of project management. Actually, if the project is organized very well a developer can perfectly know nothing about project management at all and it would be fine. On the other hand the more every project team member knows about job of other project team members the better. From this perspective a developer should know about project management as much as possible as then they're better partners in any discussion with PM. Anyway if I had to point the most important aspects of project management which should generally be known by as many team members as possible I'd point: Communication, especially communication with clients. We have to know what we can tell and whom we can tell that. Estimating/scheduling. We need to plan our work in some reasonable way. Being aware of how project looks like in a big picture. It always help to know the context of our work, so we can choose our solutions better.

First, communicate the issue to your peer openly. Try to base on facts and avoid just opinions. Direct communication shouldn't a problem these days as jmort points (+1). Chances are you peer is just unaware what he's expected to do and with some guidance not only would he help you but also would be grateful for help. Second, be prepared that not taking responsibility for the project may be just a symptom of some deeper problem which can be totally out of your control, like you peer may be totally overwhelmed with other, more important, projects or may be just incompetent. In this situation you may either try to investigate the root cause of the issue or try to escalate your problem. I'd start with letting know your peer's supervisors as it's usually pretty successful method. Third, there is some kind of agreement between two project teams. You don't mention any other company so I assume both project teams are parts of the same organization thus I don't expect any formal agreements but then there probably are some informal arrangements that guys over there would deliver leak-free kettles so you can build kettle of the future. Otherwise you wouldn't depend on them, would you? Now, if you can't solve the issue by yourself you should make aware of the problem people who made these arrangements in the organization. This starts to be large caliber gun so you may want to wait with that until you have no other options. Fourth, independently of all others you should treat the situation as your project's risk and make it visible for everyone interested. It would help you to share the issue with people involved in your project, including your supervisors and also it should make it easier to get some help with your efforts to solve the problem, especially that most likely you'll need to engage other people in organization anyway.

Find out why You see the symptoms but you need to know the reasons. Is he the only one or is it the common behaviour in a team? If you talked to him about the situation you should know what it is about. What are the rules that allow him to do that? Ask yourself 'is it wrong?' It looks obvious to many managers that this is WRONG but in some cases productivity doesn't go up if you work more. In many cases scrum teams can not work 40 hrs a week because productivity goes down after 30, 20 or even 16 hours. You can easily dig internet and find the numbers. So if your whole team need a brake this could be the case. I would consider introducing more socially integrating activities than playing flash games but nevertheless... Change what is wrong So you are sure it is wrong and want to change it. There are different ways to archieve it, not only "the talking". You can introduce rules that enforce a presentation of work done by each team member. Daily standup, reports, demo every 2 weeks... that way gaming member will be forced to stop or to officially convince. You can introduce rules making gaming almost obsolete: pair programming for example. It is very rare that one person in a pair will refuse to work or both will play games. If nothing works... ... it means everybody already know he is lazy one. What to do with member which does not accept rules - it is another story.

It depends on how orthodox you are going to be about project. If you take either Prince2 or PMBOK or Wikipedia definition it doesn't make a project. However personally I'm far from being conservative on definitions and so are many people people out there, so I'd say it is a project. Actually, many R&D endeavors works like that. Also, in many agile project, you don't have clear completion criteria or it is changing very often, like every couple of weeks -- it just depends how you look at the subject. What more, if you asked people they would answer they are a project team. The client is probably describing this venture as a project. The vendor probably refers to it as a project as well, so who are we to disagree? Besides, we don't get points, or get paid, for being conservatively aligned with definitions, whatever they are, but for making clients satisfied. So as long as everyone is happy, I see no issues with breaking rules of one or another specific project management methodology.

Span of Control. The number of tasks or size of the project in dollars or complexity can be misleading. Span of control dictates the number of people that an individual oversees. In other words, if the work is expanding, the number of people assigned to it will also expand. At some point, another layer of leadership is created. If it expands more, add another layer. There are different school of thoughts on the appropriate size of what an individual controls. Most times I have read that the number where we have maximum performance on average is between six and eight direct reports. Most recently, that number has been challenged and it was suggested we need to have as high 15 to 20 direct reports. I personally feel 8 to ten is about right, at least for me. So, if I managed a team of 30, I would have a layer of team leads between me and the rest.

Know the reasons If someone is absolutely not changing their ways, that person has a reason that justifies their choice of behaviour. Your first port of call is not to judge. Judging will only make matters worse, distance yourself from them and reduce your credibility in their eyes. Do not start thinking that person has a problem, and do not start asking them about any problem they may have - that is almost a sure-fire way of getting nowhere fast. Find out (genuinely positively) what their reasons are for their choices before you can do anything about them. You must understand before you can act. They may be good reasons or bad reasons, that is a judgement, but if you actually want to know and reach that person, you must not judge to start with, and you must make sure they think you are genuine when you ask for their reasons. There is plenty of time to judge afterwards. If for any reason you have lost their trust (such as pushing to their manager), then there is very little you can do other than try and regain trust. Anything else will fail. Could be slow. When you have established the reasons, then you have to respect those reasons and somehow use them to your advantage, if you can. It may be the case that you need to treat this person differently because they are otherwise valuable to the company - despite falling below par in your terms (not in their own of course). Challenge your own rules Personally I would never agree again (I have in the recent past) to any daily report of my activities or my team's, unless it can be done in less than five minutes. My personal experience is that any more than five minutes per day on status reporting is a huge waste of anyone's time. Who reads that? What benefits does it bring? What is the associated cost? So before you dare 'sell' your rules to that person again, challenge yourself one more time. Pick holes in your rules and find suitable arguments to justify their value as objectively as possible, clearly state the benefits and who benefits, and identify the cost each person following those rules must pay. You may (or may not) find that your rules need changing, amending, or some flexibility in some cases. The likelihood is that the 'recalcitrant' person is quite clever. You must share transparently the whole purpose, benefits (including who benefits) and costs with them so they can come up with their own reason to follow your rules, or, maybe offer you an alternative that could satisfy you both. Maybe you could suggest that they come up with an alternative that could satisfy your requirements, or let them negotiate which ones of your requirements are acceptable to them - if that helps in any way achieve your goals. Different people have different needs and reactions. Those differences are often for the better. That said, you may also find with this exercise that you can no longer have this person in your team. That is a definite possibility, but without actually knowing why, you'd be setting yourself up for trouble. Keep a record of discussions Lastly, if this story looks like it might turn sour - you be the judge - document everything. Make sure you keep a solid history with dates and times of what you say, what you write, verbal and written answers, formal or informal, situations, witnesses, the lot. This is double edged, but if you do your job the right way around it will serve you in good stead. Breaking the rules Some people believe that rules must be broken - they are right, just not all the time. It can be tricky deciding when it is time or not. Of course this is subjective and everyone will see this differently.

At the very least you need to provide the developers the code they work on. This limits your ability to restrict their access. You can provide libraries for other sections of code, but this can create barriers to resolving bugs. There have been cases where employees stole code and tried to create competing services. Those I know of have been successfully dealt with through legal means after the fact. Ownership of the code should be handled by contractual terms with those that use it. Copyright may also apply. Other than frameworks and libraries, which are increasingly pulled from or available the open source community, their is little code I have worked on that would be of much use on future projects. Those in-house frameworks that I have used were not as robust as the competing open-source frameworks. I have worked in restrictive code control environments, but they only had checkpoints and future code work was done on code version not extracted from teh code control environment. This lead to significant issues, where source code for released versions could not be retrieved as it wasn't tracked anywhere. Having managers merge the code limits the access to the full copy. However, managers may be more likely to be able to successfully make use of that access. I would rather restrict the code access to the developers. Most developers will only have the code they need to work with on their system. This can be a significant portion of the system, but likely not the full system. With good code reuse, they may have a significant portion of the system available as libraries. Larger sites generally have multiple repositories, and limit access to the teams requiring access. Code browsers can allow developers to browse the code from other projects they need to resolve related bugs. Code locking systems tend to add friction to the development process. I have seen little if any value added by code locking. Good communication and revision tracking add significant value. Having a manager merge the code would appear to be a another approach to code locking. There are advantages to using a review process to gateway changes into the released code. There are various approaches that can be used. They all require tracking changes, which increases change management overhead.

It is not your role to interpret what you are seeing in terms of what he has going on for future aspirations, why he may be checking out, etc. As a PM, you should have already considered the risk of intra-resource performance variability as well as turnover. Your project should already have built into its schedule and cost planning values and management / contingency reserves the resources you need to cope with varying performance levels. So if you are not getting what you need from this team member, then deploy plan B. You have a plan B, right? You can let his supervisor know that this team member appears unreliable at this stage and that you are moving in another direction for now. You don't need to say anything more to ruin his other aspirations. If he is moving on, let him. It shouldn't affect you because you have already examined your risks and built in the reserves and plan Bs and Cs to keep on going, right?

Basically estimation in hours and time tracking can result in problems during planing and daily meetings. Thus, I would suggest using storypoints instead. What is more, you should use planning on demand technique. You can read more here.

TL;DR If you're still thinking in terms of strongly-defined roles rather than cross-functional teams, then you're not making a successful transition to an agile process. Agile teams may need all of the skills you've listed, but each of those roles is actually the responsibility of the whole team rather than of individuals, and it is up to the team to identify who is best-suited to perform the relevant tasks required to produce a feature. Team Size There's no single canonical answer to this question. A lot depends on the organization, the project, and the available resources. The recommendation from most agile practitioners is 4-9 people; I typically recommend teams of around 7, plus or minus two people depending on the size or complexity of the project. Agility requires a full set of cross-functional skills on the team, but also requires that the number of communication channels be kept at a manageable level. The recommendation for smaller team sizes is primarily because larger teams aren't capable of the high-bandwidth interpersonal collaboration required by agile frameworks. Given the following equation for finding the number of communications channels within a team (expressed as Ruby code): # n * (n - 1) / 2 def channels people people * (people - 1) / 2 end you can quickly see that a 7-person team has 21 communications channels, while a 9-person team has 36. A 20-person team has 190 channels, which generally violates the core agile principle that values "[i]ndividuals and interactions over processes and tools." You will find many agile team processes that perform poorly for larger teams; the 15-minute daily stand-up is just one such example. Cross-Functional and Self-Organizing Agile teams must be cross-functional, meaning that while certain people may know more about certain knowledge domains than others on the team, the knowledge and responsibility is shared (often through pairing or other high-bandwidth interactions) rather than siloed into vertical skill sets or strongly-defined roles. In addition, teams succeed or fail as a team. In order to do so, the teams must be empowered to be self-organizing. In practice, that may mean that Bob writes the documentation while Alice codes, and Mallory writes the acceptance tests that Joe runs on the continuous integration server. However, Bob isn't writing the documentation because he's a technical writer; he's writing the documentation because he's pairing with Alice on some feature, and decides he has the bandwidth to write the documentation while Alice is running the developer-level spec tests on the code the two of them have just collaboratively written. In general, agile frameworks are built on the idea that the whole team swarms over each story, parceling out the tasks to the people who are most adept or have the most bandwidth to get a particular task done. Since the team is small, and the framework encourages constant n-way communication about task and story status, it is easier to simply hold the whole team accountable at the story level than to try to micromanage swim lanes and hand-offs at the project level. Teams in Transition For software teams in transition, I generally advocate the following: 5 developers who work interactively with everyone else to ensure that TDD/BDD specs are written, code is documented, and features are tested according to the "definition of done." 1 code-savvy QA expert who can work alongside the developers to help them write better tests, and who can maintain the continuous integration server. 1 code-savvy technical writing expert who can work alongside the developers to ensure that the product is documented as it's being written (not after the fact) and that the developers are writing documentable code and keeping code comments and documentation up to date. On some technical projects, you might need someone with database or network design skills, or some other specialty. If so, go ahead and add a person or two, but remember that their job is to spread expertise throughout the team, rather than act out a unique role. All of these people are full members of the development team; developers, testers, writers, architects, and analysts are all equal participants in every single aspect of an iteration. For example, testing is everyone's responsibility, and not relegated to a second-class team member. Testing should be part of your definition of done, and may include unit tests, integration tests, acceptance tests, or anything else your project has defined as part of the "definition of done." Since it's everyone's responsibility, you don't need a unique role for testing. Ditto for documentation. Because these teams are in transition, and are rarely adept at self-organization or collaborative development, you will probably need to allocate some project time (and therefore budget) to training, framework education, teaming exercises, and developing an agile mindset within the team. Simply throwing a few people with vertical skill sets into a room and calling them an agile team will not make it so. Lastly, it's worth noting that this section focuses on software development; that's simply for illustration. However, the underlying principles of collaboration and n-way communication during iterative development is equally relevant in any other domain. Only the skills required to round out the team should change.

I've tried this a few times and the only solution that's satisfied my needs is to break the task into smaller tasks. In your example, you'd edit the 8-hour task by breaking it up: (1) 4-hour task, 100% complete (1) 4-hour task, 0% complete