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
-
TNCaver wrote:
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.
Exactly this. I've even worked in a team where I wasn't allowed to pick up additional work if I finished my work, say, one or two days before the end of the sprint, because "we'll be planning that for the next sprint" :wtf: I'd just sit there and pretend to be working. Coworkers were just finishing up their work for the sprint so they didn't need my help either.
TNCaver wrote:
there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month.
Of course there isn't! However, when a client calls and says "we'd prefer you'd work on tasks A and B rather than what you're doing now" or even "drop everything, we need to do this work ASAP!" there should be room for that. I prefer knowing what I'll be doing the next month (if only because that means I have any work at all), but priorities can shift by the day.
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 could not agree more. I have a client that doesn't know what he wants until he sees what I have done. AND, any new need that pops up for his business, I have to drop everything and get that done. :omg: Very frustrating. I have to keep an Excel spreadsheet to keep up with what is done and what is not!
ed
-
lmoelleb wrote:
but I would also recommend you stop with remarks as "I know scrum should be the opposite of rigid, but that's not at all how I've experienced it" as that directly translate to "I tried to use this screwdriver as a hammer, and it sucks so it is a bad tool."
I'm really not the only one saying that and I think many people here would agree with me. Actually, I believe one of the writers of the original manifesto said something along the lines of that it was meant to grow more agile, but teams are now stuck in their scrum ways and holy two-week cycles. I think it's so hard to implement correctly because it's based around change and many people don't react to change very well. I've literally been in the situation where we were two days into a sprint when management came in and said, "things changed, we don't need what you're doing now, we need that other thing." And the team was like, bad luck, we're finishing this sprint anyway because that's what we committed to, and then start on the work you need. That's two weeks wasted! Or how about, this story has a very high priority, but we don't know if the business wants the button red or green, so we'll have to refine it further and it'll have to wait for the next sprint. That's not adding value, that's just mindlessly clinging to some process to the point where it does more damage than good. Two distinct teams by the way.
lmoelleb wrote:
Kanban is a known "lighter" alternative, but it might still be too rigid for you.
Kanban is actually fine! Not doing it now since I'm alone most of the time, but a good one for working with that designer. I'm working on growing the team and I definitely need something like that.
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
Of course many will agree Scrum is too rigid. Everyone who needs something less rigid that what Scrum gives them. Rigid or flexible is a relative measure. Stop treating it like absolute and assume something is "too rigid" or "too flexible" for every situation. It is fine you say "Scrum is too rigid for what I need - or "Scrum is more rigid that what I use". That is very likely to be the case. And if your anecdotes makes you believe "that is how scrum is", then you have no clue what Scrum is. You have seen someone doing something they do not understand and based on this, you now think you understand Scrum is not flexible. Both your anecdotes are 100% clear violation of the agile manifesto. Scrum and other agile methodologies can't fix incompetence... It's been a while (years) since I last abandoned everything in a sprint - but I have of course been in situations where it happens - and you just do it. Basically you remove any story that it no longer makes sense to work on no matter where you are in the sprint - and if that is all of them, then you remove all of them. Once you have no stories left, you have two choices: Start a new sprint, or pull in some stories in the current sprint. Do whatever works best for the team in the situation. If it happens now and then, no big deal. If it happens often, it is a sign Scrum is being applied in the wrong environment. Some more anecdotes to add to yours: Time since we accepted a story even though it was not ready for grooming: 15 days. It was clearly the priority, so the planning was longer than usual as a lot of things had to be discussed. Time since we have accepted a new story into a running already committed sprint: 3 hours.
-
I have had branches waiting for weeks or even months for review and release (this was before scrum), and they do not merge easily by that point - and as you said, going back into that code after such a long time is a churn.
That's despicable. For many years, the products I worked on used a proprietary code repository that dated to about 1980. A group owned each file, and one of its members had to open it for you if you needed to change it. You could work on it privately, but you'd ask for it to be officially opened once your changes were reviewed and you were ready to commit. Once the file was open, you'd commit your changes quickly so that anyone else working on the file could synch with your changes and ask for the file to be opened for their changes. Any significant delay in this process would get escalated to move things along. It worked quite well, though I can see it being a problem in open-source projects where escalation isn't possible.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
That's despicable. For many years, the products I worked on used a proprietary code repository that dated to about 1980. A group owned each file, and one of its members had to open it for you if you needed to change it. You could work on it privately, but you'd ask for it to be officially opened once your changes were reviewed and you were ready to commit. Once the file was open, you'd commit your changes quickly so that anyone else working on the file could synch with your changes and ask for the file to be opened for their changes. Any significant delay in this process would get escalated to move things along. It worked quite well, though I can see it being a problem in open-source projects where escalation isn't possible.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Ours is similar in structure, if not in timing. We each have our own repository with our own branches that we can push to the main repository when ready. They are then reviewed, any repairs made, and then merged with the development master and pushed live by the lead. I 'can' push things live, but only in 'emergency'. Our bottleneck is that we have only one reviewer and he's also an equal part of the dev team. So pushed branches got forgotten. I am hopeful that the sprint/scrum process will eliminate that in future.
-
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
Curious... Have you codified your areas of influence? Are there any limits on what you can arbitrarily change that affects this person? Typically, in these cases, we separate the resources and isolate their dependencies. So, you can have the freedom to change, within a framework agreed upon, so the other person has some solid footing. You clearly brought them in for a reason, and working to leverage that should be the goal. At the same time, I understand where you are coming from. We had someone refactor code (correctly to clean it up), but it impacted ~20 of other projects, a handful of which, were being actively developed. The resulting merges wiped out the value of the changes. Adding real costs to other peoples assignments. Which, to me, simply means... It is about communication and properly splitting areas of control... Put yourself in their shoes, if every day, you woke up, and you were having to rework everything you did for the last couple of days, because they were so "dynamic"... It wouldn't be long, before you would be better off waiting to see what tomorrow will bring...
-
Ours is similar in structure, if not in timing. We each have our own repository with our own branches that we can push to the main repository when ready. They are then reviewed, any repairs made, and then merged with the development master and pushed live by the lead. I 'can' push things live, but only in 'emergency'. Our bottleneck is that we have only one reviewer and he's also an equal part of the dev team. So pushed branches got forgotten. I am hopeful that the sprint/scrum process will eliminate that in future.
The main difference in our processes seems to be that, once you push, there's no need to merge. You've been working off the latest version, so your new version fits right in. Anyone who was working privately on the same file then has to synch with your changes before they can push. This relieves code owners of the task of having to merge incompatible versions.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Of course many will agree Scrum is too rigid. Everyone who needs something less rigid that what Scrum gives them. Rigid or flexible is a relative measure. Stop treating it like absolute and assume something is "too rigid" or "too flexible" for every situation. It is fine you say "Scrum is too rigid for what I need - or "Scrum is more rigid that what I use". That is very likely to be the case. And if your anecdotes makes you believe "that is how scrum is", then you have no clue what Scrum is. You have seen someone doing something they do not understand and based on this, you now think you understand Scrum is not flexible. Both your anecdotes are 100% clear violation of the agile manifesto. Scrum and other agile methodologies can't fix incompetence... It's been a while (years) since I last abandoned everything in a sprint - but I have of course been in situations where it happens - and you just do it. Basically you remove any story that it no longer makes sense to work on no matter where you are in the sprint - and if that is all of them, then you remove all of them. Once you have no stories left, you have two choices: Start a new sprint, or pull in some stories in the current sprint. Do whatever works best for the team in the situation. If it happens now and then, no big deal. If it happens often, it is a sign Scrum is being applied in the wrong environment. Some more anecdotes to add to yours: Time since we accepted a story even though it was not ready for grooming: 15 days. It was clearly the priority, so the planning was longer than usual as a lot of things had to be discussed. Time since we have accepted a new story into a running already committed sprint: 3 hours.
Look, I get what you're saying and we mostly agree with each other. I know scrum, I know what it's supposed to be, and I know how different teams implement it differently. All I'm saying is, I generally don't like the implementation, whether that's because people are incompetent or scrum is too rigid/time-wasting for my tastes is not really the issue. Besides, a big part of scrum is that you involve your clients and that's really the last thing my clients want (and also the last thing I want as my clients know absolutely nothing about software development or even what they want/need). Doing scrum by myself doesn't really make sense and doing scrum with a designer who just gets a bunch of separate assignments also doesn't really make sense (to me, at least). I have one larger customer who has their own IT department where we use a kanban-like approach (although not for everything). So let's agree to agree, or disagree, whatever makes you happy :laugh:
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
-
Curious... Have you codified your areas of influence? Are there any limits on what you can arbitrarily change that affects this person? Typically, in these cases, we separate the resources and isolate their dependencies. So, you can have the freedom to change, within a framework agreed upon, so the other person has some solid footing. You clearly brought them in for a reason, and working to leverage that should be the goal. At the same time, I understand where you are coming from. We had someone refactor code (correctly to clean it up), but it impacted ~20 of other projects, a handful of which, were being actively developed. The resulting merges wiped out the value of the changes. Adding real costs to other peoples assignments. Which, to me, simply means... It is about communication and properly splitting areas of control... Put yourself in their shoes, if every day, you woke up, and you were having to rework everything you did for the last couple of days, because they were so "dynamic"... It wouldn't be long, before you would be better off waiting to see what tomorrow will bring...
This guy has completely different assignments, most are creating some visual designs without code. As far as code goes, I told him to make a separate branch and do as he must and I'll figure it out later. He's only had to rework his original designs because the customer disagreed with a few minor aspects. And then make some new designs, while still working on old ones, because some priorities changed. Nothing too extreme, I'd say :~
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 could not agree more. I have a client that doesn't know what he wants until he sees what I have done. AND, any new need that pops up for his business, I have to drop everything and get that done. :omg: Very frustrating. I have to keep an Excel spreadsheet to keep up with what is done and what is not!
ed
Yeah, but don't tell them "no!" I'm going for customer satisfaction, they want something and I deliver (well, if it's possible with the means at my disposal, I now have a customer who wants front-row seats for back-row money, that ain't happening). Customers like working with me because I don't have all that red tape, they ask and I deliver. Sometimes not immediately, but always faster than their larger suppliers.
Slow Eddie wrote:
I have to keep an Excel spreadsheet to keep up with what is done and what is not!
I have that too, all teams have that I guess (or a scrum/kanban board).
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
-
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
