Agile, again....

[Big Blue Plymouth]

It amazes me how many contractors moan about their clients work practices. I get it if you 'do' agile you want to do it properly, but if the client isn't doing it as you would, don't you need to fit around that? Obviously offer up ideas for improvement but if it falls on deaf ears then look forward to a longer contract :-)

Here's another thought; one of the reasons I went contracting was to experience different organisations and different work practices, both good and bad. To me these just fit in as part of that experience that you can bring to the next client.

Maybe it's just because I'm an antisocial sod that I dont want all this interaction in endless meetings.

I certainly don't want to bunk up with someone for a full day of pair programming on a Monday morning.

I'm getting old - probably only doing g this for another 8-10 years. These guys are young & seem to live & breathe the stuff. They've got their own technical blogs, go to courses etc in their own time.

I think I need to do one last push to get me over the line. Either that or find a time machine...

[VillageContractor]

It amazes me how many contractors moan about their clients work practices. I get it if you 'do' agile you want to do it properly, but if the client isn't doing it as you would, don't you need to fit around that? Obviously offer up ideas for improvement but if it falls on deaf ears then look forward to a longer contract :-)

Here's another thought; one of the reasons I went contracting was to experience different organisations and different work practices, both good and bad. To me these just fit in as part of that experience that you can bring to the next client.

Agile isn't a perfect fit for everywhere and so it needs to be tailored, and that makes sense. But ultimately any company that does something should do it well.

I completely agree that sometimes that you learn the most by making mistakes. But it sounds like this company is still either in week 1 of the agile adoption or not learning.

Personally it bugs me, because agile gets the blame for the client's wrong implementation.

[original PM]

Maybe it's just because I'm an antisocial sod that I dont want all this interaction in endless meetings.

I certainly don't want to bunk up with someone for a full day of pair programming on a Monday morning.

I'm getting old - probably only doing g this for another 8-10 years. These guys are young & seem to live & breathe the stuff. They've got their own technical blogs, go to courses etc in their own time.

I think I need to do one last push to get me over the line. Either that or find a time machine...

Yeah I have found this we have just bought in a digital team to do agile - which we are running along side out legacy platforms who all use waterfall methodology

and i get the job of making projects involving both work!

But I do find the younger coders (both contractor and perm) and happy to just do stuff, pair program, whatever

But the older ones are less enthusiastic - is this because they are old? is it because they are scared these young whippersnappers will show them up?

is it just the idea that coding, coding, deleting and coding again is not seen as the most effective way to do it? e.g. it is better to work from a clearly defined spec and if that takes 2 months to deliver then so be it - no need to tell everyone what you have done each day nor showcase your work every week or so.

[Big Blue Plymouth]

Yeah I have found this we have just bought in a digital team to do agile - which we are running along side out legacy platforms who all use waterfall methodology

and i get the job of making projects involving both work!

But I do find the younger coders (both contractor and perm) and happy to just do stuff, pair program, whatever

But the older ones are less enthusiastic - is this because they are old? is it because they are scared these young whippersnappers will show them up?

is it just the idea that coding, coding, deleting and coding again is not seen as the most effective way to do it? e.g. it is better to work from a clearly defined spec and if that takes 2 months to deliver then so be it - no need to tell everyone what you have done each day nor showcase your work every week or so.

Well to be honest, I think that's the only model under which I have ever delivered a clearly defined usable product.

So, yes - work from a spec to a 3 month plan (or whatever) and invariably you need to pull out all the stops at the end but a product is delivered and the job is done.

I haven't as yet worked on any Agile project where there is a final product. They have a headcount, get rid of the contractors, hand the work over to permies and the iteration count ticks upwards to infinity....

[vetran]

cheer up you can try our methodology.

You write a spec for developers with no standard. I mean we could use Prince or PMI nope we use own PM system
despite having spent years failing to deliver using it.

You say my part (Data migration) depends on A G & H which is being developed by the Middleware & ERP team. I have Structured it so the bits we are going to do will fall due when the relevant supporting part is done Dec, Jan & Feb in various QA systems & prod. We will use the following sources because that is what the MDM & ERP system dictated. I wrote an equivalent in access in 4 hours using text extracts its not complicated.

