Why Scrum is Stressing You Out

The cross team sound more Ike a meeting vs a standup. It sounds odd that the work is so close that it can't be stretched out to a inter team meeting with less frequency. Or are your work items that small and rapid that basically a sprint is like a day?

Nothing wrong with leads attending other standups or having thier own but all team members sound like a lot of overkill.
The cross team part is meeting + standup. Someone says what they did yesterday and they need something from someone else, else it blocks their thing and then it's a quick mini meeting between said parties.

Sometimes it's beneficial to know what people on different features are working but other times not so much...

But the leads are working on this so this should improve overtime with more defined teams and roles/responsibilities of each team.

But scrum/agile isn't the magic it's painted out to be. I think someone mentioned it's Waterfall is disguise and that's aptly put!!
 
The cross team part is meeting + standup. Someone says what they did yesterday and they need something from someone else, else it blocks their thing and then it's a quick mini meeting between said parties.

Sometimes it's beneficial to know what people on different features are working but other times not so much...

But the leads are working on this so this should improve overtime with more defined teams and roles/responsibilities of each team.

But scrum/agile isn't the magic it's painted out to be. I think someone mentioned it's Waterfall is disguise and that's aptly put!!
I think folks get confused with scrum and agile. They are not the same thing. The basics and intent of agile is to itterate quickly with constant feedback, negative or positive allowing improvement of the product vs waterfall where there is a large gap between product creation and release.

Scrum / Kanban etc are just methodologies to formalise that process. To be honest, my personal opinion is often that folks get hooked up in the process of Scrum and lose sight of the goal of agile.
 
I think folks get confused with scrum and agile. They are not the same thing. The basics and intent of agile is to itterate quickly with constant feedback, negative or positive allowing improvement of the product vs waterfall where there is a large gap between product creation and release.

Scrum / Kanban etc are just methodologies to formalise that process. To be honest, my personal opinion is often that folks get hooked up in the process of Scrum and lose sight of the goal of agile.
Interesting, I definitely need to look into this a bit more now. Seems uni knowledge is letting me down lol

I think you're bang on about losing the goal of agile, I'm yet to feel the "agility" of our current setup...
 
The cross team part is meeting + standup. Someone says what they did yesterday and they need something from someone else, else it blocks their thing and then it's a quick mini meeting between said parties.

Sometimes it's beneficial to know what people on different features are working but other times not so much...

But the leads are working on this so this should improve overtime with more defined teams and roles/responsibilities of each team.

But scrum/agile isn't the magic it's painted out to be. I think someone mentioned it's Waterfall is disguise and that's aptly put!!

Sounds like you guys have figured out your own version of Large Scale Scrum (LeSS).

Inter team dependencies will always exist in complex environments so having Scrum Of Scrum type stand ups and stakeholders from other teams in your teams stand ups are appropriate in organisations where features can't be maintained by single teams in its entirety.

Breakouts are an important part of stand ups to avoid going into solution mode during the stand up and freeing up people that don't need to be part of a further discussions.
 
Interesting, I definitely need to look into this a bit more now. Seems uni knowledge is letting me down lol

I think you're bang on about losing the goal of agile, I'm yet to feel the "agility" of our current setup...

Agile is the methodology. Its really about the culture change to go from a top down management structure to a more collaborative one where teams are able to have more decision making powers, are closer to the product and customer and can be open about the challenges in the delivery of the product. This is also where most agile environments go wrong. They think putting in a framework like Scrum is all they need to do to be agile.

Scrum, Kanban, Scrumban etc are frameworks to apply an agile delivery structure. It defines the ceremonies that you need to do to be able to work in an agile manner. The problem is if you don't have leadership, product and HR teams that understand the agile methodology and lead, specify product requirements and generally follow the agile methodology and culture its impossible to have a functional Scrum team.

A Scrum team needs leadership that can paint the big picture and give the vision and strategy the teams can follow. The product team and stakeholders need to break down that vision into product visions, features and PBI's in such a manner that the Scrum team can easily deliver on it.

Once a company has made the changes that agile requires implementing the software delivery framework that is Scrum is really easy. Generally most companies do it bottom up where they start with the Scrum framework and then after years of chaos either abandon it or finally realise its a top down change and see success.
 
