|
In SCRUM meetings, and particularly during retrospective after sprint, it is critical to ensure open, safe comm. That's why team has right to ask everyone else out during retrospective or ask executives to not attend particular status meeting.
In one of companys I did work, we had a woman, which was particularly good at moderating meetings - she was outside project. For a team, where people had issue with openly discuss problems and even cooperate well, she was introduced to help to talk. No strings attached, she was there to moderate, help execute the meetings, guide their way, no detailed reports provided up in the food chain. It was said at the day one. After two weeks communication in team appeared to change dramatically, and after one month this was completely another team - she helped them. The team needs to feel secure to openly discuss it's drawbacks.
I mean - I've seen a lot of retrospectives, even ones, where people where angry on each other and it got hot. I think it's crucial if you want to have SCRUM - one of cornerstones there is the team executing development, and the team is also about honest communication.
|
|
|
|
|
Michał Rybiński wrote: In SCRUM meetings, and particularly during retrospective after sprint, it is critical to ensure open, safe comm
And AGAIN, that is is the goal of all business meetings. And since SCRUM meetings are business meetings it applies to them as well.
Michał Rybiński wrote: I mean - I've seen a lot of retrospectives, even ones, where people where angry on each other and it got hot
And I have seen business meetings where that happened. I was at an interview for a employee candidate where employees started a heated discussion amongst themselves. At another requirements meeting a business analyst left in tears.
|
|
|
|
|
snorkie wrote: We're all friends here, and can discuss issues in front of everybody.
That's one of the three questions -> "Is anything blocking you?" If there isn't an issue then nothing is blocking you. Fixing the issue isn't part of the standup. Assigning the best people to get together to handle the issue after the stand-up is. The idea is to get a feeling on how well things are going and set up interventions when problems occur and don't pull the whole team into one person's problems. That issue should be resolved in the middle of the day or your backlog may be in trouble, which is another facet of the stand-up.
I think the stand-up is intended to make people want to leave and get on with their day. You can't sit back, close your eyes and drift in the boring meeting. (I have drifted off while standing up, but not in a sprint meeting, a meeting where everyone is required, not enough chairs, and well over an hour in the meeting with one guy monotone talking in front. I did catch myself before I fell.)
The idea is that everyone finds out that they know what they are supposed to do and when they leave the scrum, they should be either confident they will accomplish their goal or they will be getting the help they need to accomplish their goal.
Issue solving is a 2 to 3 person task, the whole team shouldn't be involved in it.
|
|
|
|
|
snorkie wrote: 1. Would any self organizing team of developers actually plan to meet every day?
Probably not, which is why you have to force them to do it.
snorkie wrote: 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?
That means that your sprint planning was not performed effectively.
If someone cannot simply say "This is the story I worked on yesterday, and this is whay I achieved", then look at fixing the sprint planning, not the stand-ups.
ALL planning and discussion should be completed in planning sessions. If it turns out that something requires further planning, take it out of the sprint, and get on with something that can be completed.
snorkie wrote: 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday
If no stories have been advanced/finished since the day before, it had damned well better have been a Sunday, or you're all fired!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: If no stories have been advanced/finished since the day before, it had damned well better have been a Sunday, or you're all fired!
That's the usual result of a group just starting to do sprint planning. They haven't figured out how to create one hour or one day stories, so they never complete a story in one day, too much is in the story and they aren't breaking the stories up into small enough pieces. People hate going to sprint because they didn't finish anything. Realizing how to break things up small enough to always get something finished each day isn't yet in their mindset. They don't even know about poker card planning.
|
|
|
|
|
KP Lee wrote: They haven't figured out how to create one hour or one day stories, so they never complete a story in one day, too much is in the story and they aren't breaking the stories up into small enough pieces. People hate going to sprint because they didn't finish anything.
True.
This also means that they miss out on the satisfaction of actually finishing things, which is rare enough in the development game.
-- Closing a ticket because you've fixed a bug is pretty bleah.
-- Closing a ticket because you've finished part of a project, however small that part may be, is very satisfying.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I see where you're coming from I went through the same process of not trusting it when I started using scrum 6 to 7 years ago.
Nowadays my opinion has changed totally! I think it is a really effective way to develop software.
Developers and Testers, product managers are forced to talk, at first it feels really artificial and a waste of time, but after a few weeks you start to get really value out of the meetings.
The main thing you need to do is think differently, software is complex and although you write it, you are not the only person involved. You need to listen to feedback, you need to inform the others of your progress... the team becomes aware of the whole picture, not only technical issues with the piece of code you are writing, but you are also made aware of the nightmare your testers are going through setting up the right environment... etc... if you spend some time actually listening to the feedback you receive it will help you next time to write your code so that it facilitates the task of QA. And similarly if you let QA know that you struggled writing a piece of code they will take that into account and look at the result more carefully.
It took me some time to embrace Scrum and right now I think it is an outstanding way to develop. It teaches you humility when you listen, it encourages openness, it shorten the time needed to identify issues, it allows quick reaction to a customer who changes his mind. And above all it give everybody a voice... and that's good for productivity as it motivates people!
The team meeting in the morning is just on aspect of Scrum, this meeting will only be meaningful if the sprint has been planed carefully, if the stories are small enough so that you can actually say something about what you have done everyday. etc... If the meeting does not work maybe you need to review the sprint planning, was too much taken on? are the resource adequate? also mayeb the product backlog is not correct, you need short stories, you need priority etc..
Anyway that's my opinion. I think Scrum is really powerful and actually helps writing good software faster.
|
|
|
|
|
snorkie wrote: I've been doing SCRUM development for 4 weeks now and it feels like a huge waste
of time
I have never seen any research that suggested that any specific formal process control methodology provided a benefit over any other type.
I have seen research that shows that any formal process control methodology that is implemented effectively does in fact improve process flow in a number of ways. Of course if it is ineffective then it will do nothing but waste time.
|
|
|
|
|
jschell wrote: I have never seen any research that suggested that any specific formal process control methodology provided a benefit over any other type.
Even if you did, that would only prove the research was bad. No methodology can fix a bad team.
|
|
|
|
|
Nemanja Trifunovic wrote: Even if you did, that would only prove the research was bad. No methodology can
fix a bad team.
I don't see how those comments follow from what I posted.
Nor do I see how the first follows from the second presuming that is what you meant.
|
|
|
|
|
jschell wrote: I have never seen any research that suggested that any specific formal process control methodology provided a benefit over any other type.
The point is that if you are using a methodology, any methodology, badly, or not following it correctly, it will not work.
If scrum (or any other methodology) has been adopted by the OP's company, then discussions about whether or not they should follow it are immaterial. They have to do it right, or they're just wasting their time and risking their jobs.
Another point to note is that management will come gunning for anyone who intentionally does things to prevent it's working correctly, and will be right to do so -- you don't sabotage your home team.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: They have to do it right, or they're just wasting their time and risking their jobs.
It has been my experience that the vast majority of development shops fail to implement effective process methodology.
And effective doesn't mean that developers feel good but rather than the over all process such as delivery, overwork, bugs, features delivered, etc, improve once the process is put into place.
Mark_Wallace wrote: Another point to note is that management will come gunning for anyone who intentionally does things to prevent it's working correctly
Not any place that I have ever worked for nor that I have even heard of. At one company management terminated the formal process control because the company was acquired and the employees of the acquiring company found the process control confusing (and given that the code from the acquiring company was the worst code I have ever seen in my entire career it isn't a wonder that they were confused.)
|
|
|
|
|
jschell wrote: It has been my experience that the vast majority of development shops fail to implement effective process methodology.
Perhaps they should have hired better quality people.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Perhaps they should have hired better quality people.
Since effective process control originates from management, not development, the blame lies there.
|
|
|
|
|
jschell wrote: effective process control originates from management, not development
That there is proof positive that you don't understand scrum at all, and probably the reason why it fails where you work.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: That there is proof positive that you don't understand scrum at all
Then apparently neither does the research that demonstrated the same thing - process control only works when it is mandated and enforced by management.
Mark_Wallace wrote: and probably the reason why it fails where you work.
Management level failure is why process control fails at almost all companies.
If you think it works where you work then please provide the metrics (actual measured hard values) that demonstrate an improvement in process control where you work. Also provide a brief overview about how those metrics were collected.
|
|
|
|
|
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?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
