SCRUMmy Development
-
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.
-
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. :)
-
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
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".
-
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
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.
-
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'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
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.
-
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
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.
-
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.
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:
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!
-
Michał Rybiński wrote:
One person brought up important topic...
However all of those comments are appropriate to any business meeting and is not specific to SCRUM nor even any process methodology.
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.
-
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.
I agree with your thoughts on the meetings being a large interruption. Ours start at 9:30 am. It interrupts the morning :( After talking about SCRUM with another coworker yesterday, I came to the thought that SCRUM is not for developers, but for management to track work. I don't see this as good or bad, just an observation. Good managers/developers will make most environments successful regardless of the process. Hogan
-
SCRUM, it would seem, was derived from SCAM, SCRAP, or more likely, SCROTUM. Just sayin' . . .
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
As I heard it, scrum comes from rugby. Like in American football, the team goes into a huddle. Rugby, it is called a scrum.
-
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?).
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.
-
I agree with your thoughts on the meetings being a large interruption. Ours start at 9:30 am. It interrupts the morning :( After talking about SCRUM with another coworker yesterday, I came to the thought that SCRUM is not for developers, but for management to track work. I don't see this as good or bad, just an observation. Good managers/developers will make most environments successful regardless of the process. Hogan
I also agree. But, to sound like devil's advocate, we should plan ahead for the meeting. We know it is coming at the appointed time. So don't get too deep in your work. Possibly, scheduling the scrum meeting at a better time, say just after lunch, at the end of the day, when every one gets in may work out. The idea time would be before or after everyone has or had that inspirational moment. The hard part is making sure that all of the participants are present at the meeting time.
-
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.
-
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.)
-
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.
-
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.
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 cer -
I also agree. But, to sound like devil's advocate, we should plan ahead for the meeting. We know it is coming at the appointed time. So don't get too deep in your work. Possibly, scheduling the scrum meeting at a better time, say just after lunch, at the end of the day, when every one gets in may work out. The idea time would be before or after everyone has or had that inspirational moment. The hard part is making sure that all of the participants are present at the meeting time.
James Lonero wrote:
I also agree. But, to sound like devil's advocate, we should plan ahead for the meeting. We know it is coming at the appointed time. So don't get too deep in your work. Possibly, scheduling the scrum meeting at a better time, say just after lunch, at the end of the day, when every one gets in may work out. The idea time would be before or after everyone has or had that inspirational moment. The hard part is making sure that all of the participants are present at the meeting time.
Best time of meeting is at start of work; typically 9AM or 9:30; Meetings in mid-day or end-of-day will cause confusion and will result in either ppl not starting work before SCRUM or having to undo the work post feedback from meeting. Productivity of Meetings is directly proportional to percentage of brains present in it. Note, I am saying brains, not bodies. I too have had days when I was physically present and mentally absent