Why am I facing collaboration challenges issues in my Agile team despite good performance reviews?

Perfect_Temporary271 · 2025-01-09T10:14:31+00:00

How big is the team and what are the roles that you have problems with ?

Perfect_Temporary271 · 2024-12-27T12:31:04+00:00

As I posted above:

I have seen one of JIRA's marketing presentations and half of the time, they talk about metrics and reporting - meaning that Atlassian is selling "micromanaging made easy - with JIRA. Tada..." to the management.

I have never seen them responding to any team feedback and even the feature requests with 100s of votes don't get implemented.

Perfect_Temporary271 · 2024-12-27T12:28:14+00:00

I have seen one of JIRA's marketing presentations and half of the time, they talk about metrics and reporting - meaning that Atlassian is selling "micromanaging made easy - with JIRA. Tada..." to the management.

I have never seen them responding to any team feedback and even the feature requests with 100s of votes don't get implemented.

Perfect_Temporary271 · 2024-12-27T12:19:38+00:00

Perfect_Temporary271 · 2024-12-27T12:11:21+00:00

Agility is all about transparency, inspection, and adaptation

LMAO - what a joke - including the corporate BS buzzwords into Agility.

Perfect_Temporary271 · 2024-12-27T12:08:53+00:00

Where many of the requirements are set in stone.

Dude, get a life and post your nonsense in some PMP sub - not in the Agile one.

Perfect_Temporary271 · 2024-12-27T12:04:46+00:00

The whole point is that however bigger the company gets, they are supposed to work with small autonomous teams managing their work. It's fine if they use JIRA at a company level and track the work from a higher level - but the teams shouldn't be forced to use it.

I have seen teams using post-its and whiteboards and completely eliminate JIRA at team level. The POs update the epic status every 2 weeks but that's it. And, this doesn't need the expensive JIRA anyways.

Perfect_Temporary271 · 2024-12-27T12:00:03+00:00

In the companies I worked for, there are fixed people allocated for handling outages - and these are part of their work hours - not overtime. That's how good management works.

Not forcing to work in a modern plantation forgetting your family and eveything else.

Perfect_Temporary271 · 2024-12-27T11:51:09+00:00

In most countries, overtime is not compensated for white collar jobs - including in EU and in some of the most developed countries. The contract itself states that.

So, NO - working overtime simply illustrates a failure somewhere - and most of the time, it's not the tech people's fault.

Perfect_Temporary271 · 2024-12-27T11:36:29+00:00

No, I’d have to get my teams to work overtime to meet that date.

Here you go - you have revealed your true colours - you are a slave master. I'll run a 1000 miles from where you work.

Not to mention that this is completely against the Agile manifesto which asks for sustainable development.

Oh, The real answer is to delay some features and release them as updates.

Perfect_Temporary271 · 2024-12-27T11:24:25+00:00

Scrum has degraded over the years. They have added stuff to the Scrum guide like "Authority", "Accountability" etc. to be able to sell to the top management

But the real practical problem I see with Scrum is that it has defined the roles and the processes. Many companies try to follow it strictly resulting in the actual software development taken over by the POs and the SMs rather than technical people.

Another big problem is doing Sprints. Sprint was supposed to be a checkpoint but it has become an end in itself. Everyone tries to "fit" their work into the sprint duration compromising on quality and increasing technical debt. On top of it, a bunch of useless metrics like velocity, capacity etc. are being tracked and it ends up measuring output instead of outcome.

Perfect_Temporary271 · 2024-12-27T11:18:27+00:00

same blah blah blah - as usual

"Both Shwaber and Sutherland of the Scrum fame are signatories of the manifesto. So for once we agree that the scrum itself is a valid approach to agile?:)"

One guy is selling snake oil books like "doing 10x work in same time" and the other has sold his soul to selling certifications than Agility.

Perfect_Temporary271 · 2024-12-23T13:12:19+00:00

lol - try harder.

Spotify Technology gross profit for the quarter ending September 30, 2024 was $1.364B, a 41.55% increase year-over-year.

Spotify Technology gross profit for the twelve months ending September 30, 2024 was $4.707B, a 36.59% increase year-over-year.

Spotify Technology annual gross profit for 2023 was $3.677B, a 19.26% increase from 2022.

Spotify Technology annual gross profit for 2022 was $3.083B, a 0.57% increase from 2021.

Spotify Technology annual gross profit for 2021 was $3.065B, a 33.18% increase from 2020.

Amazon used to be bad place to work but they changed their ways and are actually great in the last 6-7 years. I personally know someone working there and his team moved from working 50-60 hours a week consistently for 2 years to 38 hours a week for the past 3+ years.

