SCRUM - Agile Dev Methodlogy

[MattVoerman]

If you're into developing any sort of sizable web site/application SCRUM (http://en.wikipedia.org/wiki/Scrum_%28development%29) is a great methodology to take a look at.

SCRUM is part of Agile (http://en.wikipedia.org/wiki/Agile_software_development) which has been around for a few years, but is now becoming one of the preferred iterative development methodologies out there.

Whilst (generally) more applicable to enterprise sized applications, there's no reason you couldn't appy the same framework to web (site) dev - albeit it on a smaller scale.

For a quick (10 min), and very comprehensive, overview you should definitely check out this video (http://www.youtube.com/watch?v=Q5k7a9YEoUI)

All the cool kids over here in Silicon Valley are using it - so it's well worth a look in if you're serious about (web) application development.

[temp]

Please point said cool kids to http://agilebench.com. Works for scrum/XP/whatever, coming soon!

[Botman]

I looked at trying Scrum at my work, as my last job used it and it went quite well.

But the work we were doing was different. It was a single, relatively large software application compared to a mix of CMS-driven websites and web-based applications in the 5-figure price-range.

A lot of our clients want an 'accurate' quote for their website and aren't keen to give up any features they've asked for. So that immediately conflicts with a key principle of Scrum: flexible requirements.

So that's something to be aware of, depending on your client-types.

There are some agile points we have adopted though. For example, the daily, stand-up meetings; the whole 'what did you achieve yesterday', 'what are you doing today' approach; and letting the team decide who will work on what.

[ashul]

There are some agile points we have adopted though. For example, the daily, stand-up meetings; the whole 'what did you achieve yesterday', 'what are you doing today' approach; and letting the team decide who will work on what.

we are trying to use the above as well but found scrum more suited larger teams with well defined individual roles..

[madpilot]

we are trying to use the above as well but found scrum more suited larger teams with well defined individual roles..

Also, I've found it impossible to get hold of the client enough to have meaningful meetings. I'm not sure why they freak out when you ask them to come in for a stand up meeting every week...

[temp]

Also, I've found it impossible to get hold of the client enough to have meaningful meetings. I'm not sure why they freak out when you ask them to come in for a stand up meeting every week...

nah that's not a standup eh. Agile puts the customer in the team for a daily x-minute update. I wouldn't travel anywhere for a standup either.

A weekly hour-long status update is a different thing.. Maybe pitch it as a client demo or something instead?

[Botman]

Also, I've found it impossible to get hold of the client enough to have meaningful meetings. I'm not sure why they freak out when you ask them to come in for a stand up meeting every week...

Yeah I agree with you.

That said, having the client on the project team is always good. The trick is to put them in charge of testing (not the day-to-day stuff, but testing at milestones, etc), so they're involved in the application during its development. It puts some of the responsibility back on the client, and means they're not seeing the system for the first time when it's already 'finished'...

[tuna]

Yeah I agree with you.

That said, having the client on the project team is always good. The trick is to put them in charge of testing (not the day-to-day stuff, but testing at milestones, etc), so they're involved in the application during its development. It puts some of the responsibility back on the client, and means they're not seeing the system for the first time when it's already 'finished'...

Just don't ever rely on the clients testing. It will be extremely bias and is often seen as the best case scenario in terms of data collect. As well like the rest of the dev team, they become used to the system and frankly after a few test runs aren't much good at maintaining independent evaluation.

[ashul]

we are starting to move milestone testing to a dedicated resource on the team that has not had anything to do with the development in other words an actual in-house tester. This has improved UAT so much so that there is very little client change (in fact hardly any in the last 3 projects) - but that is another aspect of agile in that the client will have a good idea what you are building as they are more or less over your shoulder at all times

[ashul]

Also, I've found it impossible to get hold of the client enough to have meaningful meetings. I'm not sure why they freak out when you ask them to come in for a stand up meeting every week...
I borrowed a leaf from you for our weekly staff meeting! this morning it was done standing! What normally takes 1hr 30mins took 35 mins :)

[MattVoerman]

Also, I've found it impossible to get hold of the client enough to have meaningful meetings. I'm not sure why they freak out when you ask them to come in for a stand up meeting every week...

The client doesn't have to attend the stand-up (as generally it's an internal process), but has the option of listening (and not participating) in order to stay abreast of whats going on in the project. In most cases, the client 'dials in' on the meeting (via phone).

I borrowed a leaf from you for our weekly staff meeting! this morning it was done standing! What normally takes 1hr 30mins took 35 mins :)

That's the whole point of a stand-up. If people are standing, there's little incentive to waffle on about off topic banter. Participants are keen to get the meeting over and done with ASAP. FWIW daily stand-ups should be no longer than 15 minutes and cover only -

- what was worked on yesterday
- what will be worked on today
- and any blocks or obstacles.

Anything else is taken off channel and discussed outside the meeting.

[::Scott::]

We use axosoft ontime here for scrum. We dont really do the stand up meeting thing though. Instead we just batch work together into sprints etc., allocate them off and burn them down. Ontime is also used for our todo / bug / wish lists.

My biggest complaint with axosoft ontime is that the ontime desktop client takes ages to load, and there is no way to keep it in your system tray to keep it "always loaded". The screenshot snapping feature is hell cool though.

I think also its important not to pressure your developers when using the whole burning down thing. Because it induces excitement and gets the blood rushing for managers, I can see it turning like a "burn out" chart. And when things are rushed, they arent always done right / the best way.

[Botman]

Just don't ever rely on the clients testing. It will be extremely bias and is often seen as the best case scenario in terms of data collect. As well like the rest of the dev team, they become used to the system and frankly after a few test runs aren't much good at maintaining independent evaluation.

You're right in that I wouldn't expect a client to be testing all the possible cases for data-input/output and all that sorta stuff. That's the day-to-day testing that gets done as part of development.

But to ensure the system being built meets the client's requirements, getting the client involved during the project (not just at the end) is one of the best things you can do to ensure project success.

[ashul]

But to ensure the system being built meets the client's requirements, getting the client involved during the project (not just at the end) is one of the best things you can do to ensure project success.
I find them useful for the requirements review, scoping, wireframe/prototyping & UAT areas but they can prove a hindrance during actual development unless it is a truly agile process..

[ashul]

That's the whole point of a stand-up. If people are standing, there's little incentive to waffle on about off topic banter. Participants are keen to get the meeting over and done with ASAP. FWIW daily stand-ups should be no longer than 15 minutes and cover only -

- what was worked on yesterday
- what will be worked on today
- and any blocks or obstacles.

Anything else is taken off channel and discussed outside the meeting.
totally agree