Structured, yes or no?
-
Randor wrote:
In order to get ISO certification[^] there has to be a full-time auditor on staff to ensure the process is strictly followed.
No, that is absolutely not the case. I run a one-person consultancy/development business and it achieved certification[^] at the first attempt in 2007, I believe one of the first 50 such micro-companies to do so in the UK. I passed external audits in 2008 / 2009 as well. Working with the Professional Contractors Group as it was then (now IPSE[^]) we (me and the company!) were given an outline structure for our quality system, plus some (quite a small number) of template documents. I admit it took me quite a long while to get my head around the concept of the system, but it eventually dawned on me that it was just a document change control system. (It was actually hosted on a SubVersion server). The process of working out what the company actually needed was very enlightening and brought about genuine improvements for me and my clients. The initial certification process was tough, as expected. External inspectors went through everything and needed to see evidence that the systems were in continual use. However 90% of the admin "burden" related to managing the limited company, rather than to actually doing any consultancy / development work. By choice I extended parts of the quality system to cover that (around issues like implementations, disaster recovery and backups in particular). I had hoped that having ISO9001 would open up doors to new clients and allow for rate increases. As it happened, shortly after gaining certification I also gained a major client who gave me as much work as I could cope with, and at silly (high) rates. Contact with him brought in many other clients in the same industry and I was turning work away at one point. When it came to renewal of certification I didn't bother; I had dispensed with some parts of the quality system that were adding no demonstrable value, but continue with others to this day. I understand that of course ISO9001 has developed since 2007, but I'm sure it's still attainable to any micro-business, at very affordable prices and without massive overheads. Certainly no need for a full-time auditor on staff! :-D
DerekT-P wrote:
I understand that of course ISO9001 has developed since 2007, but I'm sure it's still attainable to any micro-business, at very affordable prices and without massive overheads. Certainly no need for a full-time auditor on staff!
An existing employee could be designated as the auditor at that time. With you being the sole proprietor it would have been you. We also appointed an employee as the internal auditor for the first year, but the workload was too high. Had to hire a new FTE for that role. The ISO standard has been revised over the years. After chatting with @GregUtas yesterday I checked and the documentation process was changed in 2015[^]. I wasn't kidding when I said it was damn near impossible to follow.
-
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
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[^]
-
Me too! It's why I also prefer to work alone. It seems that the larger the team the more rigidity is required -- Scrum recommends development teams between three and nine members. Scrum would slow me down.
In my experience, the best teams (in terms of work environment and output) are where the team members are given expectations and allowed to work solo. One of the expectations is to communicate ad-hoc with others as necessary, without some project manager trying to manage such discussions or make a team meeting out of every minor question.
-
I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements. However, there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month. I'm a loner programmer myself and I've always planned my projects by tasks. Now that I do work with a team I find the Kanban approach works well without all the red tape of scrum. Maybe you and your friend could try Kanban, or your own version.
If you think 'goto' is evil, try writing an Assembly program without JMP.
In most cases, project managers and scrum masters are not software developers. They too often see software development as a bunch of developers on an assembly line, putting software widgets together. That is because much of what has been applied to the Agile Manifesto comes from the manufacturing and automotive industries. They have a hard time understanding how, in the "widget assembly" paradigm, you can't know the exact amount of time a software project will take, or how there could be unknown impediments that only appear during development, not design and planning. IMHO, a senior-level software engineer who is good with "people skills" and can lead (not just manage) is who should replace the slots occupied now by project managers, business analysts, and scrum masters. Neither Scrum nor Kanban work well for software development but do work well in manufacturing. The proper role for project managers and business analysts is as assistants to the project lead (who is a software engineer as described in the first sentence of this paragraph). My preference is to meet once a week to outline progress and setup the work for the week, then let the developers work on their own to accomplish their work. Stop with all the metrics that are better suited for manufacturing, and just measure progress once a week at the weekly meeting by what is actually accomplished. Results matter much more than process.
-
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
Sander Rossel wrote:
As far as I know he's not on the autism spectrum.
Also (with few exceptions), everyone is on every spectrum -- hence the name.
-
Waterfall: "We can't do that until the next release in around a year" With Scrum: "We can't do that until the next sprint in a few weeks" That is why you will find people saying Scrum gives flexibility. It all depends on where you started from. So yes, people who says "Scrum brings flexibility" are completely right. Just as the people who says "Scrum is making the process too rigid" are completely right. Understand what the methodologies tries to solve - then understand your own processes (and the problems with it). Then you can choose the right methodology for your team. Only consultants think the same process is the answer to every situation (and strangely, it is always the one where they can offer you "services"). Personally my productivity can be pretty much killed by switching priority daily (or multiple times a day) and I have yet to see a team (let's say 5 people+) that is not more productive if they are allowed to work unobstructed for at least a few days. My personal preference would probably be Kanban - but to be honest our Scrum is already leaning in that direction just because we don't take it too too serious :)
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'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
-
I like waterfall so any last minute changes are things that will take 2 more years to add to the project. Then again clients don't exist in my line of work. :)
I agree, Waterfall is just Scrum with two-year sprints. ;P
-
DerekT-P wrote:
I understand that of course ISO9001 has developed since 2007, but I'm sure it's still attainable to any micro-business, at very affordable prices and without massive overheads. Certainly no need for a full-time auditor on staff!
An existing employee could be designated as the auditor at that time. With you being the sole proprietor it would have been you. We also appointed an employee as the internal auditor for the first year, but the workload was too high. Had to hire a new FTE for that role. The ISO standard has been revised over the years. After chatting with @GregUtas yesterday I checked and the documentation process was changed in 2015[^]. I wasn't kidding when I said it was damn near impossible to follow.
It's certainly true that ISO9001 is about processes rather than results. I found that by having documented processes, although there was a setup time initially, things actually did run a little more smoothly / with less input once in place. In that way it was more or less neutral in regards to my time (time saved vs. time maintaining / auditing the QMS) but I had better systems in place in the event of issues arising. By implementing a feedback loop with customers I was confirming that I was meeting their expectations and, with their consent, their feedback formed part of my marketing. But you're right in that there was no direct impact on the quality of the code I wrote or, for that matter, the advice I gave. As I found, there was a steep learning curve initially followed by an a-ha! moment after which it was relatively straightforward.
-
Well, and then there is me: Why on earth would you use a toolkit for MVVM. But I am starting to accept that either: 1) I did not understand MVVM and by accident created something that is way simpler to program 2) A lot of other people are misunderstanding MVVM. I do not care which one it is, as long as those toolkits are kept away from my software. :D
-
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
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.
-
Gerry Schmitz wrote:
then he should be an analyst too
Why? He isn't, he just makes pretty front-end designs (and implements them).
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
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
-
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.
