SCRUMmy Development
-
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.
-
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?
-
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.
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
-
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
-
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
On top of other answers, it seems like issue with either team or definition of done/planning: - is your team ( i mean team: devs, testers and writers) sitting in one room? IF not, try to sit them down close to each other. They will have a plenty of opportunities to communicate outside stand-up. Helps a lot. - keep rigor on stand-up - just 3 questions, status and go to after discussions. I've seen failed introductions of SCRUM just because stand-ups got too long and people were just tired of too long status meetings - items - seems like stuff is little too complex, task granularity is too large or guys do not have much experience... whatever, I can only guess. Try out with one-two items, split it into really small tasks with clear definition of done, see if it reduces number of after stand-up discussions. Be aware - SCRUM is also about constant code refactoring, sometimes it's even 3rd or 4th iteration on the same part of code, that produces functionality satisfying most requirements. One person brought up important topic - open talk about one's problems. It takes experienced/good at 'soft skills' moderator to make team comfortable about telling of own flaws and drawbacks. Just one rule, yet very important - never allow it to have at least shadow of getting personal, always cut to the chase and disregard/ignore comments outside of subject. There is no magic, golden triangle quality/time/cost requires constant corrective actions, be it cutting the scope or extending the deadline or decision like 'now we need to refactor to get better performance/make more extendible architecture'. Keep focused on use cases, which constitue 80%-90% of normal usage of software, patch corner cases or just avoid them by design limiting delivered functionality - from my experience developers tend to spend a lot of time (and cost in company terms) to cover all cases possible, instead focusing on the basic ones.
-
Can I ask did you bring up these issues in a retrospective for the team to discuss?
-
Beats ours -- our daily fifteen minutes have been scheduled for three times a week for an hour. :sigh:
-
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
-
Can I ask did you bring up these issues in a retrospective for the team to discuss?
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. :)
-
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
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.
-
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
The thing that I've noticed is that the goal of this method of development is to show progress, no matter what the cost. I've seen numerous times where doing something the right way and preparing for maintainability and expandability is thrown by the wayside and even ridiculed in the effort to meet "goals". So when it comes time for the next sprint, the work that was just completed is thrown out, or totally rewritten, and what is usually ended up with is patchwork code because we didn't have the time to do it right. In my opinion, I see this method as a unguided accumulation of technical debt that may or may not ever get paid.
-
The thing that I've noticed is that the goal of this method of development is to show progress, no matter what the cost. I've seen numerous times where doing something the right way and preparing for maintainability and expandability is thrown by the wayside and even ridiculed in the effort to meet "goals". So when it comes time for the next sprint, the work that was just completed is thrown out, or totally rewritten, and what is usually ended up with is patchwork code because we didn't have the time to do it right. In my opinion, I see this method as a unguided accumulation of technical debt that may or may not ever get paid.
That is not really the fault of SCRUM, but more an erroneous use of it.
speramus in juniperus
-
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
-
That is not really the fault of SCRUM, but more an erroneous use of it.
speramus in juniperus
Nagy Vilmos wrote:
That is not really the fault of SCRUM, but more an erroneous use of it.
And incorrect use of other process control methodologies lead to bad results as well. But my experience is that in a very large percentage of cases process methodologies are used incorrectly.
-
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.
nathans.dropbox@googlemail.com wrote:
One of the main things about any agile process is visibility into what's happening
I haven't seen any popularized process control methodology where that wasn't a goal as well.
-
On top of other answers, it seems like issue with either team or definition of done/planning: - is your team ( i mean team: devs, testers and writers) sitting in one room? IF not, try to sit them down close to each other. They will have a plenty of opportunities to communicate outside stand-up. Helps a lot. - keep rigor on stand-up - just 3 questions, status and go to after discussions. I've seen failed introductions of SCRUM just because stand-ups got too long and people were just tired of too long status meetings - items - seems like stuff is little too complex, task granularity is too large or guys do not have much experience... whatever, I can only guess. Try out with one-two items, split it into really small tasks with clear definition of done, see if it reduces number of after stand-up discussions. Be aware - SCRUM is also about constant code refactoring, sometimes it's even 3rd or 4th iteration on the same part of code, that produces functionality satisfying most requirements. One person brought up important topic - open talk about one's problems. It takes experienced/good at 'soft skills' moderator to make team comfortable about telling of own flaws and drawbacks. Just one rule, yet very important - never allow it to have at least shadow of getting personal, always cut to the chase and disregard/ignore comments outside of subject. There is no magic, golden triangle quality/time/cost requires constant corrective actions, be it cutting the scope or extending the deadline or decision like 'now we need to refactor to get better performance/make more extendible architecture'. Keep focused on use cases, which constitue 80%-90% of normal usage of software, patch corner cases or just avoid them by design limiting delivered functionality - from my experience developers tend to spend a lot of time (and cost in company terms) to cover all cases possible, instead focusing on the basic ones.
-
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.