|
It’s been 16 years since Agile’s creation, and by all accounts it does seem to have worked better than waterfall methodologies. But it is not a perfect solution. Agile must have succeeded: there are so many articles about it being dead
After all, Windows has been dying for a while now (and Java). And Leslie Nielsen.
|
|
|
|
|
Simple Programmer wrote: I recently did a quick audit on LinkedIn. For the search I did in London, of people with the current role of Scrum Master, only three of the 10 people I looked at have a software development background.
Almost every failed project I worked on or took over and completed was because the PM or CSM or whatever they want to call themselves had little or no software development experience. I consider this as one of the largest, if not the largest, expenditures for an IT organization.
|
|
|
|
|
I feel I may be repeating myself, but anyway - regarding Agile:
Agile is a team management methodology, not a project management methodology.
If you are using it for the former it works, for the latter it fails.
If you don't know what the difference is between those, you are why it fails.
|
|
|
|
|
Duncan Edwards Jones wrote: Agile is a team management methodology, not a project management methodology.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Duncan Edwards Jones wrote: Agile is a team management methodology, not a project management methodology.
Which word do you think management see from your sentence? 
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
This is a bit of an odd comment:
Quote: one study performed by Cast Software suggests that there is over $1,000,000 of technical debt, or problems with the code quality, in the average code base.
I'm not sure how they can come to that conclusion? What's average - $1 billion... $5,000..? In either case I can't see how you can end up with $1,000,000 of technical debt and in either case, it's not a big issue.
I haven't noticed any improvement with code quality since Agile started to gain ground. In the end, we have to write code - it's going to contain technical debt, performance and security issues as well as bugs, that's just the nature of it. One thing Agile does do well is push up the cost of projects!
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
As is usual, they mixed up the terms "study" and "dart thrown at a piece of paper with random numbers printed on it".
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The increased acceptance of remote versus co-located teams and the availability of effective tools that enable it are among the most significant trends affecting technology industry employment today. The purple one?
|
|
|
|
|
When will companies and their management realize that all three - having a private space to focus without interruptions, having a co-located group space during the phases of a project where being physically together is really great, and having the ability to work remotely when one wants to take a break from the daily commute or have a change of scenery (maybe it's a gorgeous day and you want to work in the park or on your porch). And the advantage with remote work is that you can more easily control the interrupts -- the phone calls, emails, and Slack chatter and not worry about someone tapping you on the shoulder.
We need all three, and all three are effective and productive when used in the right way and at the right time.
Doors? Even the middle managers at where I work don't have doors. They just have higher cubicle walls.
Marc
|
|
|
|
|
|
Marc Clifton wrote: When will companies and their management realize that all three ...?
Great post, I agree.
Consider this :
If the project were perfectly defined everyone could work remotely without ever meeting.
The less the worker bees understand what they are attempting to create the more they need to hear the chatter that the other worker bees are buzzing about.
Take an extreme example of this extreme idea:
Suppose the project were a form with three buttons. 1 red, 1 green, 1 yellow.
There are three remote devs and each is assigned one button to develop.
The most they have to do is let the others know they've added their button and possibly do a merge of the code. Very little communication is required.
However, if they are all told something like:
Poorly Defined Software Requirements
"Each of you needs to add a control to the main form.
What you do will depend upon what the other dev does."
Suddenly, each of the three devs is like:
Dev 1: "I'm going to add a droplist because I like drop lists."
Dev 2: "Buttons are easy to add and I can always add the event code later."
Dev 3: "I'll add a button because it shows up first in the tool bar."
This Is An Extreme Example
But now, think about all the talking that will have to occur now.
Once the form has those controls everyone will start wondering who is right.
Others may assume the drop list is correct just because they don't think someone would add that arbitrarily. Etc.
The Main Point
Maybe all bad software and all failed projects are simply because the requirements just aren't defined properly? Maybe 99% of the communication is because no one has actually defined what is supposed to be built and even when they do, they communicate it so poorly that real devs who write real code can't interpret the communication.
Boils down to Bad Management. Total cluelessness about how to actually run a software project and build real software.
If the requirements had been gathered properly and the system were designed properly devs could meet very rarely.
But those two things ain't never gonna happen. 
|
|
|
|
|
In my experience remote development only works when the remote developer is extremely experienced and highly disciplined.
|
|
|
|
|
Joe Woodbury wrote: In my experience remote development only works when the remote developer is extremely experienced and highly disciplined.
Agreed, but having an absolute "no remote work" policy is silly. Give people the benefit of the doubt, or if you'd rather, see how they work on site for a while then give them a trial period of remote work.
I mean, if, as a manager, you can't create clear milestones and determine if the work is being done, you've got problems that have nothing to do with people working remotely.
Marc
|
|
|
|
|
|
Marc Clifton wrote: I mean, if, as a manager, you can't create clear milestones and determine if the work is being done, you've got problems that have nothing to do with people working remotely.
That's why you need agile.
... I'm hoping I can run faster than you.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: ... I'm hoping I can run faster than you.
Only if you're more agile! 
Marc
|
|
|
|
|
I have a bit different observation.
Yes the discipline is mandatory, but experience not at all...
|
|
|
|
|
I'd disagree with you about experience. An inexperienced developer will spend too much of his time trying to interpret the requirements and constantly returning to the users for clarification. Or he will just get it wrong and have to redo the solution.
Do not talk to me about inadequate specs or I'll slap you with my used beer coasters.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
First I think there is a lot of room between "extremely experienced" and "inexperienced", nevertheless that problem is not related to remote work.
The same issue can occur in office and the same issue can be resolve from remote.
You can have collaboration, mentoring, pair programming, whatever... all done from remote as well.
I work in fully remote company and I can say that we never encountered that issue.
The only issue that can occur is the lack of discipline and organisation, without that no person can be at least an adequate remote worker.
|
|
|
|
|
If you lack experience of something, you need to talk with experienced people, ergo stay in the office.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
True, if only there was some way to talk to those experienced people from remote (*sarcasm*) ...
|
|
|
|
|
The phone and net meetings are no replacement for being in the same room as the person who's trying to pound new information into your head.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: phone and net meetings
Make me shudder
... such stuff as dreams are made on
|
|
|
|
|
Apologize, I don't want to sound rude, but that is some seriously limited understanding or remote environment...
So in your mind you would use phone and meetings to educate someone, really?
How about some desktop assistance, remote sharing, VNC?
Nevertheless, I've seen a lot of good and bad thinks that come from teleworking, but educating the newcomers is pretty much the same as if you do it in office.
|
|
|
|
|
Stating an honest opinion isn't rude; go for it.
But talking to someone at his desk, where he can scribble diagrams on paper, show you windows, point at things with his finger (and all the while you can see if he's shrugging, etc.), without his having to spend distracting seconds clicking and configuring things to make it possible for him to show you stuff just doesn't compare. Real, human contact wins, every time.
Plus, you have to book remote meetings, rather than just stroll over and chat (and maybe return a couple of minutes later for confirmation/expansion of details).
It's really tricky to use teamviewer/virtual whiteboards/WebEx/etc. at a coffee machine, or walking down the corridor.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
