|
I'm thinking 'adverse' would be more accurate.
|
|
|
|
|
Perhaps, now come up with a CCC clue where 'Facebookverse' is the solution. 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
"Moronic social media about poetry? (13)"
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I had to ask...
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Isn’t that where spider pig came from?
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
And want does a Spider Pig do? Cany he swing from a web?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Take a look, overhead.
TTFN - Kent
|
|
|
|
|
I suppose it has something to do with Marvel and the incoming films...
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
|
I don't know when it originated but it was in use by RAH in Time enough for Love and the follow up books.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
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! 
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
|
|
|
|
|
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.
|
|
|
|
|
Yeah, with two or three developers you can usually get away with just winging it.
More than three and you'll need some process in place.
Well, depending on the people you're dealing with I guess (but more people means more preferences).
I think it's easier for people like us to follow some process than it is for people who need a process to not have one.
|
|
|
|
|
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.
|
|
|
|
|
Does structure have to be a boolean?
Unstructured is chaos. Whatever structure "structured" has will be the wrong structure at some point, if the structure is considered paramount then you're willfully creating inefficiency.
|
|
|
|
|
It seems more like a floating point number, companies are saying they're doing a certain degree of it, but they're always off 
It's not like it's chaos, just that the priority of tasks often changes daily, instead of biweekly (or triweekly for some teams).
I guess it's more or less structured rather than structured or not.
|
|
|
|
|
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.
|
|
|
|
|
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" 
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.
|
|
|
|
|
And that's always been the case. Priorities change. I don't know what the "official" Kanban approach to that is, but we shift tasks between the "doing" and the "backlog" and the "on hold" statuses quite often because of shifting priorities. It doesn't mean you can't plan your day, it just means that sometimes you change your plans.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
TNCaver wrote: it just means that sometimes you change your plans.
And sometimes multiple times a day
Maybe this is also because I'm alone working on multiple projects?
I guess when you're in a team people have their own clients and projects and maybe there's a bit more stability.
|
|
|
|
|
How many clients do you have? Because if I drop whatever I am working on because client "A" think it is important... what about clients "B-Z"?
Support cases gets priority (i.e. the product can't do something it should be able to do and it affects their business), but besides that we can't interrupt the team every time a client gets "a good idea".
|
|
|
|
|
A couple, but sometimes it's like that.
Last month, I had months of work ahead of me, but someone quit his job and months of work kind of evaporated and priorities for this customer changed quite a bit.
Yesterday I had a call with the customer and we're now going to pick up a new project while postponing the previous one.
So, I now have weeks of work for this client alone, while yesterday I had none, while last month I had months (talk about churn) 
Of course, that resulted in other customers getting more priority with their changes.
Meanwhile, another customer called this morning, his reporting didn't work, took me half a day to fix.
Of course I'm not doing everything ASAP, but when a client calls it usually has to be scheduled in later this week, or at least somewhere this month.
|
|
|
|
|
Scrum grew out to solve a different problem that the one you have. It was an answer to the world of large teams running waterfall with Gantt-charts and other horrible things.
So I would cross that one our right away in your situation, 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."
Kanban is a known "lighter" alternative, but it might still be too rigid for you. Look at it and see if there is one or two things you can take our of it - maybe as little as a prioritized list where you show restraint from changing the top item unless really needed is enough. I have seen teams receiving "Why is that feature I asked about just before the last two emails asking for urgent features not finished yet" emails while they are still working on the last email. A list makes something like this apparent - it it might also make it easier both for you and the customer to judge "do I REALLY need to change the priority right now, or will tomorrow do".
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
