User acceptance testing, grinding my gears...

[PandaAttack1]

So a client gives us an exact spec for a very specific application. Asks us really nice to stay 100% within their spec. Don't apply best practice principles, just follow the spec to the letter.
Then after their UAT, they withhold payment due to this little precious note left on their testing results by their BA:

"Note: no auto-logout time was specified in the original instruction although it is a reasonable assumption of best practice."

What a welcoming Monday. I would like to flip my table now. It's a small fix, but I'm already tilted /////

 

[thePridge]

Flipping users! Though without users there'd be no reason to create systems.

As long as there's a paper trail then the BA should be told to take a hike. If they REALLY want auto logout then change request and invoice.

 

[PandaAttack1]

Flipping users! Though without users there'd be no reason to create systems.

As long as there's a paper trail then the BA should be told to take a hike. If they REALLY want auto logout then change request and invoice.

Unfortunately I will never know what the repercussions are or how the company handles it. All I get on my side is a "GET IT DONE ASAP" email.

 

[thePridge]

Unfortunately I will never know what the repercussions are or how the company handles it. All I get on my side is a "GET IT DONE ASAP" email.

Been there done that... still have the black rings under my eyes to prove it... lol. ASAP is normally something you get told around 4pm and have to have completed by 8am the next day.

 

[Lu22X]

Been there done that... still have the black rings under my eyes to prove it... lol. ASAP is normally something you get told around 4pm and have to have completed by 8am the next day.

Yep had far too many of those the last 2 years. At the point now where I'm like: "My work hours are from 07:00-16:00. That's when I'll work on it."

 

[Reegz]

Welcome to the wonderful world of coding.

In a perfect world, we'd be able to have fruitful discussions with product owners to really unpack their requirements and get the true picture before writing a line of code.

Unfortunately coding is not recognised as a craft so we're usually just expected to "get it done now".

In a well-managed environment the client would be change requested and there'd be an estimation and costing exercise done. From experience, this very very rarely happens.

From what you say, it sounds like any hopes of proper client expectation management left the minute the spec hit the table.

Good luck though!

 

[PandaAttack1]

Welcome to the wonderful world of coding.

In a perfect world, we'd be able to have fruitful discussions with product owners to really unpack their requirements and get the true picture before writing a line of code.

Unfortunately coding is not recognised as a craft so we're usually just expected to "get it done now".

In a well-managed environment the client would be change requested and there'd be an estimation and costing exercise done. From experience, this very very rarely happens.

From what you say, it sounds like any hopes of proper client expectation management left the minute the spec hit the table.

Good luck though!

All very valid observations and points; the welcome is warm, but far too late I'm afraid. Been here quite a few years. Only recently started losing my cool and putting my foot down. Guess the 'privilege' to do that also comes with the experience?

Sometimes it feels as if something is sitting on my head with a tiny chisel and a tiny hammer chipping away small parts of my sanity.

 

[Toxxyc]

 

[Reegz]

All very valid observations and points; the welcome is warm, but far too late I'm afraid. Been here quite a few years. Only recently started losing my cool and putting my foot down. Guess the 'privilege' to do that also comes with the experience?

Sometimes it feels as if something is sitting on my head with a tiny chisel and a tiny hammer chipping away small parts of my sanity.

Yes, I think when we start a new job we're cautious and try our best not to upset the apple cart, so to speak. We 'allow' certain actions or decisions which we'd ordinarily not be happy with for fear of causing a scene. However, this sets a precedent and bad decisions etc become the norm. We live with this until it gets to a point where we can no longer tolerate it and - as you so eloquently put it - we lose our cool!

It's a bad space to be in because you may find that every small thing starts setting you off; even things you ordinarily wouldn't worry about.

 

[Maxwell]

Dirty trick of the trade - don't have "clients", rather be a "technology partner". These may seem like simple terms, but it changes the dynamics. Spec does not follow best practice? Sorry - this does not meet our security guidelines - it is not in your best interest and we won't be rolling out. We are your partner and we want what is best for you...

 

[noa]

This sounds like a find absolutely any fault possible to withhold payment. Got a client that has been using the reports I made for the last 3 months without a peep other than praise, my boss sent them a quote yesterday now EVERYTHING is wrong with the reports, they're mathematically impossible etc etc.

 

[Anzarrah]

Hahaha looks like a Tuesday routine. Last 2 years we've adopted agile, and requests like these flow in daily.

 

[Reegz]

This post coming to you live from Sprint Planning!

 

[Manny]

Just finished UAT last week with my client. It delayed production deployment of new features by a whole month! Lots of back and forth with business, PMO and testers. It can get frustrating, but more so when business users are in disagreement with each other at times

 

[Reegz]

I'm pretty disillusioned with Agile; or more correctly - with the common interpretation of Agile in the workplace.

It's seen as a means of micro-managing development teams whilst providing them with a false sense of control over their delivery.

 

[PandaAttack1]

I'm pretty disillusioned with Agile; or more correctly - with the common interpretation of Agile in the workplace.

