8 ms·

I actually like vanilla Scrum and think often you need a formalized methodology for the team to follow. I've worked with a lot of different teams and there are

by cc81 9y ago

I actually like vanilla Scrum and think often you need a formalized methodology for the team to follow. I've worked with a lot of different teams and there are a few things I've noticed being pretty common among developers (or sometimes being guilty of myself). 1. Not working on what you are supposed to be working on. Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. Something it is good and sometimes it just takes time or adds regressions you did not need at the time. 2. Senior developers owning a piece of the code base. Often grabbing a huge chunk of work for themselves on it and then you don't hear from them for a while when they hack away. Sometimes they do good work and sometimes not and if they are sick or away and no one knows how their code works. 3. Junior (or some senior) developers being stuck for a long while without asking for help. 4. Ignoring the customer and building what you think should be built. None of those are automatically fixed with Scrum and I know some here will just say "Yeah, we have a professional team that actually talks with each other and does code reviews" so they don't need it. And I get that but for a lot of those small teams building some CRUD application at a large enterprise the formalized communication ways are a god send in my experience.

deleted 9y ago
[deleted]
piva00 9y ago
I agree with you that a formalized methodology is required for you to start with agile, be it XP, Scrum, Kanban or whatever the flavor the team itself feels more comfortable doing. What no one tells these teams is that the methodology/process itself should be flexible, should be allowed to change to accommodate the idiosyncrasies of their work environment. What I've noticed helping some small companies is that teams learn some framework and use that as their "agile" concept and then proceed to be overzealous of the process itself, completely forgetting the original manifesto. Like always, it's a strange whisper game...
- gregmac 9y ago
  Adjusting the process literally is part of Scrum. At the retrospective, if something isn't working, you call it out and change it. That can be something as big as completely changing the methodology. I've never worked on a XP team but my understanding is formally there is no retrospective process - I would definitely want to put one in place if I did work with it. Any development process that doesn't allow for changing itself is shortsighted and ultimately self-defeating.
  - doseofreality 9y ago
    Except at most companies that use Scrum, there are very rigid rules sent down from above regarding the implementation of Scrum. These rules apply to the whole company and can't be questioned or changed via retros.
    - spost 9y ago
      This is definitely the case for me. I work at a reasonably large (~5-7000 total employees) company that had a top-down Agile Mandate imposed about a year ago. It’s worked reasonably well, honestly, but there was a lot of chafing initially, and there’s still some resistance. Problems with the process are occasionally solved by abandoning it entirely, with mixed results.
      - PaulKeeble 9y ago
        The thing to be careful of is that a lot of developers also don't like certain parts of agile, and those don't get used. They may have a preference to continue to use long cycle approaches (code reviews) where a shorter cycle approach is now necessary (pair programming). The end result is they pick and choose the bits they want and end up failing to ever do the process even once, not because its impossible but because it isn't their preference. They didn't do it out of knowledge, infact they failed to see the interplay in the processes working together and how the entire thing feeds together to produce the whole. I think most teams drop agile practices before they have knowledge to show they aren't appropriate, they usually never get used at all. They adopt what they have to because they don't really want to do it at all because they consider a large chunk of it doesn't work. Changing the process from a position of knowledge and experience on it is one thing, doing it without that knowledge is the more usual thing and its harmful.
humanrebar 9y ago
> Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. To be fair, project managers often decide to keep using X or leave out Y without consulting anyone first. Also, to be fair, project managers are rarely organized or explicit about where the project is and where it should be with respect to cross pollination. If they tracked their goals there like they did other things, you'd see some developers taking this style of project under their wing. That being said, my experience largely matches yours. Though I find the success rate in setting up a closed feedback loop (actually demoing for the actual people that should be happy with the actually deployed feature) is much lower than people notice, so I'm not sure agile is as technically useful as it seems. It's politically useful, for sure. You can say "Working on the wrong thing? I gave Henderson eight demos as work progressed this fall!"
- watwut 9y ago
  The developer should consult not just manager, but also (or primary) other developers. Unless you are working in isolated silos (which is fine), every developer should coordinate with others.
palisade 9y ago
And, some of the best products ever created were written without agile. How did we ever manage. I don't like it when people tell an engineer they're wasting the company time because they implemented something no one asked for. Usually, the customer or client needed that and didn't realize it. And, it bites them in the ass later if they don't.
- cc81 9y ago
  Sure, I'm not saying it is the only methodology to follow or even the best. I'm saying that in my experience it has been a good tool to fix issues like that. And sure you sometimes know that certain things need to be implemented but it should not be done without anyone else knowing it. At least it should be known and agreed upon with the team and then discussed with or made visible for the product owner/PM/whatever role.
