Tools

You definitely will need source control. Preferably one that includes a web interface so that every day you can start off by seeing what people have checked in recently.

You will need a team space where your developers, QA, and product owners can work together to deliver a product.

You will need a continuous integration server so that you’re constantly running tests against your software.

You will need an automation framework of some sort, that lets you easily write automated acceptance tests. It doesn’t have to be fancy, and could be built on top of the various *unit frameworks, but you need something.

You need a team wiki. Many source control systems come with one. You need a quick and easy way to create internal documentation.

You need an issue tracker. Many source control systems come with one of these, too. You need a way to track defects. You can use sticky notes on a whiteboard if you’re good about keeping your bug count to a minimum. Consider choosing an integrated wiki, issue tracker and source code control system in one.

Equipment

You will need whiteboards and sticky notes. There are many opinions on this, but in my experience nothing works better than physical boards and story cards. You can use an electronic story board, of course, and ultimately it boils down to what works best for your team.

Procedures

You should start by following all of the scrum rituals. That’s not to say they are the best, but before you can run you need to walk. Start with two week sprints, do your standups every day, your retrospectives and demos every two weeks. Be religious about it, until the point comes where you can decide what works for your team and what doesn’t.

You must build your software from day one to be buildable in a single step and be able to be automatically deployed. You don’t want your development team to have to spend time manually building or installing software all the time. These features are almost impossible to add after the fact, it needs to be part of the culture from day one.

Roles

You need a product owner. This is the person that straddles the line between the customer and the development team. They should be technical enough to have meaningful conversations with the development team, but they also need to know the product space and be able to speak intelligently with customers.

You will need developers. Ideally these will be dedicated 100% to creating the product. A developer shouldn’t also be a product owner, scrum master, or manager.

You will need QA developers. These people are the advocate of the customer. They are responsible for guiding the team toward developing high quality software. They aren’t just testers, they work with the team to understand what is being developed, and help the team build testable software. Ideally these people are software developers who have a passion for testing, since a large part of the role should involve writing automated tests and maintaining the testing framework.

Optionally, it would be good to have a dedicated scrum master. Their job is to focus on the productivity of the team, rather than on the product being built. Having someone in that role will help the team come together and work at their peak.

Culture

Above all, you need to build a culture that understands that software development is all about the customer. Nobody will buy your software because they want to use your software, unless you’re creating a game. Instead, they use your software in order to accomplish some other task. Your job is to deliver software that makes completing those tasks easier.

You need to foster a culture of communication, and one where software quality has top priority. That means each story is fully tested before moving on to the next. The idea that you’ll test something in a final sprint needs to simply be unacceptable to everyone on the team.

Finally, you need a culture that values a 40 hour work week. While a can-do attitude is important, and people must be willing to roll up their sleeves and work extra hours on occasion, those extra hours must be the exception rather than the rule. Software development is largely a creative task, and you can’t be creative when you are overworked. Happy team members are productive team members.

While I won’t argue with any of the suggestion @BryanOakley has already put forth, I would like to point out that in the end, the tools don’t really matter. What matters is the people you have working on the project.

Each member of the team needs, first and foremost, to be a good communicator. They need to be able to talk to the customers–and each other–and in order to understand what is to be done and allow others to understand what is being done. If the communication is there, you are 80% of the way to being agile.

The other 20% is that each team member needs to be able to pick up whatever ball lands in front of them and run with it. If someone has “downtime” they should automatically be looking to see how they can help the other members.

Alistair Cockburn calls agile software development “the Cooperative Game” for a reason–it is about people cooperating to achieve something great. “Individuals and interactions over processes and tools” is the first value of Agile development.

I think there is no clear answer but here are some thoughts:

• Process: Right at the beginning, most likely the team size is so small (<=3 developers) that you don’t need a well-tuned process like SCRUM. It will become more important if you become successful and grow, but I wouldn’t consider it crucial at the start.

• Tools: Depends on want you want to do and what your experiences are. Startups have no legacy code, so they will can generally go for newer technologies. (Who knows what that will be in the next year. Once it was Rails, now it seems to be NodeJS.)

  When it comes to programming languages, the only safe recommendation is to value productivity over performance (e.g., Ruby, Python, Javascript/coffescript instead of Java or C++).

• Practices: You should strive for as much automation as possible. You will need it later anyway and it will help you right from the start. Automated testing is a must, and the setup and deployment of your applicaton should be easy. Put your configuration files under version control, not only your source code. Configuration management tools can also help (e.g., Puppet, Chef).