GeeCON Prague 2014*
The moose likes Agile and Other Processes and the fly likes SCRUM.... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "SCRUM...." Watch "SCRUM...." New topic
Author

SCRUM....

Vijay Vaddem
Ranch Hand

Joined: Feb 13, 2004
Posts: 243
How this is different from RUP??

is anyone following this methodology?? if so,
please share your experiences...

Thanks
Vijay
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I only know the basics of Scrum, but it's a very "small" process that uses a feature backlog (a todo list of sort) and time-boxed iterations. By "small" I mean that it doesn't say much about how the project should go about those iterations and instead chooses to "wrap" other, more detailed processes such as XP.

You can read more about Scrum at ControlChaos.com.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
Originally posted by Vijay Vaddem:
How this is different from RUP??

is anyone following this methodology?? if so,
please share your experiences...

Thanks
Vijay


I see it as process under RUP or XP umbrella.

1. 30 days iteration in development(agreed requirements among developers [90 days iteration for production release(RUP or XP iteration) so three scrum iteration to each release iteration])
2. Developers meet every morning for 10 minutes (discuss what did everyone completed from yesterday's goals and what is their goal today any issues or problems blocking their work, is there any posibility that developers blocking each other etc.)
3. automated nightly builds for checked in code.
4. Maintain bugs and enhancement databases. Have business people prioritize them. incorporate bugs related to each business process that developer is working on.

Biggest Issue encounterd was human factor. Some developers are slow and define their goals too aggressively, ends up with very small accomplished goals and feel inferior during morning meeting.

from Project management point of view it worked out very good as every one is in loop as far as what others are working on goes.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
SCRUM is a project management process - it can be applied to a wide range of projects, not only software development.

Extreme Programming basically incorporated SCRUM as its planning process (with some minor modifications).


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Udayan Patel:
Biggest Issue encounterd was human factor. Some developers are slow and define their goals too aggressively, ends up with very small accomplished goals and feel inferior during morning meeting.

Note that the feeling would probably be even bigger if you'd pull a one-year project in a single sprint and then hold that morning meeting only to realize that someone has written Microsoft Office from scratch while the other managed to produce a notepad without a "save" feature

What I'm trying to say is that the bigger the gap in time gets, the bigger the gap in accomplishments gets. And, with a slow feedback loop, the gap probably doesn't get smaller next year either.
Don Stadler
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
SCRUM means that your project manager gets to humiliate you every morning if your hash isn't sorted all the time. Be prepared for many late nights....
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Don Stadler:
SCRUM means that your project manager gets to humiliate you every morning if your hash isn't sorted all the time. Be prepared for many late nights....


Huh? If that is your experience, your manager doesn't understand SCRUM, I'd think. Would you care to elaborate?
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
Originally posted by Don Stadler:
SCRUM means that your project manager gets to humiliate you every morning if your hash isn't sorted all the time. Be prepared for many late nights....


odd!!! The whole idea to have scrum is that you don't spend late nights at work.
Don Stadler
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
Originally posted by Ilja Preuss:


Huh? If that is your experience, your manager doesn't understand SCRUM, I'd think. Would you care to elaborate?


I'd agree that he didn't understand SCRUM. The targets that were set were optimistic to say the least. Anyone who gave a realistic estimate (especially given a massive learning-curve on that project) was met with open skepticism & a point-by-point reduction of the estimate, until you gave up and gave him the figure he wanted.

When the targets weren't made the 'incompetent' people were given a grilling in 60-90 minute morning SCRUM meetings. It got to the point where I would do anything to avoid the morning humiliation - staying till midnight if that's what it took. Didn't work of course, the best I could ever do is take the edge off.

I believe that 80% of the team were shown to be incompetent by this process - including the manager himself! The last I heard most of the 80% (and a few hired later) were fired or left the job.

The clearest thing I learned about SCRUM is that the management style has to be very, very, very cool for it to work. I don't mean cold, but the manager has to be willing to take people's word for things. His or her style has to be to seek to find or give help when a problem is encountered and not to guilt people over things they don't know. I think finding proper SCRUM managers may be the hardest part, although I ran the SCRUM once or twice and actually held it to 15 minutes without playing the blame game. I'd do SCRUM again if I could run it or if someone I trusted ran the Scrum. There was another team lead parallel to us who did it absolutely right - and he wasn't even a true believer in SCRUM!

As it was it was the worst pressure cooker I've worked in for a decade or more....
Don Stadler
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
Originally posted by Udayan Patel:


odd!!! The whole idea to have scrum is that you don't spend late nights at work.


Udayan, in my experience SCRUM was like being on final deadline - 365 days a year. Think you could handle that?

I have mixed feelings about SCRUM. I thought it was great until I worked with it. If your manager is a control Nazi SCRUM will give him the tools to make your life a living hell - until you quit.
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
Originally posted by Don Stadler:


Udayan, in my experience SCRUM was like being on final deadline - 365 days a year. Think you could handle that?

I have mixed feelings about SCRUM. I thought it was great until I worked with it. If your manager is a control Nazi SCRUM will give him the tools to make your life a living hell - until you quit.


Its still odd that PM conducted the morning meetings, Its a plain development thing and PM shouldn't have been involved. Usually tech leads heads these meetings and keep track how much work has been done for a sprint and how much is left and what will be done when kinda things. And then go back and fills PM up on status.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
The primary site, IMHO, for Scrum is http://www.controlchaos.com/

I would characterize it as a process which focuses on agile project management and requirements management techniques. It works spectacularly well with XP, and last I heard Mike Beedle was working on writing up XBreed which is a combination of the two.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Also, you might find http://www.agiledata.org/essays/differentStrategies.html#ComparingMethodologies to be of interest. It compares and contrasts different methods.

- Scott
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Don Stadler:
I have mixed feelings about SCRUM. I thought it was great until I worked with it. If your manager is a control Nazi SCRUM will give him the tools to make your life a living hell - until you quit.


Well, what your manager did was misusing the *name* SCRUM. Real SCRUM really doesn't allow that behaviour.

First, though the manager might set the deadline, *the developers* decide how much they can do in a sprint. The only way for the manager to change what will be done is by *reordering* the product backlog, that is, by changing the priorities of the features. How many of them will be done is important information to him, but nothing he has the authority to decide about. (Well, he might try to ask the developers wether giving them more resources gets things done faster, of course.)

Second, only developers are allowed to speak during a Daily Scrum (the Stand Up Meeting in the morning). The purpose of the meeting is for the developers to tell how things are going, to plan what to do for the day - and to request help from their coworkers and management. http://c2.com/cgi/wiki?DailyScrum
Don Stadler
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
Originally posted by Ilja Preuss:


Well, what your manager did was misusing the *name* SCRUM. Real SCRUM really doesn't allow that behaviour.

First, though the manager might set the deadline, *the developers* decide how much they can do in a sprint. The only way for the manager to change what will be done is by *reordering* the product backlog, that is, by changing the priorities of the features. How many of them will be done is important information to him, but nothing he has the authority to decide about. (Well, he might try to ask the developers wether giving them more resources gets things done faster, of course.)

Second, only developers are allowed to speak during a Daily Scrum (the Stand Up Meeting in the morning). The purpose of the meeting is for the developers to tell how things are going, to plan what to do for the day - and to request help from their coworkers and management. http://c2.com/cgi/wiki?DailyScrum


That's true. This guy is a developer who had his first management role as a team lead. A little difficult for him as two of the team members were actually far more experienced as team-leading, and a third guy is a wizzo code geek. The team lead was intensely ambitious and pushed the envelope on the goals-setting. Since he was was both a developer and the manager (and the other team members didn't know SCRUM) he could get away with it.

