Reply to: Scrum Master v Project Manager

[Lewis]

Can anyone recommend some good Scrum/Agile books?

[Lockhouse]

If they ask you for some extra stuff and you pull out the "what functionality would you like me to drop" line - they will go and ask someone else who is willing to tell them what they want to hear to get ahead of you. You risk getting sidelined.

Within reason I think its better to try "I can do all of that but quality will suffer in these areas". This is where you increase risk. Keep pointing that out during scrums. It's the managers call whether to take that risk and he/she should manage the risk by working out Plan B.

In theory, with Scrum the idea is it's the feature set that's the variable, not the quality or the time which are fixed. You do what you can, anything not done or completed in the Scrum goes back into the project backlog. It's the project owner who prioritises and maintains the list of stories.

Not saying that's what I do or what happens in the real world, that's just the theory.

[Freamon]

The idea of Agile and formal qualifications seems like a bit of a contradiction in terms.

[aussielong]

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.

If they ask you for some extra stuff and you pull out the "what functionality would you like me to drop" line - they will go and ask someone else who is willing to tell them what they want to hear to get ahead of you. You risk getting sidelined.

Within reason I think its better to try "I can do all of that but quality will suffer in these areas". This is where you increase risk. Keep pointing that out during scrums. It's the managers call whether to take that risk and he/she should manage the risk by working out Plan B.

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

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

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

[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

[minestrone]

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

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

[TheSurfer]

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

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

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

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

[Lockhouse]

Does it work in practice? Last place I was at it was a complete failure in a Business Intelligence team. Seemed to work for the Java boys in another team tho'

No idea. I think if you can keep the team focused it stands a better chance of working.