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
The CodePlex team has a Slack time policy, and it's worked out very well for them.
Jim Newkirk and myself used it to work on the xUnit.net project.
Jonathan Wanagel used it to work on SvnBridge.
Scott Densmore and myself used it to work on an ObjectBuilder 2.0 prototype.
For others, it was a great time to explore things that were technically not on the schedule, but could eventually end up being of great use to the rest of the team. I'm so convinced of the value of this that if I'm ever running a team again, I'm going to make it part of the team culture.
Have you had a formalized Slack policy on your team? How did it work out?
Edited: I just realized I didn't define Slack. For those who haven't read the book, Slack is what Google's "20% time" is: you're given some slice of your day/week/month/year on which to work on things that are not necessarily directly related to your day-to-day job, but might have an indirect benefit (obviously if you work on stuff that's totally not useful for your job or your company, your manager probably won't think very well of the way you spent the time :-p).
I just want to mention Google's policy on the subject.
20% of the day should be used for private projects and research.
I think it is time for managers to face the fact that most good developers are a bit lazy. If they weren't, we wouldn't have concepts like code reuse.
If this laziness can be focused into a creative force, and the developers can read up on technical issues and experiment with architecture and language features, I am certain that the end result will be better code and a more satisfied developer.
So, if you are a manager: Let your developers slack of now and then. Encourage them to hold small seminars with the team to discuss new ways of doing stuff.
If you are a developer: Read, learn and love your craft. You have one of the best jobs in the world, as long as you are willing to put some time into learning the best ways to do your job.
I am currently a full time freelancer working for a single client. If I want to get a full 40 hours of pay, then every minute I spend coding needs to be accounted for on the approved project plan. Or at least it has to go towards some sort of realistic maintenance task. I guess you could say this is one of the disadvantages of contracting... there's really no room for slack or being idle. You just have to keep going and going on the task at hand. It can be quite draining, but then again I kinda like how it keeps me accountable. And of course the pay is a bit better than usual.
That said, I would love to have slack time available for working on pet projects, but no client would ever agree to pay for that.
Anyway, I just thought I'd point out how this exemplifies some of the big differences between freelancing and full time employment.
I've also never worked anywhere where there was a formal policy but I have always found was to squeeze in a little R&D/tool-building time on the side. Often times I will get productivity gains out of that which will allow me even more 'slack' time.
We have slack time and we try to schedule them between releases. Once a release is out, we ask our developers to spend 60% of the day fixing bugs and then the other 40% for slack time. We have policies on what you can use the slack time for though. Then when a release creeps up again, we ask all the developers to spend all day on implementing features or fixing bugs for that release.
The policy lets the developer use the slack time for training, creating something new that the company could use, or just creating tools within the company to make things easier for ourselves. It has worked well for us. We think it is an awesome benefit.
I've never worked anywhere that had a formalized policy, but practically every manager I've ever had has allowed me to spend some time on things that weren't directly related to the current project or fighting a fire.
I think the key is to talk about the things you'd like to try. Most managers want their teams to do something cool, something extraordinary, so if you can convince them that you might deliver something, you might get the chance. Or they might let you do it just to keep you happy.
Now that I'm a contractor rather than an employee, I don't get paid to do fun stuff, but I generally only work 30-35 hours per week, so I still have time to learn and to play.
We don't have a formal policy in my team - mostly because there is just so much work to do that justifying it would be hard. Which is pretty ironic.
I've started doing some formal things in the guise of "Development Meetings" in order to at least inject the essence of this into the team. An example of this is a development project that is intended to both teach new technologies and produce a cool app at the end of it.
It's early days, we'll see how it goes.
Related
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 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 9 years ago.
Improve this question
I have a few software developers working for my projects and I would like to provide them a way to register time they spent on real development.
There is good will to register development hours, no force, but we try to avoid techniques like excel sheets register because this is so uncomfortable.
I can track svn commits, but this is unreliable. Developers also helps supporting different projects during the day, so assuming they work on one project by whole day is not true.
I've seen utilities that popups a message every hour to confirm the project you're working on but this is annoying.
Some kind of active-window-title-anaylzer might help (you can get solution name from there in the case of Visual Studio) but I have no experience with such idea.
If you have any experience with programmers/designers work hours registration, please share with me.
Thanks
Its a good question, and the very best way you can measure hours spent on a development project is not to measure hours spent at all.
You say there is good will to register hours, but I have my doubts. Realistically, from a developers point of view, excessive time management is a distraction for most (perhaps ALL developers on the planet).
I can understand why time is measured so excessively on ODesk. There is a good reason for this, because project time is paid up front by the client to ODesk, and the developer needs to prove to ODesk hours worked. Payment is also guaranteed, and its unlikely oDesk providers and developers ever meet in real life, so there is no trust.
Since its unlikely you're paying your developers upfront, and its more likely you have better trust established, you need to perhaps switch your attention from a management strategy that's cludgy and annoying, to something way more useful.
Yes ladies and gentleman I am talking about Scrum. Throw any notion of keeping hour per hour tabs of your developers out the window (they'll love you for it). And instead introduce Scrum Management into the scenario.
Create some sprints (milestones) for your product development, and in that have a list of iterations (batched deliverable s), try keep your iterations down to a weekly period.
Create a product backlog, and make sure you're aware who exactly is working on what. Find someone on the team to act as a scrum master on your behalf, or to take on this responsibility yourself. Make sure you have daily feedback meetings, keep them short and focused, to identify any risks that might get in the way of deliverable s. Let the developers more or less drive the timing process, and get realistic estimates for tasks.
Read a book or 2 on scrum, and get others and team members involved in the learning curve. Tweak the base scrum methodology to best suit your particular style of management, and I assure you, you will have a very happy team.
Measure your time in man days, and try avoid getting on the back of a developer for hour by hour progress...
There're various time tracking software tools as you have probably already seen from doing google searches. But in all honestly you are asking for the Holy Grail of time tracking. For example do you consider a developer staring at her code and thinking as development time? She might stare at the screen for 1 hour and only type for 10 minutes. In this case it looks like they don't work much when really they worked for 1 hour and 10 minutes. I don't mean to say what you asking for isn't a valid thing to want it just seems to be one of those problems that doesn't have a perfect solution.
Good luck.
I think you're asking the wrong question and are headed for a slippery slope. There's so much that goes into development that has nothing to do with actually coding.
I think a better solution if you're deadset on tracking something is to track the time spent on activities NOT related to development. Of course there's some grey area there too. For example, a meeting to discuss user requirements should probably be counted towards development even though no coding will get done.
you need something like this dashboard to measure time on task. The only way to know the real software developer time is to have then track it. That way when they switch tasks they stop the clock so to speak. I think the hardest thing would be getting the developers to use it as a measure of how long they work on a certain project or even code module, etc. If you can then use those metrics to reduce distractions and other time sucks, you might at least be able to get a decent swag about how much time they spend coding versus email versus talking to other developers, etc.
If you're trying to measure what the developer has as their active window, you have to assume goodwill, because any decent developer can sneak around that if you're trying to turn the screws on them. I spend about a third of my "development time" in Firefox looking at references, for example.
Maybe ask the developers just to keep a log, so you know where their time is going? Whereas that's not ideal, you're never going to do much better than that.
If you are trying to measure the time spent on distractions and disturbances and other task, would it not be in your developers interest to give you this information willingly?
You said somewhere that you are implementing scrum.
If you really have to either take it up at the daily scrum, making it a part of the ritual, or add a very short daily meeting at the end of the day. Let the developers guesstimate how much of the day was spent on distractions and disturbances and other tasks. To me that feels like it will be as close to "correct" as any other way of measuring, considering the difficulties involved.
So, instead of having the developers note down the time, make it the scrummaster's job to sum it up, and make this as painless as possible for the devs. Make sure that the developers gain something tangible from doing it as well, otherwise it is going to end up on the impediment list awfully quickly.
As Dean J implied, you have to trust the developers anyway.
it depends on your IDE - if you are using Eclipse then I recommend using Mylyn plugin. You can measure the time spent on each task. Tasks can be fetched from every famous task repositories i.e. Tuleap. details here
User only need to put the task in Active mode - and deactivate when task is finished to able to stop the timer. I think Mylyn will support such process - if a status of a task changes then this would trigger the active mode (if closed then deactivate the task)
Sometimes development involve using a browser, or a terminal. Eclipse can be used as a browser and as a terminal as well - so developer does not need to leave Eclipse - so almost every activity can be measured related to a task.
Try DotProject or XPlanner
An active window analyzer won't give you reliable results, because your developers will swap between programs (Outlook, File Explorer, version control, internet browser, etc.). Your proposed analyzer won't log that time, although it will very likely be part of the development time that the developer puts into the project (software development is not just coding in VS all the time).
Trying to measure a developer's work hours is the wrong notion. A proper question to ask is what is a programmer's effectiveness. That can't be measured by coding time, time spent sitting in front of a computer, or the like.
As Joel Spolsky put it well in a blog on software craftsmanship, software development "...is not a manufacturing process."
A related but somewhat different discussion appears in this SO article on an invasive programmer productivity measurement tool.
I definitely would not recommend you to use any time measuring software where the developer is forced. It is a massive distraction to developers' concentration.
Instead, the following simple techniques can be used:
Spreadsheet: For smaller projects or team of developers
There's probably nothing easier than to create and share a spreadsheet online, add project tasks to it, assign tasks to a developer, let the developers estimate hours for theirs tasks, let them update their task status(es) (very rough value between 0% and 100%) as they want, let them specify time (hours) it really took to complete the task.
So in the spreadsheet you may have columns:
task name, assigned to, estimated hours, real hours, done (%)
Google Drive spreadsheet may be the answer.
This is a very simple and fast method which distracts developer(s) minimally.
Scrum: For medium to large projects or team of developers
Tasks and the Scrum information are recorded and kept on a board in the office and/or a special Scrum application can be used. A good web Scrum application is Pivotal Tracker which I would recommend for any size of project or team.
More about Scrum:
http://en.wikipedia.org/wiki/Scrum_(development)
In both cases, the product owners (clients or those who deal with clients), project managers and all developers can better and faster:
communicate
estimate
see progress of the team and all individuals involved
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 was recently working with a team to develop an online system. We had worked for several months and were making good progress when the project got canned. We all felt strongly that the projects completion was important and that it would have great outcomes on our consumers productivity. After being frustrated for a while I thought I should ask some people with more experience.
What is the best way to deal with the frustration of a canned project and move forward so that it doesn't hold future possibilities back?
On a well designed project, some of the code you developed can be reused in future projects, making it worthwhile. Even if you can't use any of it however, you and your team probably gained valuable experience that will help in the future as well. Think of it as an expensive team exercise.
Don't put your heart and soul into someone else's project?
I do a lot of work for different people and while some projects are more interesting than others they're not my projects so I wouldn't be too broken up if they got canned. I've got my own stuff I'm working on. No one can terminate those projects but me.
Grieve. Such a loss will produce a grief reaction. Not one as strong as though you had lost a loved one, but it's a grief reaction nonetheless, complete with all those stages of grief.
Failure is the best (and sometimes only) way to learn new things, even if the failure is not your fault. There are many different angles by which you can salvage useful information from this:
Code that is reusable
New technologies or skills garnered from the project
Lessons about project management based on how the failure was handled (maybe the project should have been canceled much sooner, before the team bought into it)
Non-technical ideas that you can reuse in other projects for the company or even in your own endeavors.
I highly recommend doing a postmortem, but don't dwell. Most projects get canned at some point in their cycle and if you let it affect your morale, it becomes a downward spiral from which it's hard to recover. You may become oversensitive to even slight requirements changes.
Attack every project as though it were your own. By this I don't mean invest all of your emotions (as stated here already by Spencer Ruport). But write all your code and organize all your code in a manner that you can easily pull out tools that you might need in the future. You never know if you will need it...but odds are you will. If you write an account manager app...do it in a modular reuseable fashion. If you write an image uploader...write it in a way that it can be ported to any other project you have. Write helper functions around all of your major features to make it more user friendly down the road.
This of course requires some planning prior to losing the gig! No worries. It rarely is because of you that you (the whole team) loses the gig. Some financial decision or business decision is usually at play. In this case most likely the economy is what killed you. In the case that you don't have any physical benefits to the failed project...look at it as a learning experience. Inevitably...no matter how good you are...you probably had something that you did that you don't or no longer agree with. Learn from that. You most likely also did something very cool that you loved. BLOG ABOUT IT! This serves two purposes..you just created something tangible from the project...and you put it somewhere that you won't forget about it.
Sucks all the way around. But at least there is a great market out there right now! Contact me directly if you want my headhunter list (80 technical recruiters in CA and the US).
Two things:
Your Investment in the Project & Code: The fact your team had such strong feelings for the project & were so frustrated on it being canned is a good sign - it means you are a true developer/programmer and are not just doing a half-job for full-pay. So to deal with the project being canned: know you & your team are committed to your work & while that project may not have panned out, you guys sound like a real credit to that project & any other you may work on. It sounds like you just need to find a project/opportunity that has the legs.
My Experience: Projects get canned for all sorts of reasons - budget, lack of confidence from stakeholders, too late to market, changed scope etc. I would enquiry/investigate why your project was canned. If it is budget or lack of stakeholder confidence then it is really good news. It means an opportunity has just presented itself to you & your team. Consider pursuing it!
Either way your team will have grown from the experience: both technically & from a business perspective.
cash the paycheck - that always helps ;-)
ask if you can have the rights to the canned project, since they don't want it, then open-source or commercialize it yourself if you think it's worthy
it's good to care about your work; it's not so good to obsess over it.
there will be other projects even better than that one in the future; they might also get canned, for any number of reasons both rational and irrational
Good example: I once worked with a lady who spent 2 years on a document-imaging project that was canned a few days before it was supposed to go live; it was canned because the new manager did not like the old manager, and the project was his "pet". This lady's reaction: "I'm looking forward to learning something new!"
This can be used to bring your team closer together, if you have the right sort of people. There is nothing quite like working hard on something you believe in and then having it canned. It can depress, but it can also motivate people to want to prove next time that they can do the job, that they had the right idea.
It helps to galvanize the team; we were there, we worked hard, and it was taken from us.
Of course, it's better not to be in that situation to start with, but when you find yourself there use it to build the team.
Sunk cost cannot be used as a reason for the continuance of a project. If the leaders have made a business decision then I'm sure that it is well motivated, however upsetting.
I'd console yourself in that big swings should be celebrated in business, big companies do not win every bid and complete every project they start. So console yourself in having lost once, maybe you might be able to change the way things were done, or focus more on the project stakeholders as well to make sure they understand why your project is worth completing compared to the other projects and business initiatives at the company.
I'll finish with my favourite saying:
"Good judgement comes from experience. Experience comes from bad judgement."
Learn from it!
Watch a Rocky movie (the last one was good) and have a few beers. There's no way not to put yourself into a project, there's no way to not feel bad about a project being terminated or failing, there's no way not to feel negative about the company. What makes a good programmer better is taking all the emotions, anger, etc. and being able to release it and move on with the same focus and dedication that was there with the first project. All part of life and all part of working in IT.
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'm the leader of a small web development team, and I have a feeling that we will have a couple telecommuters joining the team pretty soon (either new employees, or existing employees that will begin telecommuting). Any idea how to effectively manage and collaborate with developers working remotely?
Most of the work we do is client-driven. We're doing agile development (or our version of it, anyway), but since it's mostly client work, we can't really assign a feature to a developer and set them lose for a week or two like we might be able to with a desktop app or something like that. The biggest problem we have when people occasionally work from home is collaborating - it's tough to work together without the benefit of a whiteboard and hand-waving.
It seems like software development is perfect for telecommuting, but I haven't been able to find many good resources about the practical aspects of working remotely within a development team. Has anyone else had any experience with this?
I freelance a lot and in doing so work remotely a lot of the time. These are the things that make my life as easy as possible (so might be things you want to "suggest"). I think they're mostly common-sense, but you never know...
[Everyone] Communicate well. When you're having a conversation face-to-face, you can be verbose and explain things in a round-a-bout way. When you're limited to email, IM and phone, all parties need to explain themselves fully but succinctly. I find that summarising long emails into request/action points goes a long way towards getting things done well.
[Everyone] Have a online project tracking space. Most tend to use a ticket system or some description, where action points can be assigned to members. It wouldn't hurt to use this same space for tracking emails and sharing whiteboard ideas. Most online project apps allow for that by default.
[Management] Don't pester devs. If you need something urgently, set the status of the ticket, give them a call and chase them up later on in the day. Half-hourly emails asking "is it done yet?" does more harm than good!
[Management] Make sure messages get passed along. If a dev says "somebody needs to do something", it's your job to make sure the message is passed along to the right person. There are few things more annoying than passing a message to a project manager for them to accidentally sit on it. I don't want to have to chase up things like that because it's, frankly, not what I'm being paid for.
[Management] Make sure people have something to do. If you send them home with nothing on their task list that they can immediately action, they're not going to put in the effort. It's a damned sight harder to keep yourself productive at home than it is in the office when you've little or nothing that you can do. You might have to juggle tasks if there's a blocker.
I work at home full time. Here are things that help in my small (6 people) team.
Set up rules for using IM. For example, allow remote workers to block off time not to be interrupted by email or IM. Require workers to keep status up-to-date somewhere (IM, Yammer, etc) which helps keep them accountable to stay on task. Stay in touch without being a distraction.
Meet in person occasionally if possible. Nothing can replace a face-to-face meeting. Skype is ok for group meetings, but not if whiteboards are involved.
Use SharedView or another screen sharing program for collaborating. Screenshots/screen captures are helpful as well to make sure both parties are on the same page.
"Any idea how to effectively manage and collaborate with developers working remotely?"
What does "effectively" mean? I can be negative and assume it means "with me, the project leader in control of everything". I can be positive and assume you want people to be as effective as possible.
Sometimes, "effective" is management-speak for "under my control". Or it means "not screwing around."
The question, then is "effectively doing what?" Effectively "working" is rather vague. Hence my leap to the dark side of project management. [Which, I admit, is probably wrong. But without specific team productivity problems, the question has no answer.]
"it's tough to work together without the benefit of a whiteboard and hand-waving" This is only sometimes true, there are lots of replacements. The "hand-waving" over the internet happens more slowly and more thoroughly.
The group-think around the whiteboard is fun -- it's a kind of party. However, for some of us, it's not very productive. I need hours to digest and consider and work out alternatives; I'm actually not effective in the group whiteboard environment.
I find it more effective to use the alternative "slow-motion" whiteboard technologies. I like to see a draft pitch for an idea. Comment on it. Refine it. A lot like a Wiki or Stackoverflow. I really like the internet RFC model -- here's my idea; comment on it. When there are no more improvements, that's as good as it's going to get.
I work in Mississippi and my home office is in Michigan. I spend several hours a day pair programming with my team with ease. The tools I use are:
SharedView
Remote Deskop Assistance
Live Meeting
Oovoo
Skype
Depending on who and how many will depend on the tool I use.
"Use the right tool for the job and invest in a damn good headset." - Me.
I've generally used some time of community based software such as a wiki, blog, or forum to handle the documentation areas. We also have a Cisco phone system and use some capabilities of the system. I'd also recommend live meeting or webex to do frequent team meetings. Skype and IM clients such as Live Messenger are also good tools. For the short status updates, twitter does the trick.
Check out the Agile Scrum methodology with VSTS. Scrum forces us to have daily 15 minutes meeting and small mile stones , It makes sure the effective togetherness and tight communication. Make sure you use Task,Bug assignment etc through VSTS
I agree with John Sheehan's response. I am a consultant and manage other consultants - both on a project basis (as PM) and on a client basis across projects. I have worked with developers on a purely remote basis as well as telecommuting (meaning the majority of time we are co-located). Working remotely is a matter of trust and communication. Co-locating is best, but if you work remotely, simply create a culture of frequent communication. IM and phone are great for this, email less so. If you have a less than communicative co-worker, it is up to you as the manager to reach out. Ask for status. Force code-checkin on a frequent basis for review.
[EDIT] - Yes, don't pester and set expectations! Be clear and concise.
First of all use scrum (daily scrum calls, scrum board w/ burndown chart (wikis do a great job there), iteration in sprints etc). Next to that use tools that make it more easy to collaborate remotely like skype and VNC (maybe campfire?) and a wiki. I worked for 2 years on a project w/ people in 3 countries on 2 continents and various time zones and it worked quite well. The key is having tools and methodologies that make it more difficult for people to "hide", so that everything you and your team does is visible.
I find clear communication and staying on task are challenging with virtual teams. I try to use regular scheduled update meetings (over the phone or video conference) with a written agenda to help with these challenges.
At the front on the agenda list the major milestones and the near term milestones. The first item is always "check progress" each team member simply updates us on when they expect to finish the particular tasks involved. We try not to get involved in long stories here. It's simply "what are you going to do and when".
Once the progress check is done deal with any other issues raised in during the last week and any issues the team has that can be sorted out whilst you are in the meeting. Anything let over (such as new issues raised) needs to have the question asked "who is needs to sort this out and when".
Once you set a common format for the meeting you can do this weekly in 30-45 minutes with teams of 5-8 people. Keep it short and sweet so it isn't viewed as an imposition. Keep it focused on actions and schedule so it can be valuable.
I'm currently the PM of a smaller project that has two developers (myself and another developer that works out of the office). We are currently having daily SCRUM meetings, which last for about 15 minutes. We discuss what got done the previous day, what problems were encountered and what I can do to help with these problems, and what will be done tomorrow.
They're pretty quick and seemed to be very helpful.
Using a Time Tracking Software for your remote employees can greatly help you in managing the team.
While hiring a remote employee, you would be concerned about,
The amount of time spent in getting a task done.
The quality of the work done.
Collaboration based on the progress of the project.
The real time progress on a task.
Collaborating to solve bugs and logical errors.
I was in your situation a while ago and then I tried StaffTimerApp and it helped me in the following ways.
A Time Tracking Software gives crystal clear statistics about the time spent on getting a task done. StaffTimerApp captures screenshots and converts them into billable and non-billable hours. Hence, you would know if any time was wasted while getting the work done. You would also know the exact amount of time spent in getting the work done. If you pay your contractor by the hour, this application can help you tremendously.
If you use a time tracking software that captures screenshots, you can look at them to analyse the quality of work that is being delivered. I used this feature and was able to save some tasks from derailing.
A Time Tracking Software lets the employer know how far along the employee is with the task, hence the information extracted by Time Tracking will make collaboration easier. StaffTimerApp proved to be very helpful as I was able to collaborate with the other employees based on this information.
The screen sharing feature equipped me with the power of viewing my employee's laptop screen in real time. This way I would get to know about the progress on a task.
So you need a good Time Tracking Software with great productivity analytics and employee monitoring capabilities to feel comfortable with hiring a remote developer.
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.