richie5um 9y ago
That’s a list of poor engineer attributes, which need to be addressed via conversations. Not impose a process in the hope that’ll fix them.
- cc81 9y ago
  The process is a tool you use to address them. You might have worked with more mature engineering organizations than I have and with people that are more professional. But I've worked with guys who spent most of the time surfing the web or were really territorial with their code. Or teams that were just shitty at communicating with each other so you had frequent misunderstandings or blocking. Or people who said "Yeah, this will be done in a week" and then after one week they say one more week etc. Some are personal issues that should probably be handled by a boss and some are just shitty engineering practice that could be fixed by conversations (provided someone actually knows good engineering practices). But that also requires people not to get defensive and say that we have always done it this way and it works or become angry because they think you are calling them out. Instead agreeing about things like these: 1. The work we do is agreed upon by all and is visible on a board or website. 2. Every day in the morning we chat for 15 minutes about how things are going and if we need help. will fix some of them in my experience and the angry people can whine about the process for a while instead of directing that anger at team mates.
  - richie5um 9y ago
    Fair response - my assertions were a bit extreme :-). You can use process to force change, but, personally, I think a strong manager/leader would aim to resolve these issues irrespective of the process. Also, and I think this is why so many complain about agile, is that it is used to change these types of behaviour and is then seen as ‘the bad _guy_’. My personal view is that the process should be aligned with your business, not as a tool to fix people challenges. The 15 min daily catchup is invaluable irrespective of your overall process. Easier said than done though :). Happy to talk further and learn from your experiences. Thanks.
crdoconnor 9y ago
>I actually like vanilla Scrum Scrum has some really serious flaws: 1) It creates a massive disincentive against refactoring technical debt (refactoring stories essentially have to be 'sold' to the product owner). 2) You end up spending more time than is necessary in too-long meetings. Planning should really be done continuously rather than in biweekly meetings. 3) The idea that you should deliver working software every two weeks is outmoded. You should be aiming to deliver potentially shippable increments continuously.
- ljf 9y ago
  1 the po is the representative of the customer and cares about the long life of the product. Sounds like a role that should care about the future state of the code/product though will obvs want to understand the cost/value of anything that isn't helping the immediate needs 2 planning can be continuous, just every two weeks you look at what you should focus on next, you can still bring stuff into the sprint along the way if everyone agrees 3 you plan to deliver a bundle of value every two weeks (so you can bite off enough to get stuck into, but not so much that you can head in the wrong direction for long) but you can release as soon as the code is ready, no need to wait until the end of sprint.
  - crdoconnor 9y ago
    >the po is the representative of the customer and cares about the long life of the product. That does not make them qualified to rank and/or write refactoring stories. IMHO, they should tell the developers how long to spend on refactoring/tooling (e.g. 30% of their time) and developers should figure out themselves how to spend that time. That isn't scrum, though. >planning can be continuous, just every two weeks you look at what you should focus on next That's saying on the one hand that planning both is and is not continuous. >you plan to deliver a bundle of value every two weeks I call this mini waterfall. It's a good thing to shoot for if you were y previously doing releases every 3 months. It's not a good thing to shoot for if you were previously doing daily releases.
    - ljf 9y ago

by cc81 9y ago

deleted 9y ago

[deleted]

piva00 9y ago

I agree with you that a formalized methodology is required for you to start with agile, be it XP, Scrum, Kanban or whatever the flavor the team itself feels more comfortable doing. What no one tells these teams is that the methodology/process itself should be flexible, should be allowed to change to accommodate the idiosyncrasies of their work environment. What I've noticed helping some small companies is that teams learn some framework and use that as their "agile" concept and then proceed to be overzealous of the process itself, completely forgetting the original manifesto. Like always, it's a strange whisper game...

gregmac 9y ago
Adjusting the process literally is part of Scrum. At the retrospective, if something isn't working, you call it out and change it. That can be something as big as completely changing the methodology. I've never worked on a XP team but my understanding is formally there is no retrospective process - I would definitely want to put one in place if I did work with it. Any development process that doesn't allow for changing itself is shortsighted and ultimately self-defeating.
- doseofreality 9y ago
  Except at most companies that use Scrum, there are very rigid rules sent down from above regarding the implementation of Scrum. These rules apply to the whole company and can't be questioned or changed via retros.
  - spost 9y ago
    This is definitely the case for me. I work at a reasonably large (~5-7000 total employees) company that had a top-down Agile Mandate imposed about a year ago. It’s worked reasonably well, honestly, but there was a lot of chafing initially, and there’s still some resistance. Problems with the process are occasionally solved by abandoning it entirely, with mixed results.
    - PaulKeeble 9y ago
      The thing to be careful of is that a lot of developers also don't like certain parts of agile, and those don't get used. They may have a preference to continue to use long cycle approaches (code reviews) where a shorter cycle approach is now necessary (pair programming). The end result is they pick and choose the bits they want and end up failing to ever do the process even once, not because its impossible but because it isn't their preference. They didn't do it out of knowledge, infact they failed to see the interplay in the processes working together and how the entire thing feeds together to produce the whole. I think most teams drop agile practices before they have knowledge to show they aren't appropriate, they usually never get used at all. They adopt what they have to because they don't really want to do it at all because they consider a large chunk of it doesn't work. Changing the process from a position of knowledge and experience on it is one thing, doing it without that knowledge is the more usual thing and its harmful.

