Structured, yes or no?
-
Everybody hates SCRUM. I do, too. But I think, the larger the team and the more innovative the project, the more SCRUM you need. Unfortunately! Haven't seen anything better for teams of 5-8 or more people yet.
If everybody hated it we'd be doing something else by now. It's true lots of people don't like it, especially the overhead, but there are still many people who follow scrum religiously.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Most of my clients don't have enough work to plan in two week sprints anyway. It would be a sprint for multiple customers. So let's say the sprint starts on Monday, a customer (who may or may not have work in the current sprint) calls on Tuesday, and I have to tell him they'll have it at the end of the next sprint (four weeks from now)? That's a recipe for losing clients. There's a lot less than scrum that can still count as a process.
SeattleC++ wrote:
His experience says this is a bad way of working. That's certainly what I would say.
I'm actually more experienced than him in pretty much every way possible (number of jobs, time in the field, methodologies used, etc.), but he is by far the better front-end programmer. He's never done anything else than scrum, I have, and that's probably why he's having trouble adapting. And in my experience, I'm saying everything we do besides what we're doing now is absolute overkill as far as work planning goes. Although I'm now making sure his tasks are a bit less open for interpretation, some people need a bit more management and I accept and respect that. So, instead of "can you start with whatever form and fix it like we said last month, tell me when it's done." I'm now saying "can you make sure fields x and y on form z are positioned like a and b and I want it by the end of the week." (this is an example, not a literal conversation, before people start making assumptions based on this too).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I've mostly worked on multi-man-year projects. It's hard for me to imagine a whole project that takes less than a week, but requires iteration and needs more than one worker. You have to do what works for you, and sprints are apparently not part of it. Your partner was suffering from a need for a more concrete design to grind on, and you have learned to provide it, which is good.
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
If everybody hated it we'd be doing something else by now. It's true lots of people don't like it, especially the overhead, but there are still many people who follow scrum religiously.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
With "everybody" I meant every developer. The religious people are usually managers. ;-)
-
I've mostly worked on multi-man-year projects. It's hard for me to imagine a whole project that takes less than a week, but requires iteration and needs more than one worker. You have to do what works for you, and sprints are apparently not part of it. Your partner was suffering from a need for a more concrete design to grind on, and you have learned to provide it, which is good.
SeattleC++ wrote:
It's hard for me to imagine a whole project that takes less than a week
More like tasks than projects (or tasks that are part of an ongoing project, if you like). The tasks usually don't require more than one worker, it's just that I'm not a (graphic) designer so those aren't tasks I can do myself. So this guy goes from a full scrum team from another employer to a task here and a task there for me. Maybe it's good to mention he doesn't work for me full time, but a few hours a week. I'm getting a full time employee later this year, will probably switch to a more scrum/kanban approach when that time arrives. It still won't be a full fledged project team, but hopefully getting there in the next two years or so :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
