SCRUMmy Development
-
So you're saying we have room for improvement :)
Pete O'Hanlon wrote:
Yes. The longer you leave it between people talking, the more chance you have for things going wrong, and the SCRUM shouldn't just be the developers. What about your testers? Tech writers? They need to be involved because they need to hear what is being said just in case you are changing things.
All of those people are in the meeting. It just doesn't seem like anything is done. Our meeting is forced to quick updates where we are at and nothing else being discussed.
Pete O'Hanlon wrote:
Better known as, let's waffle on about an issue for an hour or two and completely bore those who aren't involved. The standup is purely there to give people an update on what's just gone on, and what is coming up in the future along with what's preventing you from delivering.
Yes, many people are lazy and try to use meetings to get out of work. However, we're so early in development that I think we need some level of "group think" to get on the same page. This could be done with time boxing to ensure it doesn't go too far off topic.
Pete O'Hanlon wrote:
So no one delivers anything? Your units of work should be small enough that you can see progress in short spaces of time.
In terms of delivering, we have a meeting at the end of the SCRM to show what was done. This seems too little too late to me, but our SCRUM expert set it up this way. I know it can be done well, but we have not figured it out yet. Hogan
As OG states, what I'm saying is that meetings tend to be counterproductive. Without strict control, they do have a tendency to wander all over the place, and the meeting is at the mercy of the people with the biggest agendas, and the loudest voices. That's not a way to handle a status update. What most SCRUM environments tend to do is operate in sprints. At the start of a sprint, all the items that haven't been completed are up for grabs, and the meeting is used to decide on what you are going to do this sprint. This is the opportunity to bring forward your backlog from previous sprints; to get a common understanding of what you're going to attempt to deliver this sprint, and to get updates on areas that need further clarification. It's fairly common practice to give some high level estimates to each item and to allocate tasks (I tend to assume that people will only be about 70% allocated to these tasks), so if I were to allocate 80 hours per person over a fortnight, I'd only look to give them about 7 days of tasks (note that this isn't 7 days of development). The reality, of course, is that you wouldn't allocate 80 hours because you need time to wrap up each sprint, so over 10 days, I would expect the last day to be tidying up loose ends and doing a post-sprint release. At the end of each sprint, you might opt to have a sprint review. This is the opportunity to say what went well; where the pain points are, and what can be done to improve things for the next sprint.
Chill _Maxxx_
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
What you need is a simple to understand definition[^]. SCRUM works, and works well, as long as you accept it. The greatest impediment is members of the team trying to work around or outside of the sprint. Once that happens things go FUBAR. The stand-up has three questions - "What did you do yesterday? What will you do today? What help will need?" - anything outside of this does not belong in the stand-up.
speramus in juniperus
-
As OG states, what I'm saying is that meetings tend to be counterproductive. Without strict control, they do have a tendency to wander all over the place, and the meeting is at the mercy of the people with the biggest agendas, and the loudest voices. That's not a way to handle a status update. What most SCRUM environments tend to do is operate in sprints. At the start of a sprint, all the items that haven't been completed are up for grabs, and the meeting is used to decide on what you are going to do this sprint. This is the opportunity to bring forward your backlog from previous sprints; to get a common understanding of what you're going to attempt to deliver this sprint, and to get updates on areas that need further clarification. It's fairly common practice to give some high level estimates to each item and to allocate tasks (I tend to assume that people will only be about 70% allocated to these tasks), so if I were to allocate 80 hours per person over a fortnight, I'd only look to give them about 7 days of tasks (note that this isn't 7 days of development). The reality, of course, is that you wouldn't allocate 80 hours because you need time to wrap up each sprint, so over 10 days, I would expect the last day to be tidying up loose ends and doing a post-sprint release. At the end of each sprint, you might opt to have a sprint review. This is the opportunity to say what went well; where the pain points are, and what can be done to improve things for the next sprint.
Chill _Maxxx_
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierI have bookmarked this. I am really trying to write a sensible [for a given value of sensible] guide to SCRUM that can be used effectively to get people to understand what they are doing. To me an underlying principle of all Agile methodologies is that they must get rid of fluff, and in return increase productivity and quality.
speramus in juniperus
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
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?
One of the big purposes of SCRUM is to communicate amongst the team members, including with a stakeholder representative. One of the features of this is the very important detail of communication. If you are triggering something where people realize that a subgroup needs to meet every day about some detail, then this aspect of scrum is working the way it should. This also keeps the stakeholder aware that there are problems to be solved, and they are being solved or at least identified. This goes a long way in avoiding surprises towards the end of the project. You need to give it more time.
Windows 8 is the resurrected version of Microsoft Bob. The only thing missing is the Fisher-Price logo. - Harvey
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
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!
-
I have bookmarked this. I am really trying to write a sensible [for a given value of sensible] guide to SCRUM that can be used effectively to get people to understand what they are doing. To me an underlying principle of all Agile methodologies is that they must get rid of fluff, and in return increase productivity and quality.
speramus in juniperus
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
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.
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
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.
-
I have bookmarked this. I am really trying to write a sensible [for a given value of sensible] guide to SCRUM that can be used effectively to get people to understand what they are doing. To me an underlying principle of all Agile methodologies is that they must get rid of fluff, and in return increase productivity and quality.
speramus in juniperus
Nagy Vilmos wrote:
To me an underlying principle of all Agile methodologies is that they must get rid of fluff,
That is part of the process of all process control methodologies that I have seen.
Nagy Vilmos wrote:
and in return increase productivity and quality.
That is part the goal of all process control methodologies that I have seen.
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
That doesn't sound like SCRUM to me. Somebody is faking it.
Anna :rose: 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?"
-
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.
-
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?
One of the big purposes of SCRUM is to communicate amongst the team members, including with a stakeholder representative. One of the features of this is the very important detail of communication. If you are triggering something where people realize that a subgroup needs to meet every day about some detail, then this aspect of scrum is working the way it should. This also keeps the stakeholder aware that there are problems to be solved, and they are being solved or at least identified. This goes a long way in avoiding surprises towards the end of the project. You need to give it more time.
Windows 8 is the resurrected version of Microsoft Bob. The only thing missing is the Fisher-Price logo. - Harvey
I'll give it more time, cause I like my job! However, I have yet to personally realize benefits from SCRUM. I feel that valuable communication is lost because the meeting is limited to the three questions. I feel like I'm living in a law drama where developers are lawyers having to have sidebars all of the time. We're all friends here, and can discuss issues in front of everybody. Hogan
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
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?).
-
That doesn't sound like SCRUM to me. Somebody is faking it.
Anna :rose: 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?"
-
Only if you don't call their bluff!
Anna :rose: 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?"
-
I have bookmarked this. I am really trying to write a sensible [for a given value of sensible] guide to SCRUM that can be used effectively to get people to understand what they are doing. To me an underlying principle of all Agile methodologies is that they must get rid of fluff, and in return increase productivity and quality.
speramus in juniperus
This is the video I got our guys to watch[^] It was a waste of time as I continually get "I know we're doing it wrong but we can't change it" response - but I think it's 10 minutes well spent for anyone who is interested in Agile development.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. Hogan
Beats ours -- our daily fifteen minutes have been scheduled for three times a week for an hour. :sigh:
-
I've been doing SCRUM development for 4 weeks now and it feels like a huge waste of time. Here is a short list of complaints. 1. Would any self organizing team of developers actually plan to meet every day? 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? 3. The other half of our 15 minute morning meetings is just to state that the status hasn't changed from yesterday I'll give it more time, but I'm not expecting much. 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'll give it more time, cause I like my job! However, I have yet to personally realize benefits from SCRUM. I feel that valuable communication is lost because the meeting is limited to the three questions. I feel like I'm living in a law drama where developers are lawyers having to have sidebars all of the time. We're all friends here, and can discuss issues in front of everybody. Hogan
There should be nothing stopping you from talking to your colleagues outside of the stand up to further discuss issues. If there are things which are a problem and could stop the team delivering working software then the standup is the place to raise this since everybody who is interested in the project succeeding should be there, however, it isn't the place for a full blown discussion of an issues. One of the main things about any agile process is visibility into what's happening, so what work people are doing, how the project is progressing, problems, etc but depending on size of your team(s) not everybody present may need to participate in discussions about specifics so having "sidebars" is the right thing to do.