It's seen as a means of micro-managing development teams whilst providing them with a false sense of control over their delivery.

In all fairness, most dev teams need micro-managing. I've made peace with it... So now, when I feel hope, I suppress that feeling asap because I know it is false. Get everything done, yesterday. GG.

 

[noa]

In todays sprint they had no comments, everything was as they wanted it.
"But ja that pixel over there"
...

 

[PandaAttack1]

In todays sprint they had no comments, everything was as they wanted it.
"But ja that pixel over there"
...

Well, was something wrong with the pixel over there?

 

[PandaAttack1]

I've been assuming a more architect/designer role in our team, systems analyst if you will, and as a result more and more managerial tasks land on my desk. Feels good asking about the pixel more often than being asked about it.

I am slowly moving towards the other side of the table.

 

[Eon]

I'm a product owner for one of the Agile teams at the company I work at. When I get told I should avoid best practice I get that in writing. Always, so I can refer back to it when a BA drops a note like that. I am actually delaying development at the moment, for a a management sign-off in writing of something very similar to that.

 

[PJtheKILL3R]

It's seen as a means of micro-managing development teams whilst providing them with a false sense of control over their delivery.

I have now met quite a few developers that feel this way about Agile.

And to some extent I can understand it, whenever a sprint is planned, you almost feel like you are appearing in front of a court, asked to tell the whole truth and nothing but the truth, and throughout the sprint you are "cross examined" on that truth by logging your time spent on each and every bug/enhancement etc.

 

[noa]

Well, was something wrong with the pixel over there?

Padding from 4px to 5px. I'm glad we had a 1hr meeting for a pixel.

 

[PandaAttack1]

Padding from 4px to 5px. I'm glad we had a 1hr meeting for a pixel.

Fuck me, we had our whole dev team, managers and appies in a 40min meeting yesterday. 30mins of that meeting was spent arguing if a menu function should read "Book-In" or "Book In".........

 

[PandaAttack1]

Ooooooooooh, and we also had a lekker event after our sprint yesterday...

"Btw, I do not like your attitude. You are not my boss and you are always insinuating that I do not care about the detail or the client!"

"You're right, I'm not your boss. Also, I am not insinuating anything. I am literally saying that you do not care about the detail or the client."

*senior dev proceeds to pack bag*

 

[noa]

Ooooooooooh, and we also had a lekker event after our sprint yesterday...

"Btw, I do not like your attitude. You are not my boss and you are always insinuating that I do not care about the detail or the client!"

"You're right, I'm not your boss. Also, I am not insinuating anything. I am literally saying that you do not care about the detail or the client."

*senior dev proceeds to pack bag*

Sounds like you guys need a heavy christmas party, with a pair of boxing gloves to settle matters somewhere nearby.

 

[PandaAttack1]

Sounds like you guys need a heavy christmas party, with a pair of boxing gloves to settle matters somewhere nearby.

Guess that's what happens when you don't deliver and the pressure is on for final uat and hungry desperately clients waiting... 🤷🏻‍♀️

 

[Reegz]

In all fairness, most dev teams need micro-managing. I've made peace with it... So now, when I feel hope, I suppress that feeling asap because I know it is false. Get everything done, yesterday. GG.

It's a bit of a yes and a no on this.

I've had the chance to work in some really switched on teams and in some rather ordinary ones too. In most cases - almost without exception - the developers were pretty well-disciplined in that they were very capable of managing themselves and their delivery within their level of expertise. The same could not always be said about the BA's in the team.

Agile says that we need to hold each other accountable. I think this fails in the SA context because we're generally quite polite people and we don't really want to go out of our way to have the difficult conversations with each other; especially not in a public setting! So what happens is that we allow the weak links to keep pushing the same ticket around sprint after sprint and we listen to their half-baked stories each morning at stand-up; but we don't ever tackle this head-on. We'd rather leave this for the manager.

Contrast this with development teams in the US that I've worked with. They will not pull any punches when it comes to calling someone out.

 

[Reegz]

The one aspect about being a developer that no one ever teaches you is how to deal with the mental challenges of being harassed by all and sundry.

It's almost as if development teams - and particularly developers - are the whipping boys of IT projects. We get to carry the can for poor project planning, poor resource management and mostly piss poor business product development (functional specs).

Despite the best attempts of many, I still enjoy being in development.

 

[Ice_BuNNy]

The one aspect about being a developer that no one ever teaches you is how to deal with the mental challenges of being harassed by all and sundry.

It's almost as if development teams - and particularly developers - are the whipping boys of IT projects. We get to carry the can for poor project planning, poor resource management and mostly piss poor business product development (functional specs).

Despite the best attempts of many, I still enjoy being in development.

This ^

Someday's I believe I should just pack up and go flip burgers somewhere (I still do want that restaurant one day)
but the mental challenges of IT are insane, a badly drawn up design doc that you follow to the . and something goes wrong, Devs are to blame because you should just know it.
Question it, and you are almost immediately yelled at.
saying that, I have had some amazing bosses that always stuck up for devs and QA when it was needed.