|
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 
|
|
|
|
|
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. 
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).
|
|
|
|
|
Do you know where Agile comes from? Because the statement "Agile is the invention of project managers and is designed for their purposes" to me looks a bit strange when you know the history of agile.
|
|
|
|
|
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.
|
|
|
|
|
Working solo you can do however you want but once a second person is added there needs to be some sort of structure. Formal process for two people who know each other, probably not. But some form of "Here's what I'm working on. What are you working on? Are we going to step on each other's toes?" conversations need to happen.
I agree with the Kanban suggestion.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
MarkTJohnson wrote: But some form of "Here's what I'm working on. What are you working on? Are we going to step on each other's toes?" conversations need to happen.
Yeah, definitely!
But for me, they can be just that, conversations.
That's exactly how my first employer did it.
You fix that form, you write a new one and I'll work on a third. Are we clear? See you next week (or when someone has questions, or actually keep seeing you as we shared an office)
|
|
|
|
|
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 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.
|
|
|
|
|
I think your post is talking about two different things.
The first one is process. You don't need guidelines or rules to follow until something bad happens. Then you put something in place to reduce the chances of it happening again, even if working alone.
The second one is stability. I would also get annoyed if priorities were constantly changing. It's also not an effective way to work when you often have to drop one thing for another. Returning to where you left off takes time. And if you never return to it, you wasted time on something that wasn't needed.
The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
|
|
|
|
|
Greg Utas wrote: The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
True, but our churn is dependent on that of our customers.
If they have churn, we have it too.
The difference is that we're getting paid for it.
Greg Utas wrote: And if you never return to it, you wasted time on something that wasn't needed.
I've been hearing this a lot too.
Frankly, I don't really care.
It's nice when customers use your software, but if they don't, they don't.
As long as they pay for it it's not my time that was wasted, but their money.
|
|
|
|
|
I can see why you wouldn't care if the customer is paying anyway. It's probably a personality thing. Like your colleague, I don't like being yanked around in one direction, then another. I would tell the customer that churn has a cost and suggest that we work together to better determine the requirements in advance. If they didn't want to do that, OK, they're the customer. But not one that I'd gladly take on again.
|
|
|
|
|
Greg Utas wrote: I don't like being yanked around in one direction, then another.
I don't see it that way.
Obviously, my client doesn't really know where they want to go, or they do, but something changed.
I try to support them the best I can and if that means going from one direction, then another, that's fine by me.
And sometimes I simply tell them "I want to do that, but I'm also doing that other thing for John, so you should probably get together and work out your priorities and then get back to me."
Recently, I had to tell a client "look, two weeks ago you said this thing, which is what I did. Now you say another thing and I have to change it again. We really should prevent this in the future..."
But you know, stuff like that happens in business, things change, priorities change, people change.
Also, I charge by the hour, so it's all paid time, which greatly helps
|
|
|
|
|
I beg to differ.
Money is not the only reason I write code. Another reason is the satisfaction of knowing that people find it useful and are using it. Basically, I'm happy when my client are happy with what they paid for. This is also a good way to ensure repeat business.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
My client is so happy they said they'd prefer to ditch some really large suppliers in favor of me.
Unfortunately, that's not really an option right now.
I had two projects where a customer really didn't use what I wrote for them and that just sucks (although they did become a repeat customer and are now using another system I wrote and they're now even asking for yet another!).
They can be using your software to full satisfaction and still change priorities though.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Structure, with flexibility of course. Without it's all a mess of work hours but with no idea of the direction.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Too much structure can cause a lot of useless output.
My current example:
I'm testing the MVVM Toolkit from MS (which is based on the very popular MVVMLight from Galasoft).
When you install the NuGet package of the MVVM Toolkit it comes along with 6 or 7 other packages.
And when you create a new build it adds more than 100 files to your debug folder !!
MVVMLight from Galasoft did add less than 10 files.
|
|
|
|
|
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. 
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
