Scrum Master v Project Manager

[original PM]

Although you can use days the shortest\easiest time period in Agile is the Storypoint. Using storypoints is the easiest way to estimate accurate velocity and burndown. You can tell I just came off the course.

Thing is with story points with a new team you will not know in your first timebox whether there estimates of story points are actually any good!

Also lets say you give a chunk of work 10 story points but that includes the dev, testing and rework then after 5 story points the dev maybe done but th tester would prefer to play abit og COD online rather than test.

If you do not have the daily stand up you may get to the end of those ten days and find that only the dev has been done so you need to jump on the tester (in this case) on day 5 and not get to day 10 before findng it all ground to a halt on day 5.....

It does depend on the set up but I believe the Agile/scrum standups do increase the chances of work being delivered to the correct quality and on time.

[malvolio]

What' that old adage about "If you don't know where you're going, any route is good enough"?

Scrum works for single threaded, single-team development projects. As soon as there's an inter-project dependency, it breaks (or is so fragile it may as well break). Hence, use it where appropriate and nowhere else.

And let's be clear - it's not a robust project methodology. Scrum Master and PM are different skills for different purposes. Only one can do the other's job.

[Lockhouse]

What' that old adage about "If you don't know where you're going, any route is good enough"?

Scrum works for single threaded, single-team development projects. As soon as there's an inter-project dependency, it breaks (or is so fragile it may as well break). Hence, use it where appropriate and nowhere else.

And let's be clear - it's not a robust project methodology. Scrum Master and PM are different skills for different purposes. Only one can do the other's job.

Bl1mey I agree with most of that! Certainly inter-project dependencies present a significant risk to using scrum if not managed correctly.

[TheSurfer]

This Scrum stuff sounds way too much like hard work for me.

[d000hg]

From my experience, the people who resist these the most tend to be the lazy and disorganised.
If you're on top of your work then these sessions are a good opportunity to make sure that someone else isn't dragging you down (without the rest of the team knowing about it)

From MY experience, the people on top of their work resent these pointless meetings which stop them getting work done.

[minestrone]

Scrum is just the current serving of tripe in the never ending buffet of tulipe software development methodologies.

[SimonMac]

Scrum is just the current serving of tripe in the never ending buffet of tulipe software development methodologies.

And there in lies the money

[VectraMan]

This Scrum stuff sounds way too much like hard work for me.

We're meant to be doing Scrum at PermieCo, but to be honest I just ignore the whole thing and get on with my job.

Cynicism aside, I quite like Agile, and think daily meetings work well, but it works best developing an existing system, not doing a major new bit of development. But Scrum just seems to result in everybody looking for small tasks that can be done within a sprint and putting off the important stuff; I'm not sure why anyone things that's a good idea.

[eek]

But Scrum just seems to result in everybody looking for small tasks that can be done within a sprint and putting off the important stuff; I'm not sure why anyone things that's a good idea.

That's the problem of moving to a short time scale. given a two week deadline you want to ensure you deliver something at the end of the deadline so you fight to grab and own the easy things you know can be delivered.

Of course the scrum master should be grabbing the best developers and making them do the larger pieces separately but that would never work with most contractors.

[Zippy]

What I'm hearing here is customers and dev teams not understanding how you construct a sprint cycle.
You shouldn't have a sprint deadline imposed unconditionally. You should get your customer to tell you what elements from the product backlog they want in that cycle, you estimate it, then you tell 'em how long it will take.
They come back and say "that's too long to see something" (I know, don't get me started) so you ask them what functionality they want to take out to bring it in within their time frame.
It can be tough (and you have to be), but that's how it should work. No victimhood allowed. No sirreee.