|
Translation: 'snot my fault!
Unfortunately, scrum relies on everyone contributing, and gives developers much more control over what they do and how they do it, so if it doesn't work for you, it is because you are not making a commitment to, and taking responsibility for, producing the best possible product -- perhaps because you're too busy looking for other people to blame.
i.e. It is your fault. If you were to put customer needs and the quality of the product before your little character-assassination games, it would work well for you, too.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Unfortunately, scrum relies on everyone contributing
I didn't say it didn't. But that is true of any management decision - regardless of its merits it can't succeed if the rank and file do not do it.
Mark_Wallace wrote: so if it doesn't work for you, it is because you are not making a commitment to,
and taking responsibility for, producing the best possible product -- perhaps
because you're too busy looking for other people to blame.
Complete and utter nonsense.
I have been a proponent of process control for a very long time. That includes promoting it, contributing to it, participating in committees, providing education, etc. And reading a great deal about different methodologies and ways to succeed and fail. At several companies I was the ONLY one providing guidance and formal process.
And that dedication is the reason I understand what process control is supposed to do and why it fails to succeed.
Mark_Wallace wrote: It is your fault.
AGAIN provide the metrics that demonstrate that it is succeeding where you are.
If you do not have the metrics then you have nothing more than an emotional reaction which is no more meaningful than puppy love.
|
|
|
|
|
Bored with you, now. Your arguments aren't intelligent enough.
Troll someone else for a while.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Bored with you, now.
But not so bored that you felt you still needed to take time to denigrate.
Mark_Wallace wrote: Your arguments aren't intelligent enough.
You mean you can't understand them (yes I can denigrate as well.)
And given that you completely ignored my comments about metrics twice I am rather certain now that you have none.
|
|
|
|
|
That doesn't sound like SCRUM to me. Somebody is faking it.
Anna ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Everybody in my life is faking it recently. Does that mean its me? 
Hogan
|
|
|
|
|
Only if you don't call their bluff!
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
This is pretty much my experience with SCRUM too.
The main things that impeded our process:
-SCRUM for a large team does NOT usually work well. Say each person takes a time frame of 3 min on average, a team of 10 people will already use up 30 min SCRUM time. Hard not to zone the hell out, especially if the talker is going on about unnecessary details and blabbing the world away. We had a team of just under 20, and our scrum meetings occasionally went over an hour.
-Developer pride... no one likes to admit that they're having problems with an issue in front of THE WHOLE TEAM. I guess the point is to encourage openness but again, it doesn't work unless if everyone is open about their problems, but how does one really know if the other person is being open or not?
-Productivity scores were okay in usefulness at best. If we couldn't finish something, the scrum master would just assign more hours to it, or put it on the next sprint, which doesn't really help for productivity. If things were going bad for the sprint, it can't always be helped, because things don't always go as planned. Forcing things to happen in development is a pretty bad idea.
-Geographical division of developers. Yes there is google hangout/skype, but it's hard to be open to people who you don't even see in person.
-Production issues... take priority and mess up sprint planning. Sprint failed. These prod issues usually end up taking a huge chunk of scrum time too.
Don't get me wrong, I know SCRUM does work, but it only works if done properly. I love hearing what other people are working on, but at the same time there were countless scrums where I could have used that 40 min - 60 min time period to do something more productive. SCRUM needs to be short, and done in scope (What was done yesterday, today, need help?).
|
|
|
|
|
Can I ask did you bring up these issues in a retrospective for the team to discuss?
|
|
|
|
|
We're still on sprint 1. Our retrospective is this coming Friday. I've been talking to the decision makers in our group separately about my concerns, so we'll see what happens...
|
|
|
|
|
I didn't bring it up because I was only a co-op/intern student, and it was also my first time with SCRUM process. I wasn't sure what SCRUM was supposed to be like at that time.
However, my current company is also planning to start SCRUM, so I'm hoping we'll do it right. 
|
|
|
|
|
Silvabolt wrote: ...so I'm hoping we'll do it right.
Money bets favor that it won't be.
|
|
|
|
|
10 to 20 people is too many for one scrum team. When the group gets this large, it must be broken down to teams of 7 (+/- 1). Then, each group must have a leader. The scrum should never take more than 15 minutes. Each person should tell what he/she did, is going to do, and the roadblocks faced. Then each group leader meets with the other group leaders to give the details (a high level scrum).
If your project is this large, break it down to a more manageable team size. Otherwise, it gets too unwieldy and useful time is lost.
|
|
|
|
|
Beats ours -- our daily fifteen minutes have been scheduled for three times a week for an hour. 
|
|
|
|
|
I've suggested this, but 2x Tue/Thu. So far they don't want to change. How is this working out for your group?
Hogan
|
|
|
|
|
SCRUM was one of the best environment I've worked in.
Without knowing name, place and context, I can surmise that the person running the show has no clue about SCRUM. Yes, SCRUM is about self - organizing but in this context, it is a buck-passing game. Either you are surrounded by perennial variety of developers or you've gotten clueless project manager or both.
If you care about the company and project, take charge of situation but be prepared for political aftermath and resultant consequences
|
|
|
|
|
I think a few people on the group do know about SCRUM, but the group as a whole is very new with it. I still need to give it time, but this post is about my initial reactions. I'm hoping that I can post a follow up about how good it is in a few months.
Hogan
|
|
|
|
|
Where is you company based? What line of work are you in? (I mean the industry vertical that your s/w product is aiming at)
|
|
|
|
|
ExcellentOrg wrote: SCRUM was one of the best environment I've worked in.
How many formal process control methodologies have you worked under for real company projects?
How large are the teams both for your current success and other failures?
ExcellentOrg wrote: or you've gotten clueless project manager or both.
SCRUM doesn't define a "project manager" and in normal business practice the role of "project manager" is not one that controls people but instead manages tasks. Perhaps you meant something more general like "manager".
|
|
|
|
|
jschell wrote: ExcellentOrg wrote: SCRUM was one of the best environment I've worked in.
How many formal process control methodologies have you worked under for real company projects?
How large are the teams both for your current success and other failures?
I have worked in a few; Change Control; Waterfall (aka SDLC); In my very first SCRUM project, team size was 5; In second project, it was 20+. In SDLC, actual team size were in 100s but individual tasks were granulated "fine" so one rarely worked with more than 3 ppl at a time. Change Control was the weirdest formal mgmt one: On some days, I had so much work that I would not have time for lunch; On other days,
I'd be free from 9 to 5 and would find it hard to kill time at work.
All said and done, SCRUM does rely on relative honesty of all Project stake holders....
Currently, I run my own company and work solo but I do hire freelancers at which point, I use ideas I learnt for SCRUM.
SCRUM doesn't define a "project manager" and in normal business practice the role of "project manager" is not one that controls people but instead manages tasks. Perhaps you meant something more general like "manager".
Yes. Project Manager is more of a formal organizational designation. SCRUM keyword for the same role is
"Scrum Master". More often than not, that responsibility falls on heads of Project Manager or a Tech Lead.
|
|
|
|
|
snorkie wrote: I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time.
It's not uncommon for a company to need 1-2 years (empirical numbers based on my own an my friends companies) before feeling effective in doing Scrum.
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
The desire is to make software development function like other manufacturing things of the past ... and it just ain't gonna happen until the robots are doing the work. SW dev is still a very new industry; and it changes every week. The work I was doing from '88 - '95 was very much agile but we didn't call it "agile" - we called it "let's get this stuff out there now" (it was online work prior to the www coming into its own). Since then I've done agile and waterfall and tequila-driven-dev and ......
I'm now working for a [very large] company and Agile Dev is the latest and greatest NEW thing!! It's wonderful! Our standups are via webex (as I type, there are 12 other people on the call); I'm muted. Basically, we spend 3 hours/week with this; I'd estimate about 18% efficiency. But, it's what they want to do; I get paid by the hour - their call.
|
|
|
|
|
It seems like the team is still getting used to the SCRUM mentality but as with most projects, there's probably little time to waste on them getting up to speed.
In reply to your original complaints and a couple of things that will help the scrum run better are:
1. Would any self organizing team of developers actually plan to meet every day?
A. Yes, the team need to meet everyday so they are fully aware of where they are in the development process and where their team mates are. They need to be made fully aware (usually by the scrum master) of what each meeting will focus on and what is expected of them.
2. About half of the 15 minute morning morning consists of, "Lets have a Meet After to Discuss". Half the team stays after the meeting every day. How about just discussing it now and getting it over with?
A. If they are having to have follow on meetings from the scrum, these should be formalised so that the results of the meetings can be shared at the next day's scrum. This will make sure that everyone is fully aware of any potential issues that could impact on their work and as they will have to put more into it than just chat for a while they will probably cut down on the amount of "discussions".
3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday
A. This needs to be addressed, if there is no progress from one scrum to the next then the project is essentially stalled. If they are saying nothing has changed since yesterday then challenge them on why there is no change and what they are doing to address this. Whatever you do don't let this carry on. It is counter productive and other team members will start to get the impression that they are either doing all the work when others aren't pulling their weight or they will take it as the norm and just stop making progress on their part.
From experience the simplest way to keep a scrum going is:
1. Give an update of where the project is along with any priorities.
2. Each person says what they accomplished yesterday and what they will accomplish today.
3. Everyone has a say and they need to question or comment on anything they don't understand or agree with.
4. The scrum leader has to keep the scrum as short as possible but at the same time covering everything that needs to be discussed. If the team is large, make certain people responsible for giving the updates rather than everyone chipping in.
5. Make sure that you thank everyone for their work and contribution to the scrum.
modified 10-Oct-13 16:09pm.
|
|
|
|
|
 Member 8261648 wrote: It seems like the team is still getting used to the SCRUM mentality but as with most projects, there's probably little time to waste on them getting up to speed.
