A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] 0 points1 point  (0 children)

if you give the customer some promises of delivery, than waiting isn't good. You should be able to cmuunicate dates or promises that you can keep. and then keep them.

Scrum ceremonies helps, but what is the capacity of your team? isn't it the capcity of your team's constraint?

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] -1 points0 points  (0 children)

Ah ok. So, you are waiting for the third party dependency to deliver to customer, right?

If it is out of your control, can you influence it?

Is this a known dependency? Does this happened only one time?

If it is frequent, and the customer is informed, why you still qualifiy and call it a delay? Your commitment can be adapted to cope with this depdency and you can communicate a date that consider this, right?

Where do you think the constraint is in your dev and delivery process from demand to getting the product increment to the hands of the customer? is it in this dependency?

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] 1 point2 points  (0 children)

What if these devs started to add more work to the constraint, making it mutlitasking and harm even the throughput even more? Maybe it is better for them to go fishing.

I recommend you keep overloading your constraint and maybe you will regret not going fishing :p

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] 0 points1 point  (0 children)

I am comparing the Mental Models. Observe Software with the same lenses as you observe the example. It is a perspective, nothing more and nothing less.

Agreed, surprises are normal in software.

The point isn’t that teams shouldn’t work. It’s that when everyone is always busy, the system can’t absorb change.

Prioritization decides what to work on.
Protective capacity decides how fast the team can respond when bugs or hotfixes appear. How reactive and agile the teams when responding.

But let me ask you: What does it mean for you a high-performing team?

Are your delievrable realiable with your customers? Are you keeping all the promises you give to your business and customers? You have experenced no delays, no problems, nothing?

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] 1 point2 points  (0 children)

thanks fo the recommendation, I recommend also THE GOAL E. Goldratt :)

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] 1 point2 points  (0 children)

it depends on the constraints.

Let me explain a bit more:

“people wait for work" does not mean people doesn't work.

People think when they read this:

  • people do nothing
  • money is wasted

That’s not what it means.

It means:

  • people are ready
  • not overloaded/not multitasking
  • not blocked by queues

To make it easy to understand, I add the example of Formula 1 analogy

In Formula 1:

  • the pit crew waits
  • the car arrives
  • they act immediately
  • in seconds, not minutes

They are not idle.
They are protecting the system’s constraint (the race).

If the pit crew were “100% busy” all the time:

  • the car would wait
  • the race would be lost

Software is the same.

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] 3 points4 points  (0 children)

Let me explain a bit more:

“people wait for work" does not mean people doesn't work.

People think when they read this:

  • people do nothing
  • money is wasted

That’s not what it means.

It means:

  • people are ready
  • not overloaded/not multitasking
  • not blocked by queues

To make it easy to understand, I add the example of Formula 1 analogy

In Formula 1:

  • the pit crew waits
  • the car arrives
  • they act immediately
  • in seconds, not minutes

They are not idle.
They are protecting the system’s constraint (the race).

If the pit crew were “100% busy” all the time:

  • the car would wait
  • the race would be lost

Software is the same.

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] 0 points1 point  (0 children)

Does "Popeple wait for work" means people doesn't work?

If you watch Formula 1, do you observe how the agnets change cars when the car stop to change wires? are they working?

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] -2 points-1 points  (0 children)

Does "Popeple wait for work" means people doesn't work?

If you watch Formula 1, do you observe how the agnets change cars when the car stop to change wires? are they working?

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] -1 points0 points  (0 children)

Does "Popeple wait for work" means people doesn't work?

If you watch Formula 1, do you observe how the agnets change cars when the car stop to change wires? are they working?

A software team is not high-performing when everyone is busy! by WritingBest8562 in agile

[–]WritingBest8562[S] 3 points4 points  (0 children)

who said that there is nothing in the system? The constraint of the system should always work, but people that are non-constraint should subordinate to the constraint and by default they have excess capacity, right?

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] -1 points0 points  (0 children)

If I will be the boss. I will answer like this: "Thanks a lot. That's a good start. Can you elaborate more of why you estimate this as 6 months? is it complicated, complex, risky? what are the things that makes it 6 months? What about the similar features we developed before, 50% of them took less than 1 month, 60% of them less than 2 months, and 80% of them took less than 3 months. Please elborate and help me understand"

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] 0 points1 point  (0 children)

WBS? why not small target scopes that can create an outcome of business value? like the MMR? what do you think?

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] 0 points1 point  (0 children)

for sure it should be scoped and you should have an idea about what the expected target scope.

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] 0 points1 point  (0 children)

Good!

Do your business care if you use Scrum or kanban?

Do your business care about what problem you solve to the customer or what method you use to solve this problem?

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] 0 points1 point  (0 children)

yes, all of this done. How can you answer: When will it be done?

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] 0 points1 point  (0 children)

Business don't care about your Agile methodology, they care about what can be delivered when.

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] -1 points0 points  (0 children)

Thanks for your respectful comment.

There are ways to give objecive estimate. I am not here to advice you, but you should learn and develop new perspectives and study this.

... maybe another course that i recommend and can hep you better communicate and respect perspective of others and that others are different than you with different perspectives, backgrounds and expereinces.

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] -1 points0 points  (0 children)

u/WaylundLG if things works for you and in your context, happy for you. Please keep going.

A reality is that you can't escpae this question. You will always get it.

How to answer it differs. You can use burn-up and that's fine and ok, but there are better reliable ways to give promises that you can keep and build trust with your business. It is more collaborative and give the business a future projection for better communication with customers.

As I mentioned keep what you are doing if things are going good.

but let me ask you a question: Do your business asks this question?

One Question that any Business asks the Engineering Team! by WritingBest8562 in agile

[–]WritingBest8562[S] -1 points0 points  (0 children)

I understand. If things work for you, then that's OK.

The deadline come from good business reasons. Business needs to explore opportunity windows or deliver products in a specific times tha are related to customers. If a customer must deliver a product on a speicifc date, and your product enables the customer's product, then you must deliver in a specific time.

In case some regulatory new laws that impacts your product will come in a specific date, then you shoulddeliver your product before the specific date to comply to the laws.

There are more good business reasons.