Excrement by any other name is still ****.

All to get people to just do their bloody jobs.
 
Excrement by any other name is still ****.

All to get people to just do their bloody jobs.
Nah, the main purpose is to try and give clear instructions and handle the expected changes when things go pap.

Do you know how many developer and dev teams have broken/fractured due to requirement hell and scope creep? And then they take the blame rather than others?
 
At a high level, I feel like Scrum is really just a mechanism to encourage a bit of collaboration or coordination.

A standup is a quick check in about where you were and where you are, and if any blockers.

A sprint is just a way to break work up. It doesn't mean you need to get more done faster or launch something at the end of it, but does give you a moment to reflect back or plan ahead.

It doesn't really need to be any more complicated than that.
 
Sounds like you guys have figured out your own version of Large Scale Scrum (LeSS).

Inter team dependencies will always exist in complex environments so having Scrum Of Scrum type stand ups and stakeholders from other teams in your teams stand ups are appropriate in organisations where features can't be maintained by single teams in its entirety.

Breakouts are an important part of stand ups to avoid going into solution mode during the stand up and freeing up people that don't need to be part of a further discussions.
Bang on, we actually have breakouts during sprint planning.

Will read up more on LeSS.
 
  • Like
Reactions: B-1
Agile is the methodology. Its really about the culture change to go from a top down management structure to a more collaborative one where teams are able to have more decision making powers, are closer to the product and customer and can be open about the challenges in the delivery of the product. This is also where most agile environments go wrong. They think putting in a framework like Scrum is all they need to do to be agile.

Scrum, Kanban, Scrumban etc are frameworks to apply an agile delivery structure. It defines the ceremonies that you need to do to be able to work in an agile manner. The problem is if you don't have leadership, product and HR teams that understand the agile methodology and lead, specify product requirements and generally follow the agile methodology and culture its impossible to have a functional Scrum team.

A Scrum team needs leadership that can paint the big picture and give the vision and strategy the teams can follow. The product team and stakeholders need to break down that vision into product visions, features and PBI's in such a manner that the Scrum team can easily deliver on it.

Once a company has made the changes that agile requires implementing the software delivery framework that is Scrum is really easy. Generally most companies do it bottom up where they start with the Scrum framework and then after years of chaos either abandon it or finally realise its a top down change and see success.
Found the professional SCRUM Master...
 
Nope. Scrum Masters go to bed early.
I've never met a Scrum Master I thought added any value to a team to be perfectly honest. They seem like the kind of people who don't have the acumen to be business side BA's, nor technical enough to be part of IT.

Net result, trying to explain anything to do them is a fool's errand.
 
I've never met a Scrum Master I thought added any value to a team to be perfectly honest. They seem like the kind of people who don't have the acumen to be business side BA's, nor technical enough to be part of IT.

Net result, trying to explain anything to do them is a fool's errand.

That actually makes a good Scrum Master. As soon as they try and get involved in the solution or requirements definition they have misunderstood their mandate. The Scrum Master is there to own the process and empower people to follow the process.
But there are a lot of dodgy yes men Scrum Masters around. Really good ones are scarce in my opinion.
 
That actually makes a good Scrum Master. As soon as they try and get involved in the solution or requirements definition they have misunderstood their mandate. The Scrum Master is there to own the process and empower people to follow the process.
But there are a lot of dodgy yes men Scrum Masters around. Really good ones are scarce in my opinion.
Dont get me wrong. They should not get involved with the technical solution or requirements, but I'm talking about people who dont even grasp the development concepts properly.
 
Dont get me wrong. They should not get involved with the technical solution or requirements, but I'm talking about people who dont even grasp the development concepts properly.

Fully agree, a lot of Scrum Masters don't even know why they are going through the motions and have no sense of how to really guide people to adopt Scrum never mind the complexities of the sdlc. The role does need a good eye for the big picture and multiple talents so its not an easy one to be good at.
 
While on the topic of scrum, is getting a SAFe certificate a good idea as a software dev? I've seen them here and there...
 
Top
Sign up to the MyBroadband newsletter
X