In reply to your original complaints and a couple of things that will help the scrum run better are:
1. Would any self organizing team of developers actually plan to meet every day?
A. Yes, the team need to meet everyday so they are fully aware of where they are in the development process and where their team mates are. They need to be made fully aware (usually by the scrum master) of what each meeting will focus on and what is expected of them.
2. About half of the 15 minute morning morning consists of, "Lets have a Meet After to Discuss". Half the team stays after the meeting every day. How about just discussing it now and getting it over with?
A. If they are having to have follow on meetings from the scrum, these should be formalised so that the results of the meetings can be shared at the next day's scrum. This will make sure that everyone is fully aware of any potential issues that could impact on their work and as they will have to put more into it than just chat for a while they will probably cut down on the amount of "discussions".
3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday
A. This needs to be addressed, if there is no progress from one scrum to the next then the project is essentially stalled. If they are saying nothing has changed since yesterday then challenge them on why there is no change and what they are doing to address this. Whatever you do don't let this carry on. It is counter productive and other team members will start to get the impression that they are either doing all the work when others aren't pulling their weight or they will take it as the norm and just stop making progress on their part.
From experience the simplest way to keep a scrum going is:
1. Give an update of where the project is along with any priorities.
2. Each person says what they accomplished yesterday and what they will accomplish today.
3. Everyone has a say and they need to question or comment on anything they don't understand or agree with.
4. The scrum leader has to keep the scrum as short as possible but at the same time covering everything that needs to be discussed. If the team is large, make certain people responsible for giving the updates rather than everyone chipping in.
5. Make sure that you thank everyone for their work and contribution to the scrum.
Loved your advice!!!
|
|
|
|
|
My experience is that the daily standup is a huge time waste. First, unless you force all developers to start at the same time, someone has to interrupt real productivity for the meeting. Further, if you have correctly sized teams, the need to give each other updates is a symptom of poor team cohesiveness. You have a board showing who is doing what and you should talk to each other more than once a day. As for the other people? I don't get why all developers should be interrupted for their sake.
The best part is moving the longer discussions until after. This way, the real workers can get back to productivity while the snobs waste more time discussing details while not discussing details and other crap like that.
If your status hasn't changed, then you are doing it wrong. Ideally your work should be carved up in small enough pieces that once can tell that things are happening.
Obviously, I am not a big fan of Scrum. And while I am a huge fan of iterative development, I think the talking heads should spend 15 minutes reading the source of "waterfall" and realize that it in fact started with iterative development as the first premise was that until they had some work done, they couldn't possibly know what success would look like.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
