SCRUMmy Development
-
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
-
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
Where is you company based? What line of work are you in? (I mean the industry vertical that your s/w product is aiming at)
-
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!
-
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!
-
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.
-
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!
-
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.
-
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!
-
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.