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.


4 Answers 4


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.

  • 1
    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. Commented Oct 17, 2012 at 7:48
  • The link is not available anymore
    – Belgi
    Commented Apr 1, 2017 at 18:04
  • I fixed the link (edit pending review). The original page is archived at web.archive.org/web/20130619061255/http://… Commented Apr 2, 2017 at 8:19

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: http://www.mountaingoatsoftware.com/topics/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.

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).


You dont need to spend on hiring consultants to train you. you and your team just need to learn scrum ftom right sources.

scrum is ightweight framework so easy to leran the terminology but difficult to appreciate the concepts behind. so you may need the source that not only introduces the elements but also explains those 'aha' moments of understanding.

just to create a commitment on learning you can also enrol for a goid quality certification test like PSM.

I started my journey with PSM test and used the book Scrum Narrative and PSM Exam Guide. it was effective. all the best for your team.

  • "You dont need to spend on hiring consultants to train you.": +1 What is now called agile, 20 years ago was called "common sense" and every experienced programmers just applied it without the need of expensive external consultants. Common sense is acquired by experience, by trial and error, and by using your brain during the process. Agile gives managers the illusion that by hiring a consultant they can buy a package that will automatically solve their problems. IMO the best way to be "agile" is to forget about agile consultants and start using your own brain.
    – Giorgio
    Commented Apr 1, 2017 at 20:00
  • 1
    @giorgio I've never really understood why agile consultants are even a thing. As you say, agile is all about common sense, and the founders of the movement have always been clear that that was what they were trying to achieve. There were never XP consultants, but then along came Scrum and it's certification schemes and suddenly agile consultants are everywhere....
    – Jules
    Commented Apr 2, 2017 at 17:27
  • @Jules: Another common "agile" motto is: we do not do waterfall. Well, way before I heard the word agile, really few people were using waterfall. I studied computer science during the nineties and we all just knew that you cannot strictly follow waterfall or any other methodology, but you take what you need and adapt it to your needs. But here come agile people and teach you that you have to abandon the old waterfall model that almost nobody was using in the first place. I think most of the movement is just about making money selling certifications and consulting.
    – Giorgio
    Commented Apr 2, 2017 at 18:04

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