|
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'm looking forward to that article; coming from SDM I'm still not convinced that agile has any benefits. To me it sounds like a generalization of idea's on how to cut a corner.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
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 enjoyed it, even with the blatant ad in the middle of the presentation.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
snorkie wrote:
2. About half of the 15 minute morning morning consists of, "Lets have a Meet After to Discuss".
Reminds me of one of the Google commercials.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
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 |
|
|
|
|
|
LOL 
|
|
|
|
|
As I heard it, scrum comes from rugby. Like in American football, the team goes into a huddle. Rugby, it is called a scrum.
|
|
|
|
|
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
|
|
|
|
|
SCRUM works, and works well, as long as you accept it.
That's what my pastor told me about religion.
Religion works, and works well, as long as you accept it.
Interesting....
|
|
|
|
|
No matter how you call your "product development strategy/process", some people just prefer wasting time to actually doing their jobs.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