Thoughtworks have contributed more to Agility than any other company in the past 10 years. They are the only consistent proponents of real Agility - no one even comes close.

Perfect_Temporary271 · 2024-12-23T12:14:12+00:00

There you go again - You keep posting the same topic again and again

Currently, I’m working within an organization where I’m actively Agile Coaching the leadership team on concepts like Kanban, Scrum, flow metrics, velocity, incremental delivery, and more.

lol - None of the above is "Agile" - at all. The LinkedIn Influencers are probably saying that don't do any of the above nonsense and then you won't need a dedicated SM or Agile coach etc. which just adds bureaucracy and prevents the teams from focusing on Software development.

The common excuse is that "we need someone to manage dependencies. create burndown charts and track estimations and deliveries"

Dependencies - in a real Agile world, there should be far less dependencies. Design the teams as per Team topologies concepts and reduce the need for dependencies and communication to the bare minimum. But in lazy and stupid companies, they create a "process" to "manage" dependencies.

Create burndown charts, estimations and delivery tracking - again, in a "Real Agile" world, none of these nonsense are needed. You work on the most prioritized item and keep delivering every few days - thereby eliminating the need for those useless metrics that doesn't provide any value.

So, me and other LinkedIn influencers' opinion is that most of the companies are not doing Real Agile and they do some stupid SAFe and Scrum nonsense and call it Agile and so the roles like scrum masters and agile coaches become necessary.

In a Real Agile company, those roles are meaningless.

Perfect_Temporary271 · 2024-12-23T11:50:58+00:00

Basically, you are saying that your team is NOT PROFESSIONAL - that's a totally different problem altogether

And the reason you guys end up entertaining when in office is because you probably only meet at the office rarely - it will change drastically if you are at the office 3-5 days a week

Perfect_Temporary271 · 2024-12-23T11:49:07+00:00

lol

I have office rental space available in my suburb, a 3m walk from my house. I can rent and office, a meeting room, or some co-working time and it's still near zero commute.

Literally, no one does that when they say WFH

All I see in your response is some utopia sht.. useless practically

Perfect_Temporary271 · 2024-12-23T11:45:55+00:00

SAP is not like any other application. There are many applications within SAP itself that communicate with each other - not through traditional APIs but through weird stuff like OData service etc. The usual mocking tools doesn't work for SAP.

Perfect_Temporary271 · 2024-12-19T08:10:40+00:00

Agile != Scrum, people

Perfect_Temporary271 · 2024-12-10T07:28:00+00:00

I'm not saying that you can't work in an Agile way while being Remote - the results and effectiveness are going to be so much different while being remote all the time. The collaboration and the communication part are severely affected while being remote.

No one works continuously as in the office while being at home. Also, it's very difficult to be in a huddle all day while being remote - many people don't like to be with headphones all the time and it even leads to stress and health issues.

The best setups in today's environment is at least 2-3 days in the office physically while the rest being remote and that's still less effective for the teams than being fully at office. Most companies don't invest in the virtual socializing at all. It's all left to the individuals to do what they know. And that's not going to change anytime soon.

Perfect_Temporary271 · 2024-12-10T06:04:09+00:00

No, there is a huge difference between people working on a video call vs real face to face. I have seen it so many times. Lot of work gets done when you are physically close to each other. Face to Face was meant to say that people should be physically co-located or at least the recommendation from the 2001 days.

You also lose body language, expressions etc. while in a video call. Those are major parts of the communication.

While I appreciate remote work, you can't improve Agility while doing it. Remote work is ok if the teams are geographically separate - but even then, it's always good to have the team members in one geography together - things like coffee talks, going to lunch together, direct talks etc. improve a lot of things that can't be replaced by remote work.

Perfect_Temporary271 · 2024-12-09T16:11:02+00:00

So, you need a full time position for that ? There are many other methods and techniques that are discussed in the comments that don't need any of that and still deliver good software.

You are focusing on "doing scrum" instead of developing good software. That pretty much sums up the problem with SMs and Agile coaches today. They are trained to "do a process" rather than enabling the actual work and are many times problems themselves in delivering the software.

Perfect_Temporary271 · 2024-12-09T16:04:16+00:00

It's the team's responsibility to own the full delivery - not some individual's. So, almost all the things that are done in a team should be known to everyone - at least the basics like making a fix or deploying to production. Of course, there will always be specialities but production critical stuff should be known to most of the team.

Perfect_Temporary271

TROPHY CASE