views:

582

answers:

8

What agile methodology would you recommend for a web-site shop?

We have a variety of small projects and a few large ones, teams are cross-project and they multitask. We are really interested in Scrum, but it seems that it would not apply to small projects (less than 2 weeks), which currently make up a lot of our time.

What alternatives are out there to implement agile principles in our situation?

+1  A: 

Try one methodology per project and see what works well.

Kevin Conner
+2  A: 

Scrum can certainly apply to two week projects. You can either shorten the sprint duration or do multiple projects per sprint.

Also, there's nothing that says you can't pick and choose parts of different methodologies to use in your project.

17 of 26
some ideas of the scrum might work such as the daily stand up face to face meetings, but I think concepts like paired programming in XP would be more helpful for small projects. And true "scrummists" don't like changing the time of the 2 week intervals.
stephenbayer
Actually, Ken Schwaber (one of the creators of Scrum) specifically says in his book that you should tailor the Scrum process (including sprint duration) to fit your team's needs.
17 of 26
I have to admit my shortest formal project to date has been 5 weeks, and I used a fairly strict XP method with that. Usually I work on 3 to 6 month projects with strict scrum. I haven't done micro (2 week) projects. I try to stay follow the methodologies strictly rather than mixing them up.
stephenbayer
I agree with 17 of 26. You can tailor the sprint duration. I can't cough up the reference since they are all at work, but I'm sure that I've read online and in several agile books that durations should fit your situation. We use 20 day sprints. Works perfect for us. Others use 14, some 30.
Mark
A: 

Scrum will not work for a small project like that. Since in it's definition scrum sprints are 2 weeks long. some variation of XP, or Extreme Programming would be much more suited. However, getting a project done in 2 weeks, if it is complicated, will require your developers to be extremely focused.

Also, with whatever methodology you chose, don't be afraid to modify the process to fit your team better.

stephenbayer
A: 

I think you should try like Kevin say some methodology to see how your current team work with it. Some person aren't very open to try XP or other new methodologies. You should also try different methodologies for your small and for you larger project. Methodologies for 2 weeks project of for 2 years projects can change. In a 2 weeks project you can have 1 iteration and you may plan for the whole 2 weeks at starts, this is something not possible for a 2 years projects.

Daok
+1  A: 

I'd second using Scrum even though your typical projects are small. Look at your sprints as being two, three or four days long. You can still incorporate the "lots of ongoing feedback" basis of Scrum into your project.

You wouldn't want to work on something for two weeks, only to have the customer say at the end "Oh, that's not what we were after at all!"

Have a listen to Ken Schwaber's short talk about Scrum over at IT Conversations which is full of great podcasts BTW.

Then I'd watch Tim McKinnon's talk on Agile over at InfoQ which is also full of great talks and interviews.

HTH.

cheers,

Rob

Rob Wells
A: 

I think that using TDD (test driven development) would provide a lot of benefits in these projects. it would help development and design. The unit tests could also be a "micro documentation" for implementation details and design decisions.

Dror Helper
+5  A: 

We started with Scrum because its formal structure (estimation, user story planning, task planning, daily meetings, retrospective) helped us get from our old methods to be more agile. We've now found that the 3 planning and esitmation meetings can be done on a task/user story basis in the morning meetings.

We have a large pin board and pin on index cards for each user story. The board is split into not started, in progress and done. We ensure that no task takes more than a day when we break it down, and we break down each user story in the daily morning meeting the day we are going to need it. This keeps us agile so that the list of "features" as user stories can then change without us spending time breaking it down into tasks. This ensure that two week projects can easily be handled in the same way that larger ones are too.

To estimate velocity we count up the cards at the end of the week to see how many task we've done. The downside is that release planning and velocity estimation is not as accurate as with Scrum but this hybrid XP methodology helps developers focus on tasks when ready and not waste too much time in meetings.

Having smaller tasks also promotes more regular commits to source control and combined with a build server and deployment scripts we can deliver a progression in the application once a day at least - great for getting feedback from the client. We also have weekly retrospectives too and have hired in an agile consultant for a week every 3 months or so to ensure we keep on the right track.

Paul Shannon
A: 

Scrum.

greetings

stoimen