Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a few months, a friend will establish his startup software company, and I will be the software architect with one additional developer. Though we have no real day-to-day experience with agile methods, I have read much "overview" type of material on them, and I firmly believe they are a good - if not the only - way to build software. So with this company, I want to go for iterative, agile development from day 1, preferably something light-weight.

I was thinking of Scrum, but the question is: what is the best way for me and my colleagues to learn about it, to introduce it (which techniques when etc) and to evaluate whether we should keep it?

Background which might be relevant: we're all experienced developers around the same age with similar professional mindset. We have worked together in the past and afterwards at several different companies, mostly with a Java/.NET focus. Some are a bit familiar with general ideas from the agile movement. In this startup, I have great power over tools, methods and process. The startup's product will be developed from scratch and could be classified as middleware. We have some "customer" contacts in the industry who could provide input as soon as we get to an alpha stage.

share|improve this question
up vote 3 down vote accepted

Disclaimer: I have never done any formal Scrum training (although have worked on a couple of Scrum (based) projects so far and like it very much). So you may prefer opinion from someone better versed on the subject.

IMHO if you have read the "obligatory" material such as the Scrum book, you probably know enough about it in theory. Plus, with your sw development experience, you understand how it works and what makes it work in practice. With a team of two, the simplest way is to just have the other guy read the relevant material too, then start with a discussion about your SDLC. Discuss any unclear parts or question either of you have, and work out your own process. It may be an exact Scrum, or a hybrid - do whatever fits you (your team, your project(s), your environment) the best. Then start doing it immediately, and keep reviewing and adjusting as you go - this is actually the most important gist for long term success.

You may consider taking a formal training or workshop with an experienced Scrum / Agile consultant (if there are any at reach where you live). However, for a startup team of two, this may be an expensive overkill.

Btw for further study, I found a reading list on Scrum Alliance's site.

share|improve this answer
I just comment to highlight again that review and adapt (learn) is the most important part of Agile. Do that and you'll be fine if you know the theory. – Patkos Csaba Oct 17 '12 at 7:48

No need to spend alot of money to learn scrum man. Just do your work and Im sure you can learn all you need.

Most importantly I just want to say keep it simple. Allow your process to grow organically. Remember you want to be able to embrace change and produce working software early and often. Face to face standup meetings and pair programming are very helpful.

I know with .net their is Scrum Project template that you can use that comes with Team Foundation Server. Not sure if their is the same for JAVA but I would imagine so.

The basics on scrum: There is way more but that website is a good start.

These are some tips I have just come up with:

  1. Define features and break them down into user stories.
  2. User stories are cataloged and placed in backlog.
  3. Iterate over group of users stories.
  4. Standing meeting every 2-3 days.
  5. Deliver working software to customer to test every 3-6 weeks.
  6. Use pair programming to break up stagnation of hard problems by working together.
share|improve this answer

My suggestion would be for you to acquire budget for yourself to attend formal scrum master training and certification session with the scrum alliance. If this budget is not approved then try to acquire all the materials for this training, go over them yourself and see try to evangelize the Agile process to your team.

One other thought: Although anyone in the team can take up the role of a scrum master, it is probably not the best decision for the architect to be in this role. It's not that the architect is not suitable for it, but the amount of work the architect has to do outside of being a facilitator for the team is going to conflict with the scrum master role (at least in my experience).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.