As I said before there was a big learning curve on this for 80% of the team. On about 60% of the technology as well as Scrum. So we didn't know enough to push back. Basically if we couldn't 'prove' that it would take longer his figure got put down. Signed in blood it seemed.

The other big mistake he made was introducing fear and guilt in a big way. When developers asked for help and advice from him we tended to get it - but reluctantly. When we asked others he was always watching - and judging. We'd hear about it at SCRUM the next morning!

The crazy thing was there was this other team lead for another group who also did SCRUM without any of this crap. He knew very little about it (the nazi was the one pushing it), but in my book he did it just right. 5 minute meetings, take anything else offline, no guilt. I think he was actually younger than the nazi, but his instincts were completely sound.

My point is that SCRUM can be a tool used for good or for ill. Seems to me that if used well it might improve things maybe 15-20%. Used badly and you can drive everyone into their own corner and make the project drag. After losing 60% of the initial team and on the way to losing one replacement I wonder if upper management has gotten the point yet and fired or demoted this fellow?
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
Originally posted by Don Stadler:


Basically if we couldn't 'prove' that it would take longer his figure got put down. Signed in blood it seemed.


Answer to this is TDD. Make sure your unit tests are already in place let these tests determine how long would it take you to make changes to something.

Originally posted by Don Stadler:

My point is that SCRUM can be a tool used for good or for ill. Seems to me that if used well it might improve things maybe 15-20%. Used badly and you can drive everyone into their own corner and make the project drag. After losing 60% of the initial team and on the way to losing one replacement I wonder if upper management has gotten the point yet and fired or demoted this fellow?


Never happens, People like this knows how to deal (old fashioned *** kissing) with upper management as upper management doesn't know much about technical details and don't want to. All they are interested in is getting stuff done in limits of budgeted amount. Not sure how big the organization we are talking here but in big corporations the only time upper mangement comes to know when they get notified by HR.
A famous saying: one bad fruit in a basket make all good fruits go bad.
Don Stadler
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
Originally posted by Udayan Patel:


Answer to this is TDD. Make sure your unit tests are already in place let these tests determine how long would it take you to make changes to something.


Yep. We were doing that too. Reading the Kent Beck book and getting quizzed bythe team lead was one of the Scrum targets.

Everything from the ground up of course. Hibernate, TDD, Ibatis DAO, Commons Validator, Maven, Cruisecontrol, etc. If it was best-practice the project had it. Listen the guy wasn't all bad. He had a lot of good ideas and if he'd let his team breath a little many good things would have happened. We had a good mix of tools and methodologies. Trying to do too much too fast can be a problem in itself.

You should perhaps bolt no more than one or two 'new' things on per sprint. As it was a bunch of things had to go right for the sprint to make it's target, and none of us really had the chance to absorb the new stuff. When I left I spent a month or more absorbing the tools I'd worked with on my own project. Great stuff. If someone had described it to me I'd call it a dream project. It could have been. They should have made this guy technical lead and let one of the older farts the scrum lead.

Originally posted by Udayan Patel:

Never happens, People like this knows how to deal (old fashioned *** kissing) with upper management as upper management doesn't know much about technical details and don't want to. All they are interested in is getting stuff done in limits of budgeted amount. Not sure how big the organization we are talking here but in big corporations the only time upper mangement comes to know when they get notified by HR.
A famous saying: one bad fruit in a basket make all good fruits go bad.


I don't think so. I think you have the wrong idea of the guy. He wasn't much of an ass-kisser, and the upper management were watching like a hawk anyway. If the project wasn't getting results they were ready to cut. Small organization. Some of the managers were pretty good. They were in a financial squeeze themselves because of outsourcing taking their markets and a project coming to an end.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Don Stadler:
You should perhaps bolt no more than one or two 'new' things on per sprint. As it was a bunch of things had to go right for the sprint to make it's target, and none of us really had the chance to absorb the new stuff.
I've often heard suggestions similar to "one new thing at a time" -- both in software development and in other contexts. It makes it a lot easier to analyse whether the observed effects after the addition were in fact due to the new thing or whether it was something else.

Then again, I wouldn't make it a rule without exceptions. Common sense over thick law books.
Don Stadler
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
Originally posted by Lasse Koskela:
I've often heard suggestions similar to "one new thing at a time" -- both in software development and in other contexts. It makes it a lot easier to analyse whether the observed effects after the addition were in fact due to the new thing or whether it was something else.

Then again, I wouldn't make it a rule without exceptions. Common sense over thick law books.


Not a rule exactly. But it's common sense that steep learning curves and tight inflexible deadlines don't interact well. Particularly within a sprint timeframe, because there is no give buit-in. In this case we had steep learning curves on maybe 60% of the technologies we were using. Maybe 80%. I remember one guy who was obsessing about Hibernate and wanted to use JDBC. I personally saw it as a wash even it being my first project with Hibernate. But I could see his point.

I have a bit of a laugh for you. I talked to a recruiter today about a consulting gig at an xP shop. xP, TDD, SCRUM, the whole deal. And it sounded good!

You'd think I'd have learned after getting burnt the first time, but apparently I'm more of an optomist than that. I wonder whether I'm not drawing to an inside straight, but I'm bidding on that contract. A good chance I'll be working there next....
 
GeeCON Prague 2014
 
subject: SCRUM....