Structured, yes or no?
-
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
Scrum is the absolute minimum amount of process that can be imposed on an organization that is process-averse. That you find it too rigid makes you less of a cowboy and more of a wildman. (I might have said wild indian to carry on the cowboy motif, but that's not politically correct). If you let customers change horses in the middle of a two-week sprint, you are embracing a degree of chaos that probably hurts your profit as a consultant, or needlessly raises costs to your customers. I bet this is not your friend's first rodeo (Yee-hah! More cowboy metaphors). His experience says this is a bad way of working. That's certainly what I would say. More discipline is called for. It's better for you, better for your partner, and better for your customers.
-
I use it for my hobby project. Now found out the >100 files are only copied when .net framework 4.6 is used. With .net framework 4.7 it copies only < 20 files to the debug folder.
There are a lot of "filler" DLLS to bring 4.6 up to .NET Standard compliance - which might be what is used by your framework. The best solution if this is a problem is to stop using 4.6 - the world is not going to stop using .NET standard, so even if you skip this framework (well, to be honest, as it is an MVVM framework I would skip it no matter what) then the next library you find for something else will have the same problem.
-
In 40 years of professional software development experience, I have never seen Waterfall (as you describe it) done. There is always versatility in every project I have seen or been a part of in that time. I think the "waterfall" argument that underlies the current approaches to Agile is a strawman argument. I don't doubt it has or does happen with rarity (I have not worked for IBM, for example), but I have not witnessed it.
I have 25 years in software development, and I have seen it in two out of three companies I worked in. Well at least it was supposed to be waterfall, but of course it did not work so it was fudged left and right - still, they pretended everything was planned 6-12 month ahead. The first company was a very large ISV, the second a small one, but both of them made products (as opposed to projects) targeting large enterprise customers. A friend worked doing projects for government, and they also had to do waterfall - and for them the trick was of course to quote low, then charge relative high for the changes that would ALWAYS be requested to turn a profit. If they quoted realistically from the start someone else would get the deal - or the project would be cancelled due to too high cost.
-
Scrum is the absolute minimum amount of process that can be imposed on an organization that is process-averse. That you find it too rigid makes you less of a cowboy and more of a wildman. (I might have said wild indian to carry on the cowboy motif, but that's not politically correct). If you let customers change horses in the middle of a two-week sprint, you are embracing a degree of chaos that probably hurts your profit as a consultant, or needlessly raises costs to your customers. I bet this is not your friend's first rodeo (Yee-hah! More cowboy metaphors). His experience says this is a bad way of working. That's certainly what I would say. More discipline is called for. It's better for you, better for your partner, and better for your customers.
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
-
This comment will add very little to Sander's post but it is posted to say I admire the intelligence and thoughts of the folks who responded to the query. What a bunch of smart people. When I started coding VB 6 I would use what I learned in an elective Basic Programming on a DEC writer NO screen. That was to draw a flow diagram. It was a terrible idea as I had no idea what the VB 6 project would do. Slow forward too many years and I have learned to draw my screens (Forms) and think about the controls that might be needed. This makes the process of writing the code easier. Yes I am up to vb.net now. Last summer I started woodworking table saw the whole nine yards. Wanted a workbench/outfeed table. So I did a sketchup drawing made a cut list. It dawned on me that this process was the very similar to my rudimentary design process for coding. I had to farm out my milling for the table legs as I have no jointer or planner. I wanted the 4 by 4's to be 3 in square. I have no friends that code and have often thought it would be fun to work on a BIG project with a fellow coder. I have no idea how working on a BIG project with someone else would work After reading every comment on this post I am guessing 70% of the people who responded work solo. It would be nice to know. So someone make a post posing the question. While I have been here for sometime that type of post for me is above my pay grade.
The process goes a bit as follows. An analist meets with "the business" and divides the work into stories. To create and organize stories the team uses a scrum board with backlog, like Jira, Trello, Azure DevOps, etc. You then have meetings to estimate how long the stories take to complete the complexities of the stories (complexity can be expressed in T-shirt sizes or numbers from the Fibonacci sequence, for some reason). A product owner prioritizes the stories based on other meetings. You then meet to plan the next sprint (any stories you didn't complete from the previous sprint are moved into the next). During these meetings you also divide the stories into tasks. Any stories that aren't 100% clear can't be estimated and have to go back to the story owner (mostly the person or manager who requested the change). After a while you should know just about how much complexity your team can handle in a two-week sprint, so you can plan accordingly. Every day you have a stand-up with the team to briefly discuss what you did, what you're going to do and if you need any help. During this stand-up you'll move tasks and stories from "to do" to "doing" or "done". At the end of the sprint you'll have meetings about how the sprint went and what could've been done better. You'll have at least two or three one to two hour meetings a week (I've even heard people say they should be three to four hours!) plus a daily 5 to 15 minutes stand-up. During the sprint it is possible to move some stories around if priorities change, but that should be avoided. At the end of the sprint you should be able to deliver the stories, and so real value, to the business. As for the code, you'll use tools such as Git and GitHub, obviously. So yeah, prepare to lose at least half a day a week on meetings while being more or less agile in two-week increments. Keep in mind not all teams do everything like this, but this seems to be a popular format. I've been in three-week sprints, half hour to hour stand-ups, teams skipping meetings like the retrospective, teams doing only the stand-up with a Kanban board and calling it scrum... Scrum absolutely has its merits, but it's not the golden bullet some people would have you believe.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (fre
-
You're kidding right? How can you design something you don't understand? I can't. Why? Because he "said" he didn't "understand". You've set him up to fail.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Gerry Schmitz wrote:
You're kidding right? [...] You've set him up to fail.
That's a quick conclusion you're coming to, and not one I find flattering. An analyst, to me, is someone who talks to the business and finds out what they have, what they want and what they need, and based on those discussions, writes a document on what the new software or features should do. A (UI) designer then reads that document and comes up with a compelling UI so users can do what they should do as easy and quickly as possible. My guy is the last one and I already did the first. Besides, I already had software running, showed it to him, and he merely redesigned it. I actually told him not to think of the business too much because I wanted a fresh perspective. The client was, and is, satisfied. Next time, be more like an analyst and ask before drawing conclusions.
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
-
FWIW, I wrote these principles (not rules) that address your question, at least to some degree. I hope you and others find something useful in them. Rethinking Software Development Life Cycle Management[^] "Soup to Nuts" in Software Development[^]
Excellent reads! You can't really say scrum may not be your best solution without getting some hate, but I agree wholeheartedly :thumbsup:
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 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
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.
-
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
