Guide to software developer job advertisements

"Must know languages/technologies X, Y, ..., Z" == "If you're good with a bunch of different languages and technologies, imagine how good you'll become at the one or two we actually use!"
 
cguy said:
"Must know languages/technologies X, Y, ..., Z" == "If you're good with a bunch of different languages and technologies, imagine how good you'll become at the one or two we actually use!"
Click to expand...
Or we have no idea what we doing so we're going to blanket a lot.
 
I would have thought "an Agile team" actually means "nobody knows what the requirements are"
 
zippy said:
I would have thought "an Agile team" actually means "nobody knows what the requirements are"
Click to expand...

This.

So often you get these agile teams where the business guys think "agile" means they can change the spec and/or priorities because the team is agile and can/should cope with it. I've had it here at the bank (which changed a bit for the better after fighting for over a year) and now I know of an ISP that started doing "agile" beginning of this year. Same old story:

Scrums are 30+ min long
Scrums turn into design sessions
Sprint planning on mondays for almost the whole day
Management disagreeing with the devs on story sizes
Changing specs and priorities
The project manager supposed to create/admin the tickets is only there for half a day.
Blah blah etc etc.

Same old scht. Told my SO to wait and see - in a month or two they'll have the team meeting about "why is this not working and how can we fix it" and then a couple of months after that the Agile "consultants" will be there to tell them exactly what the devs have been telling them all this time :D
 
Hamster said:
This.

So often you get these agile teams where the business guys think "agile" means they can change the spec and/or priorities because the team is agile and can/should cope with it. I've had it here at the bank (which changed a bit for the better after fighting for over a year) and now I know of an ISP that started doing "agile" beginning of this year. Same old story:

Scrums are 30+ min long
Scrums turn into design sessions
Sprint planning on mondays for almost the whole day
Management disagreeing with the devs on story sizes
Changing specs and priorities
The project manager supposed to create/admin the tickets is only there for half a day.
Blah blah etc etc.

Same old scht. Told my SO to wait and see - in a month or two they'll have the team meeting about "why is this not working and how can we fix it" and then a couple of months after that the Agile "consultants" will be there to tell them exactly what the devs have been telling them all this time :D
Click to expand...
Agile is the buzzword of the moment at that damn bank. And the more people talk about it, the clearer it becomes that they have no clue as to what it actually means. And then you have people saying how Agile is awful (I disagree strongly on this) but they can't even tell you what a scrum or sprint is.
 
Messugga said:
Agile is the buzzword of the moment at that damn bank. And the more people talk about it, the clearer it becomes that they have no clue as to what it actually means. And then you have people saying how Agile is awful (I disagree strongly on this) but they can't even tell you what a scrum or sprint is.
Click to expand...

Once you drop Agile and switch to CFS you'll never turn back.
 
Hamster said:
Once you drop Agile and switch to CFS you'll never turn back.
Click to expand...
I don't code much anymore, so don't get to deal with the nitty gritty of these frameworks, just the repercussions.
I don't know anything about CFS. Can you point me in the direction of some resources?
 
Messugga said:
I don't code much anymore, so don't get to deal with the nitty gritty of these frameworks, just the repercussions.
I don't know anything about CFS. Can you point me in the direction of some resources?
Click to expand...

Most people don't have a clue abut CFS, hence the problem :p

Common Fscking Sense
 
As my career has progressed I've seen a shift from more formal methodologies to just CFS. My current group's manager doesn't really tell us to do anything, but rather works with us on projects. Currently, being at the far end of the CFS spectrum, we create the projects we want to work on, and simply decide how to prioritize them within the group. There are no scrum sessions or sprints or extreme programming, we just do what the most effective thing to be done next is.
 
Last edited:
cguy said:
As my career has progressed I've seen a shift from more formal methodologies to just CFS. My current group's manager doesn't really tell us to do anything, but rather works with us on projects. Currently, being at the far end of the CFS spectrum, we create the projects we want to work on, and simply decide how to prioritize them within the group. There are no scrum sessions or sprints or extreme programming, we just do what the most effective thing to be done next is.
Click to expand...

See, CFS in action ^

What our team is doing right now is working rather well and very similar to what you describe. The basic ideas of Agile is there (sprints, stories, planning etc) but it is moulded and used in a way that works for us. It's not perfect but much better than you could ever hope for in bank. Our scrums are also quick and to the point and on days when they are not needed - we skip them.

We're lucky in that our lead/architect also shields us from all the politics and crap from above. All we need to do is rock up, focus on our work, goof around a bit and then focus on our work some more :p
 
Hamster said:
What our team is doing right now is working rather well and very similar to what you describe. The basic ideas of Agile is there (sprints, stories, planning etc) but it is moulded and used in a way that works for us. It's not perfect but much better than you could ever hope for in bank. Our scrums are also quick and to the point and on days when they are not needed - we skip them.
Click to expand...
Sounds like Agile implemented properly. That's really what the retrospectives are for - molding your process to work well for you and your team.

Hamster said:
We're lucky in that our lead/architect also shields us from all the politics and crap from above. All we need to do is rock up, focus on our work, goof around a bit and then focus on our work some more :p
Click to expand...
That's their job is't it? You're right! You're lucky you guys got someone that knows what they're doing!
 
A big part of Agile is continuous integration and continuous deployment. Once you adopt these you will wonder how you ever did things any other way.
 
deweyzeph said:
A big part of Agile is continuous integration and continuous deployment. Once you adopt these you will wonder how you ever did things any other way.
Click to expand...

Most organisations have been operating this way for years. Then some genius comes along and says "Hey, we are going to adopt Agile, so that we can release stuff quicker". They just like to throw buzzwords around.

A lot of execs have this idea that its ok to go live with a certain level of bugs in the system. They compare the cost of delay vs the cost going live with some bugs and then having to fix those bugs after go live.

In principle, this isnt necessarily a bad business decision, but more often than not they underestimate the impact of the cost of these bugs or they have grossly overstated the expected returns of going live.
 
The best part about Agile is getting to play Buzzword Bingo on your phone while you're in meetings :D

Also, do not forget about the best buzzword of them all: "Technical Debt". That excuse they use to allow a shoddy job now, forget about fixing it the next sprint all together and get really pissed off when the Agile Grim Reaper comes to collect one day.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X