humanrebar 9y ago

> Sometimes some developers feel that they should probably rewrite X or add Y and does so without consulting anyone first. To be fair, project managers often decide to keep using X or leave out Y without consulting anyone first. Also, to be fair, project managers are rarely organized or explicit about where the project is and where it should be with respect to cross pollination. If they tracked their goals there like they did other things, you'd see some developers taking this style of project under their wing. That being said, my experience largely matches yours. Though I find the success rate in setting up a closed feedback loop (actually demoing for the actual people that should be happy with the actually deployed feature) is much lower than people notice, so I'm not sure agile is as technically useful as it seems. It's politically useful, for sure. You can say "Working on the wrong thing? I gave Henderson eight demos as work progressed this fall!"

watwut 9y ago
The developer should consult not just manager, but also (or primary) other developers. Unless you are working in isolated silos (which is fine), every developer should coordinate with others.

palisade 9y ago

And, some of the best products ever created were written without agile. How did we ever manage. I don't like it when people tell an engineer they're wasting the company time because they implemented something no one asked for. Usually, the customer or client needed that and didn't realize it. And, it bites them in the ass later if they don't.

cc81 9y ago
Sure, I'm not saying it is the only methodology to follow or even the best. I'm saying that in my experience it has been a good tool to fix issues like that. And sure you sometimes know that certain things need to be implemented but it should not be done without anyone else knowing it. At least it should be known and agreed upon with the team and then discussed with or made visible for the product owner/PM/whatever role.

richie5um 9y ago

That’s a list of poor engineer attributes, which need to be addressed via conversations. Not impose a process in the hope that’ll fix them.

cc81 9y ago
The process is a tool you use to address them. You might have worked with more mature engineering organizations than I have and with people that are more professional. But I've worked with guys who spent most of the time surfing the web or were really territorial with their code. Or teams that were just shitty at communicating with each other so you had frequent misunderstandings or blocking. Or people who said "Yeah, this will be done in a week" and then after one week they say one more week etc. Some are personal issues that should probably be handled by a boss and some are just shitty engineering practice that could be fixed by conversations (provided someone actually knows good engineering practices). But that also requires people not to get defensive and say that we have always done it this way and it works or become angry because they think you are calling them out. Instead agreeing about things like these: 1. The work we do is agreed upon by all and is visible on a board or website. 2. Every day in the morning we chat for 15 minutes about how things are going and if we need help. will fix some of them in my experience and the angry people can whine about the process for a while instead of directing that anger at team mates.
- richie5um 9y ago
  Fair response - my assertions were a bit extreme :-). You can use process to force change, but, personally, I think a strong manager/leader would aim to resolve these issues irrespective of the process. Also, and I think this is why so many complain about agile, is that it is used to change these types of behaviour and is then seen as ‘the bad _guy_’. My personal view is that the process should be aligned with your business, not as a tool to fix people challenges. The 15 min daily catchup is invaluable irrespective of your overall process. Easier said than done though :). Happy to talk further and learn from your experiences. Thanks.

crdoconnor 9y ago

>I actually like vanilla Scrum Scrum has some really serious flaws: 1) It creates a massive disincentive against refactoring technical debt (refactoring stories essentially have to be 'sold' to the product owner). 2) You end up spending more time than is necessary in too-long meetings. Planning should really be done continuously rather than in biweekly meetings. 3) The idea that you should deliver working software every two weeks is outmoded. You should be aiming to deliver potentially shippable increments continuously.

ljf 9y ago
1 the po is the representative of the customer and cares about the long life of the product. Sounds like a role that should care about the future state of the code/product though will obvs want to understand the cost/value of anything that isn't helping the immediate needs 2 planning can be continuous, just every two weeks you look at what you should focus on next, you can still bring stuff into the sprint along the way if everyone agrees 3 you plan to deliver a bundle of value every two weeks (so you can bite off enough to get stuck into, but not so much that you can head in the wrong direction for long) but you can release as soon as the code is ready, no need to wait until the end of sprint.
- crdoconnor 9y ago
  >the po is the representative of the customer and cares about the long life of the product. That does not make them qualified to rank and/or write refactoring stories. IMHO, they should tell the developers how long to spend on refactoring/tooling (e.g. 30% of their time) and developers should figure out themselves how to spend that time. That isn't scrum, though. >planning can be continuous, just every two weeks you look at what you should focus on next That's saying on the one hand that planning both is and is not continuous. >you plan to deliver a bundle of value every two weeks I call this mini waterfall. It's a good thing to shoot for if you were y previously doing releases every 3 months. It's not a good thing to shoot for if you were previously doing daily releases.
  - ljf 9y ago