ThoughtWorks

[ChrisFromGreece]

Explains some of your posts, if you've gone the conceptual route and aren't hands on any more.

I'm a full life-cycle software engineer (which basically means I do everything (depending on gig) from high level design all the way through to implementation).

It's a skillset / requirement I see less and less these days which is shame as I firmly believe having experience of all stages of the software process benefits every stage.. Too many companies seem to want to partition people off as architects, coders etc.

Being a Technical Architect, I am still hands on. Probably not as much as a developer of course, but still hands on.

What do you want me to explain?

[LondonManc]

I got as much... but could say the same thing given the following statements (complete dismissal on various things):

Avoid Agile software development.

Avoid pairs programming.

Avoid any co with a Chief Scientist or similar, unless they are a genuine scientist and make things explode.

To have credibility, a scientist should have a PhD, no question about it.

The problem with agile is that 90% of the projects that I've seen claim to be Agile aren't run as Agile. There's either a failure to convince senior management to arrange their budget differently (this guys have delivered successfully under waterfall/v/JFDI for many years so have a different mindset) or nobody with the stones to attempt to convince them that an agile methodology is totally different to waterfall and explain with simple pictures how it works, including roles.

[eek]

I got as much... but could say the same thing given the following statements (complete dismissal on various things):

Avoid Agile software development.

Avoid pairs programming.

Avoid any co with a Chief Scientist or similar, unless they are a genuine scientist and make things explode.

Can't see anything wrong with the last 2 statements. Continual Pair Programming is a waste of money. It's better to do it once in a blue moon when you want to train people up or have something seriously complex to work out...

Anyone with stupid job titles that don't logically follow on from their actual role means that there are problems in the structure of the company. Mind you I spent 6 years calling myself a consultant when the consultancy wanted me to be Lead Principal Consultant or something to that effect depending on the mess they wanted me to fix at the time..

[ChrisFromGreece]

To have credibility, a scientist should have a PhD, no question about it.

The problem with agile is that 90% of the projects that I've seen claim to be Agile aren't run as Agile. There's either a failure to convince senior management to arrange their budget differently (this guys have delivered successfully under waterfall/v/JFDI for many years so have a different mindset) or nobody with the stones to attempt to convince them that an agile methodology is totally different to waterfall and explain with simple pictures how it works, including roles.

Couldn't agree more! That's my point, that if you don't run a project as Agile, 1) how do you expect to rip the benefits that Agile offers? 2) how can you blame Agile if it doesn't succeed?

As I mentioned on another post... to change the mentality and behavior of the frozen middle is the most difficult part in an Agile transformation.

[ChrisFromGreece]

Can't see anything wrong with the last 2 statements. Continual Pair Programming is a waste of money. It's better to do it once in a blue moon when you want to train people up or have something seriously complex to work out...

Anyone with stupid job titles that don't logically follow on from their actual role means that there are problems in the structure of the company. Mind you I spent 6 years calling myself a consultant when the consultancy wanted me to be Lead Principal Consultant or something to that effect depending on the mess they wanted me to fix at the time..

Avoid pair programming is as extreme as doing it constantly, so I lie somewhere in the middle, thus don't agree with the second statement. The third one I won't even touch it, I might explode!

I agree with stupid titles but for me it's more what you do rather what your title says. Last company I worked for, my title was Software Pilot. It still doesn't make any sense to me as I was a Tech Lead effectively... however all of the developers had the same title irrespective of seniority.

[LondonManc]

Couldn't agree more! That's my point, that if you don't run a project as Agile, 1) how do you expect to rip the benefits that Agile offers? 2) how can you blame Agile if it doesn't succeed?

As I mentioned on another post... to change the mentality and behavior of the frozen middle is the most difficult part in an Agile transformation.

Which means that there's no point doing agile if you're just going to pay it lip service; all it becomes then is an excuse for failed projects.

[ChrisFromGreece]

Which means that there's no point doing agile if you're just going to pay it lip service; all it becomes then is an excuse for failed projects.

Spot on!

You should only go for it if everyone is committed to it!

[LondonManc]

Spot on!

You should only go for it if everyone is committed to it!

So to senior managers who don't subscribe to it, but let agile "happen", it's JFDI as usual and means that they are responsible for less because there are no BRDs to sign off

[ChrisFromGreece]

So to senior managers who don't subscribe to it, but let agile "happen", it's JFDI as usual and means that they are responsible for less because there are no BRDs to sign off

In a nutshell, JFDI sums it up.

In reality, it's even worse than that.

In my company they tried to go with a mixed model as in Development streams under the Programme should work in an Agile matter, but Programme level should be Command and Control.

That happened because the ask for the Agile Transformation came from way up above, but frozen middle were not that keen... and during the initial roll out, the metrics were at the team level, so they could game it.

So we ended up with doing pretty much twice the work. I.e., BAs and Technical BAs spent months on BRDs which the business signed off, and then the BAs (assigned as POs) had to convert the BRDs into User Stories to be sized and prioritized. At the Programme level the projects were still marked with a RAG status as per the "normal" way of doing things.

[Antman]

The way I see it is that although agile is the buzzword-du-jour and that's fine and dandy, how can any board sign-off on something that they don't know how much it'll cost and when it'll be delivered.

Agile software development methodology is fine but how can you report on progress to shareholders? So you're always going to have a point as you go up the org. structure that the way the project gets done isn't important anymore but the dates and cost are. Hence frozen middle ground.