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
To those of you who started using scrum in your development teams: Did you maintain the traditional teams or form new ones? At our organization we are split into database, product development and frontend developers (simplified!).
I am interested in whether others actually reorganized their whole team structure due to scrum or if you formed dedicated project (?) teams combining e.g. one person of each "old" team.
I actually can't even imagine how scrum could work if you maintain your role silos. In scrum we build vertical slices through the product so that every feature delivered during a sprint requires all the skills you mentioned (plus QA which you did not). How would you create continuous collaboration and have people commit to the sprint if they weren't all on the same team? Seems like the most likely way to end in "Scrumfall" to me. I'm not an expert by any means but it seems to me that the sure way to fail at scrum is to think of it as a project management solution instead of an entire organizational change. Its cultural at the core.
To answer you question about "generalists". The easy answer is that by having certain people only able to work on certain things you create big fatty bottlenecks in getting to Done. With specialties you are always constrained at each step by having limited resources to work on something. In sprint 1 you may have a lot of db work to do where there is more than just that one dba can do. But then in sprint 5 where there is no change to the datamodel at all, your dba will be sitting around keeping bored. It becomes almost impossible in sprint planning to commit in a reasonable time if you have to divy up and assign at the task level by role instead of just grabbing the next set of priority features that fits your team's velocity. The generalist model will inevitably bring business value in the long run. You may just not see it right away until you achieve cross-pollination.
I would warn that if you are already in silo-ed groups by role, then you have to be very careful in am agile reorganization. Many people are not ready and don't want to be ready to lose their special titles and just become team members. I would think you should almost always expect some amount of turnover.
It is preferred that in scrum/agile development that most individuals on the team are 'generalist' meaning that anyone can reasonably step into any role so that anyone can pull off items in the backlog as the come and nobody is waiting around for others.
now this may not be the case in your situation today but doing things such as peer programming and standup meetings to see where people are having impedements and to improve cross pollination of knowledge will help in obtaining this goal.
At my company we create a temporary cross function team for each project. Our existing teams are still there, but it is really important that we have cross functional teams for scrum.
We generally try to mix up a little bit to get some cross-team knowledge, but we for the most part work on our specialties. But as the project progresses we can more easily help out on different teams
When I worked for my previous employer, the company reorg'ed the whole dev organization and product management. They put engineers, qa, and analysts in each team. The split was mostly vertical/functional with some exceptions. Those exceptions were a mistake - the architecture vertical did not fit, because it was really horizontal. I thought that cross-functional teams worked well. In your case, the db and front-end departments need to merge with the rest if possible, and new verticals specific to your product may be created
We split our team into New Product Development and Existing Product Maintenance, with the ability for any developer to hop from one to the other between sprints.
I think we have maintained the traditional team, at least for now. There are a couple of other teams within the applications branch of the Information Systems department where I work though these were put in just before we got into Scrum.
There is a big project most of us are on that is using Scrum and the team seems to be evolving along nicely. We have some new tools and processes that seem to have helped us a lot and given us a sense of "awesomeness" that hopefully we will pass on to the other teams.
For changes to a database, any of us developers can make the change in the development environment and then pass along the script to a DBA to be done when it is ready for production. For changes to the network, there are infrastructure folks that handle that and initially setting up a server in terms of O/S, network, memory, hard drives, etc.
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 6 years ago.
Improve this question
Firstly, I'm aware there is a UX stackexchange, but I'm a UX designer trying to get more of a dev's perspective! How can the UX design activity work well with a team of developers and testers trying to work in an Agile way? There seems to be reluctance to do any (UX) design up front, and to only engage users after something has been built, rather than prototyping and testing with users before making production-quality code.
The basic theory behind agile is that there should be close collaboration between the development team and the customer throughout the development cycle, and that the team has all of the skills needed to succeed.
In your case, the UX designer skillset should be represented on the team, and conversations with the customer about UX concerns should take place alongside conversations about functionality.
So, the explicit answer to "How can the UX design activity work well with a team of developers and testers trying to work in an Agile way?" is "In an agile way, of course!" You need to work on the same stories as the developers. Don't try to create a UX design all at once. Let it emerge over time as the stories are developed, just like the functionality. As the developers are working with the customer to understand the functionality of each story, you need to be present and discussing UX concepts. Functionality and UX should evolve together, so the developers always know both what the software should do and how it should look and feel to the user.
The developers have learned that big design up front is a bad thing; the same goes for UX.
A key aspect of Agile is responding to change over following a plan.
Creating a detailed UX design up front works brilliantly as long as the requirements are unchanging and there are no technical problems encountered that require changes to be made. Agile is all about handling these kinds of changes.
The best way for a UX designer to work in an Agile way is to think of it as a 'just in time' process. What is the best way for you to produce good designs but to do the work at the latest possible time that is practical?
In this way if a change does occur (for example there is change in priorities and you have to quickly focus on other work) then you are best positioned to quickly adapt.
As you can probably tell this isn't a one-size-fits-all solution. Each team needs to explore how they fit design and developement together. With some teams they might have the designer pairing with the developer and work on the design and development at the same time. Other teams might do their designs a few weeks ahead and run them by the users so that they are approved and ready by the time development starts. There are no hard and fast rules here, it is about doing that which the team finds to be most effective.
It is all about discovering the best compromise between doing detailed up front preparation and being able to respond to late changes.
You should try faster methods, as paper wireframing or balsamiq mockups which gives you a very good idea of what the system will look like, so you can test with real users and you are able to make an 'on time' delivery between sprints.
It is very important to discover what the user needs,or to be more accurate to see if they get the idea of your development before It's built.
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 5 years ago.
Improve this question
Everyone is talking about Agile and how good this is. There are several advantages and disadvantages of Agile. I have studied them theoretically. Since there are experts here who have worked in many projects I want to know real two-two scenarios where Agile is unsuitable and suitable. Thanks
If it is possible to do agile well, then i believe that is always a good thing. If it is not possible to do it well, then i believe that it can be harmful. Not because there's anything intrinsically hazardous about agile, but because it would mean using a dysfunctional process.
So, agile is unsuitable when the conditions for doing it well do not exist.
Some things that could scupper the adoption of agile:
Team members do not understand the process, and do not have either the time or the inclination to learn it
Team members do not have the experience or maturity to assume more control over their own process
Management requires detailed long-term plans as a deliverable
The customer is unwilling to provide feedback on incremental releases before the final ship
There is a high churn of members in the team
The technology in use does not permit a build and test cycle of a useful length (i've done agile with a three-hour build and test cycle; this was very painful but just about doable), or does not permit it at all
The problem domain does not admit incremental development of a solution (i'm not sure if this is ever true; the nearest i've come to this is when dealing with cryptography, where the thing either works completely or doesn't work at all)
To some extent, these can be remedied. An uninformed or inexperienced team can be shepherded by a cadre of informed or experienced members. Team leadership can write a long-term plan, then let the team ignore it and hope that delivering working code will pacify management. Business analysts or QA can act as a proxy customer for providing feedback on incremental releases. Branching strategies and build servers can be used to decouple build-and-test from commit and merge. These remedies are certainly not guaranteed to succeed, though, and if the problem remains insuperable, agile will not be succesful.
Agile may be unsuitable when:
it threatens to expose overgrown management (some positions suddenly become clearly superflous)
people actually don't want to have fun and do creative things, preffering 9-17 mode of mundane work (maintenance of legacy crappy software that just cannot wait to be disposed of)
politics rather than professionalism run the company
Human Resources run the company (Agile is about humans, HR treats them as things)
the customer expects that you will figure out what he needs for him (Agile will make you asking him questions that he doesn't want to answer)
Agile is expected to be a magic wand that will solve problems without anyone changing their habits (another buzzword, a fad)
development is spread across multiple locations far away from each other, in different time zones (communication suffers)
you have a pointy-haired boss ;)
or in general:
it is misunderstood
organization is devoured with serious patologies
no one actually wants it
I worked with many different teams trying to move to agile. Some succeeding, other which did not succeed. Based on my experience, I can say that:
Moving to agile is suitable when the software creators want to improve quality of their product(s) (whatever its mean in their context) so badly that they are even ready to work as a team to achieve it.
Moving to agile is not suitable when everybody is happy with the current quality level and/or do not want to work as a team.
Sort answer:
agile is suitable, when IT company is making its own product. e.g. visual studio is made in agile way couple of years. And you can see much better "idea to delivery time".
Agile is not suitable for Internet Banking. Another example is client based in US and dev team or its part in azia. The time delay makes things complicated.
Long answer:
First, if you want to run an agile project, your management should understand it and processes in your company should embrace it. If you try to workaround them, you will fail. See how management and internal processes are important here: https://www.youtube.com/watch?v=4u5N00ApR_k It's more important that the management and team leads understand agile processes than the programmers. Usually, opposite is true.
Second, your client's management and processes should embrace agile processes. A bank or financial institution will never sign an agile contract. Their processes requires deep planning and approval at multiple levels. See how clients misunderstanding of agile can cause a fail: https://www.youtube.com/watch?v=lAf3q13uUpE
I completely agree with Tom Anderson, that the circumstances are more important that the type of project itself. For example, if you have signed fixed contract (either because of your management, or a client), you probably have detailed requirements. If you have detailed requirements, you wont run scrum but "SCRUM BUT". It's against agile philosophy.
It may happen that the project is not suitable for neither agile, nor waterfall.
Sometimes it's better to use agile internally having Product Owner role assigned to somebody from your company, who understand the domain best.
Suitability and Unsuitability of Agile methods?
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
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Team should decide whether a tool is to be used; but I think suggestion most commonly comes from the Scrum Master as (s)he is most likely to have experience using tools. Any team member can suggest tools of course.
Anyway, my feeling is that given Scrum philosophy, the whole team needs to agree on this in my opinion. Usually things start with "let's try this, see if it works", and is refined along the way, just like anything else in Scrum. It should not be top-down enforcement, same way as using Scrum methodology should be team decision, not handed down from top.
Great question. There is a lot of value to embracing the self organization of agile and allow the teams to choose their tools. However, there are usually constraints imposed by the business. For instance, the business may not be able to support/want each scrum team rolling its own scm solution. The more established the business, the more constraints and push back. Even established businesses can change. Don't be afraid to question a constraint if the team can justify the change.
Agile planning tools will follow these same rules. The business may have a full software life cycle management solution in place. This solution may or may not have an agile module. However the business may have reasons (regulated industries for example) to require that design inputs / outputs are documented in the life cycle management software solution they have. The business usually needs to balance keeping the teams happy / productive with staying in business.
I don't think there will be a black or white solution (unless you are one of the first devs at a start up). Agile teams will need to embrace the open communication. If the tools are impediments the business needs to know.
I'm going to make simple answer, because I actually think this is a simple question.
The WHOLE team is responsible of that.
Let me explain a little bit.
We first have to accept that every context is different, so this is not a biblical answer.
Let's say you start your project. I always love starting my projects/products with nothing.
NOTHING. Sometimes, just a task board, with todo, in process, done.
That's it. And I fill the todo column.
And that's all my point: I build my agile process incrementally and iteratively.
Why should I have to create a Burndown Chart? Because literacy tells me so?
Hell no, because, maybe, eventually, at some point, I might need to have some visibility for my planning.
Same with everything. And never forget, Agile tools serve as a support for the process.
So, you're a PO, and you're tired of the simple todo list, and fell the need to do a Backlog?
2 Solutions:
-- you're already in a highly mature team, you just have to tell everybody during stand up meeting that you're taking the lead on it. Eventually it'll need a retrospective to accept that.
-- you're migrating from a V, W or whatever product management model. Then, wait the retrospective and ask everybody and explain your pain. Give solution (here the backlog), and ask for a shot.
So, you're a scrum master, and you find a "systemic bug" in your process, let's take the classic one: Too many bugs. Then take the lead to promote TDD, or systematic testing.
So, you're tech lead and feel... Well, you understood me.
My point is: never over tool your process at the beginning. Build the process slowly, add tools slowly, when you need them. And by doing so, don't worry, people will take reponsability to create the tool and add it to the process, to lobby it to the rest of the team.
Hope this helps.
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Well my experience from real life is that, certain "Agile Planning Tools" tools were handed to the Scrum Teams before they even started their Sprints, fortunately the Teams liked it, but we were free to inspect and adapt to using something else if it did not work out for us.
I think it should be in the Teams power to use, accept or reject a tool in a completely transparent way. They could very well take suggestions from the Scrum Master or an Agile Coach because (s)he may have more knowledge in the Agile Tools area. Secondly, the Team should be courageous enough to have a collective discussion and decide on using a tool based on the Agile Coach's suggestions, and see how it works for them, and adapt and adjust from using it if it does not work for them (productivity-wise)
The bigger question which you did not ask is, how do you manage the differing tool set chaos when the company scales into having multiple Scrum Teams who use their own Agile Planning tools?.
Well, I think realistically, in a scaling agile software company, a little bit of uniformity in tool usage across Scrum Teams can be beneficial and productive but that may be directed by the self organised enterprise project Team instead of each Team having their own tools. Off course there can be exceptions, where certain teams are working on completely different features and they need a totally different tool set, but the benefit of using common Agile tools will help scaling projects view their Teams progress without much of change in gear.
The above can be done by having a Technical, Infrastructure and Process Tools Story which not many companies use or create. This EPIC story can be the starting point for discussion of what Agile tools and other tools can be used, to have a little uniformity within the project. While deriving the EPIC story the whole project team could be involved around project kick off, if it is too big then 1 - 2 members can represent each of the Teams. The story could be broken down exactly like business user stories, and modified accordingly and calibrated, estimated and prioritized through out the project from an infrastructure and tools stand point. Let me know if you want me to go in more detail about this.
Ideally the scrum master, but they may inherit some legacy which needs some evolution.
If the organisation is new to Scrum, then an experienced Scrum Master should be able to advise the best tools for the maturity of the team.
Typically, if a team already has some tools, a scrum master can adapt what is already there, regardless of the organisational choice. Some of the best boards are on Excel Spreadsheets and work just as well as a purpose built system. Every technology creates 'constraint'. So, it is up to the scrum master to support the business in ensuring the tools are fit for purpose and delivering the value the team needs.
Typical mistake I experienced as a coach was decision made by managers or even senior management according some study done by 'specialist' or even external consultant. Those people are many times not aware about what, how and who will yse the tool. In this case I see dissapointed people once they should use chosen tool.
You have to consider who is going to use the tool for most of the day. Team members are better target community. Tool must support ScrumMaster role due to daily work she needs to done. Include experienced product owners into selection of the tool as tools have different support for planning that is necessary to be usable.
Consider your organization (complexity of products, projects, number of locations)
The responsibility (and authority) of choosing a planning tool should be with the team. Often the surrounding organization will have a stake in terms of licensing costs and consistency across teams. Depending on how autonomous your teams are it should be OK for them to chose their own tool, though.
Within the team, the product owner usually has the highest stake in the decision, since he will be the one who is going to use it the most for continuous refinement and prioritizing. The rest of the team often only interacts with the planning tool during refinement and planning sessions once or twice each sprint. So he is usually the one driving the decision-making, but should definitely involve the team.
If the chosen tool also includes a board that the team uses daily to track their work, they will want to have more of a say in the choice.
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 10 years ago.
Improve this question
What does the "self organizing" in "self organizing Scrum team" mean?
See this article for a good explanation. This quote explains the heart of it:
Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.
The team approaches a project, and, based on the project at hand, decides how best to allocate its resources to take advantage of each team member's various strengths.
What does the "self organizing" in "self organizing Scrum team" mean?
It means this: No one – not even the ScrumMaster - tells the Team how to turn Product Backlog into increments of shippable functionality. The Team figures this out on its own. Each Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Team’s overall efficiency and effectiveness.
Reference: Scrum Guide
A self-organising team is one in which every member of the team is working towards some shared goal. Team members collaborate to reach the goal, valuing the team's output over their own individual productivity.
A self-organizing team tends to be:
trusting of each other's motives and motivation
helpful, respectful, communicative and transparent
collaborative with other teams
interested in delivery and feedback
goal-focused instead of productivity-focused.
The project manager's roles in a self-organising team tend to be:
making sure that the team has people with sufficient skills to succeed
helping them be aware of and understand information coming from elsewhere in the company
reporting the team's progress, successes, risks and obstacles to other audiences
getting stuff out of the team's way wherever possible (see Servant Leadership).
A self-organizing team is usually pretty good at getting things done, blasting through obstacles, communicating issues outside of their control and generally provides a great project experience for anyone using them. See also: Forming, Storming, Norming and Performing - you're looking for that last one.
It’s a flexible, responsive team that is allowed to make important decisions on its own in a preset framework. Usually, the management decides on the goals and overall deadlines for a project. Then it's up to the team to find the best ways to attain these goals, distribute tasks among the members, plan and evaluate their own work at the interim deadlines they set. Team leadership is not set in stone. Usually, the Scrum master changes regularly, so that each team member has a chance to try this role.
The main aim of such teams is to encourage the self-actualization of every worker. When team members can make a difference, they feel inner responsibility and motivation to perform. This way, self-organization promotes innovation and a good team morale, both of which look like solid benefits. By the way, we recently published a blog post explaining the benefits of the concept in more detail. You can check it out here, if you are interested.
A self-organizing team in Self
organize scrum team means each and
every team member is responsible for
their individual module, Scrum master
role is minimal/existed in the team.
Self organizing scrum team means low
ceremony and trying to work as a
collective whole so titles mean
little.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm sure that all of us have had to deal with telecommuters at some point in time, and I'm facing a situation now where my new project will have a "core" group of office workers and some off-site telecommuters. Not wanting to repeat past mistakes, I'd really like to know what ways people have tried in the past to effectively integrate telecommuters in an agile process, namely scrum.
My first fear is that the telecommuters will be the first ones to break the "daily scrum" routine. And, as human nature often goes, once that gets broken, it's hard to resume and get people back on track. Scrum recommends enforcing small, fun "penalties" for people missing or being late to the daily scrum, like donating a few bucks to a jar which would later be used to buy a case of beers for the end-project party or something. This is obviously something that would be difficult to enforce online.
The other big problem with telecommuters is the "out of sight, out of mind" problem. Aside from using webcams/skype/teleconferencing, what other tips do people have for keeping the team as closely knit as possible?
Also, what about dealing with telecommuters from different timezones? At the moment, we're lucky enough not to have this problem, but it's definitely a possibility at some point in the future. How have other teams dealt with this problem?
Instant messaging really helps with the "out of sight, out of mind" issue as their 'Status' (Available, busy, on the bog, etc) is visible to all. Also, by responding to messages they reinforce the idea that they're generally available.
I wouldn't worry about the Scrum meeting issue, joining a meeting via teleconf is often easier than attending in person.
Set the ground rules upfront. Don't be wishy-washy about them.
You've probably eliminated the "I got stuck in traffic" excuse for missing the meeting or whatever when they're working from home (or a satellite site) and so there's no reason to expect less out of them.
Take advantage of technology:
Use IM. We use it here and it is great for 'reaching out and touching' the guy four states away. Make it a requirement to be available via IM.
Use other tools to help break down the barriers. It'll depend on your situation.
If you're having the daily meeting, it should be clear to everyone that you're going to be asking the questions:
What did you accomplish since we
last met?
What are you going to be doing
today?
What's in the way that needs to be
moved?
Just because you can't see Matt in his cube doesn't give me a right to be lazy or unproductive and unresponsive. It's like dealing with my kids - let them know the rules and what is expected, then nobody can claim ignorance.
We have success using this tools:
Assembla for project management (source control, wiki, scrum tool)
Skype for voice communication
Google talk for im
We are team of 3 developers, in 6 time zones range.
I spent a year as the only remote guy on an Agile team. I called into a conference line for the daily scrum, as well as the planning/review meetings. I kept in contact during the day via IM/e-mail/phone.
I think it worked pretty well overall. The biggest constant drawback was not being able to see the physical whiteboard we used to track the scrum. We discussed moving to some sort of online tool to do this, but it never happened.
I was one timezone away, and I just considered it part of the telecommute tradeoff that I would work the hours that the rest of team kept.
As far as penalties for missing SCRUM - to a certain degree you should enforce this loosely, via the beer jar or whatever. But if someone is consistently missing/late required meetings, then their manager needs to address that.
The are a number of techniques that you can use - remember the purpose of colocation is to encourage collaboration and communication. A few things can help out.
If your team is all nearby - think about having core days of when everybody can come into the office. My current team allows working from home on Mondays and Fridays - and everybody comes in the office Tuesday through Thursday
For distributed teams, I have had good success with using Wikis instead of giant sheets of paper on the wall. The nice thing about wikis is that they encorage the team to edit the forms to meet the needs of the team as opposed to adapting to a more formal tool.
Another advantage of having a Wiki is each person can have their own page to share pictures about their vacations and hobbies - this makes remote people more real.
When you have a distributed team, I want to second the use of Instant Messaging that includes a status (Available, Away (grabbing a cub of coffee), Busy (in a meeting)) - these can include notes if people switch between working at home and at the office.
Webcams are inexpensive and valuable tool
Invest in a decent speaker phone (we like Polycom phones) for your group conference calls
Use tools like LiveMeeting to promote remote pair programming
A technique for doing stand ups over the phone is to have the person talking say the name of someone else in the group who has not gone yet - this keeps everyone paying attention.
For iteration (sprint) planning meetings - follow up with meeting minutes or a communication plan to make sure that everyone is on the same page. Not being colocated means a tad more documentation and intentionality on communicating.
Good luck
SCRUM and many other agile methods really do depend on physical proximity - it is hard to integrate telecommuters into any development process where integration happens frequently, but these particular processes are especially hostile to disembodied developers.
You will have to adapt the processes to the situation at hand. Video conferencing using webcams is actually very usable, and in fact yo might want to experiment with having their webcam on all the time in their cubicle/work area so people can just walk up and ask a question as they would with any other coworker.
But at the end of the day, you simply have to expect things to go differently for them - they aren't going to be able to fully participate in many processes if you are an agile shop.
-Adam
Make sure they attend the daily standup via webcam; as you said that's the first mis-step down a slippery slope. We try to have all meetings done with a RoundTable as well which really helps.
I've been doing this for two months (working in Canada with the core team in Dublin) and so far everything has been going really well.
See Scott Hanselman's writeup on his first year working remotely at Microsoft - definitely some good tips there. One Year Later.
Instead of a beer jar, the privilege of telecommuting itself could be part of the bargain for participation when required. If the team is not responsible enough to telecommute properly than they probably shouldn't be. More fun penalties for occasional tardiness could be to use a funny avatar to represent the person that is missing from the meeting.
Other methods of keeping people closely knit is using collaboration tools such as Wikis and project tracking tools such as Basecamp or FogBugz.
For differing timezones, early meetings will need to occur based on the furthest west time zone, unless one is on the opposite side of the world, which is a bigger problem. Then it will probably be based on who is in charge.
We have been able to manage daily scrums in our environment even with distributed teams over the phone.
It helps to use software such as Rally and Basecamp to manage the process.
One place I worked used Asterisk instead of a normal phone system. It worked well because when you are working from home, you simply log on, people can call your direct line number, outsiders don't need to know. Even though phone call cost are relativity trivial these days, having a 'always on' connection encourages more communication. The sound quality is better too.
For telecommuters/distributed teams, I recommend getting a decent phone - most desk phones lose the ability for folks on the other end to hear folks who are multiple feet away from the phone during a standup.
When you do your demos of working code for stakeholders at the end of the iteration, use webex or livemeeting or something to share the desktop and a camera to show the speaker so that your distributed participants can see what's going on. (Even better would be to ask your telecommuters to attend during iteration boundaries to participate in person).
I recommend getting folks together for a few weeks at the beginning of the project during the inception/kickoff phase so folks can build interpersonal relationships. It's amazing how helpful the face-to-face interaction up front can be to build a foundation for teamwork.
Use a distributed card wall. I like Mingle (http://mingle.thoughtworks.com), but I haven't used other tools, so can't comment on them.
For retrospectives, it's useful to have a proxy in the room using IM to communicate with your distributed team members... so that any comments the distributed folks have can be written onto a piece of paper (or post-it, or however you do yours).
As for your fears of "out of site, out of mind", my preference for things like this is to not create solutions for problems that have not yet materialized. If you find that your team is becoming disconnected (prime discussion points for retrospectives), then you can facilitate a team discussion on how to deal with any issues that arise. Again - the team should help identify the problem and the solution rather than having a manager or scrum master dictate solutions. Start with an assumption of trust.
Distribute Scrum requires good preparation. It is not just about the tool.
We supported many rollouts in distributed environment and there was one fundamental point - people.
The most efficient is to start with ALL people in one location. They have to meet in person so they can know each other as persons, not just someone virtual on the other side of the world. As I used to say - team members need to smell each other.
For release planning meet at one location, if possible. Change locations so you visit all of them, to have a context and understanding of culture, habits, persons. For sprint planning use video meetings, screen sharing etc. It is not necessary to travel (it would be too often).
Clear roles and team(s) organization must be established. You have to have Product Owner and Scrum Masters. You should consider if you do not want to get PO & SM as close to the team as possible. Definitely you have to get them into face 2 face meetings (it is about face, not a location) every day.
Definition of done, if agreed by the team, helps to have the same understanding what Done means. In distributed environment is a must.
You will need a good communication tools for daily stand-ups . We found usable to use Skype or Office communicator for dailies. We use audio AND chat. Especially in international environment chat allows you to understand people. Keep communication channel open after daily so team members can discuss what is necessary outside of daily report.
And, the most important, is to do regular retrospectives with all team members in all locations. Do not forget to implement ideas coming from retrospective. Teams in other locations will need a local support who will help them to implement ideas.
I work on a team of 5. We to facilitate our telecommute workplace we use:
Asana - Project and Task management
Google Talk + Your favorite IM
client (I used Pidgin)
RingCentral - VOIP Telephone
Gmail - asynchronous communication (i.e. email)
Dropbox - file transfer and
backup
Team Viewer - Screen Sharing, Training, and Presentations
Even with these tools it is easy to fall short on your process so it is important to establish some best practices for your team based on your dynamic. For example, we have two chief practices:
Communicate Often - because we are not in the same location when communicating it is easy to forget that you are working on a team. For our team, we update our tasks in Asana with comments describing ideas, obstacles, and task completeness. When immediate assistance or feedback is needed, don't wait, seek assistance via IM or email if (the person is offline).
Lean on the side of over communication - This pertains more to Asana comments and emails. However, in general we found it is better to give more information than is needed (within bounds).