Now they are saying where are the dates for the data migration spec? Just invent some apparently.

They can't develop G until after go live.

Emails from the developer saying Dear Vetran please confirm point 1, 32 & 76 in the document (the ones the customer demanded backed by legal requirements as stated) and how this works (the bit with 6 diagrams that I could explain to 3 year old). I have resisted taking screenshots of the design document.

Now they decide lets use just the ERP system as source despite the fact they don't maintain the tables in the ERP system and they have no intention to do so. something I had already mentioned. MDM team are near to crying.

We are on our second PM.

Its heading for a brick wall.

Strange the other 2 projects the same size with no one in teh way where I have done the same without the methodology or the new team were done part time in 3 months and with applause.

[original PM]

Well to be honest, I think that's the only model under which I have ever delivered a clearly defined usable product.

So, yes - work from a spec to a 3 month plan (or whatever) and invariably you need to pull out all the stops at the end but a product is delivered and the job is done.

I haven't as yet worked on any Agile project where there is a final product. They have a headcount, get rid of the contractors, hand the work over to permies and the iteration count ticks upwards to infinity....

Now this is the bit everyone needs to avoid.

This assumption that as the delivery date approaches everyone on the project will start doing 10-12 hour days and work weekends - I have never understood that.

It is a 'thing' made popular by stupid people who think that delivering a project should be a hard arduous task with pizza until 3 am and everyone living on coffee and doughnuts saying 'Ra Ra Ra' aren't we great.

For those who have been doing projects for years n years it is no different to any other job - you need to plan and you need to deliver - yes it is often bringing in new concepts etc - but so what.

[LondonManc]

cheer up you can try our methodology.

You write a spec for developers with no standard. I mean we could use Prince or PMI nope we use own PM system
despite having spent years failing to deliver using it.

You say my part (Data migration) depends on A G & H which is being developed by the Middleware & ERP team. I have Structured it so the bits we are going to do will fall due when the relevant supporting part is done Dec, Jan & Feb in various QA systems & prod. We will use the following sources because that is what the MDM & ERP system dictated. I wrote an equivalent in access in 4 hours using text extracts its not complicated.

Now they are saying where are the dates for the data migration spec? Just invent some apparently.

They can't develop G until after go live.

Emails from the developer saying Dear Vetran please confirm point 1, 32 & 76 in the document (the ones the customer demanded backed by legal requirements as stated) and how this works (the bit with 6 diagrams that I could explain to 3 year old). I have resisted taking screenshots of the design document.

Now they decide lets use just the ERP system as source despite the fact they don't maintain the tables in the ERP system and they have no intention to do so. something I had already mentioned. MDM team are near to crying.

We are on our second PM.

Its heading for a brick wall.

Strange the other 2 projects the same size with no one in teh way where I have done the same without the methodology or the new team were done part time in 3 months and with applause.

You are suity and I claim my 50 Wispa Gold mini bars

[vetran]

You are suity and I claim my 50 Wispa Gold mini bars

I feel like Suity with this bollox! 35 years breaking things & I finally get caught

[greenlake]

Do they provide biscuits?

No biscuits. Will chocolate do....?

[milanbenes]

was involved in a Project earlier this year, new Project new .net implementation of one of the Business Suite products with integration to other existing Business Suite products.

One of my contributions was to confirm that all of the .Net Business Suite products involved have enough capacity for the new Demand.

I said to the PM, can you share numbers of Users, peaks of concurrent activity, data transfers, volumes of data, frequency.

This was in February.

They wanted to go live in September.

PM says, we haven't done that yet, capacity planning.

I says, why not ?

PM says, this is an Agile project and we're gonna do that in July/August.

I said Agile or not, adding capacity to these .Net Business Suite systems has considerable lead times, and if you start doing your calculations in July/August there won't be enough time to get the capacity in place before your goLive.

PM says, oh.

Milan.