Changing priorities - what to do?

"A team mentioned the following: We are unable to focus on the work, resources are being borrowed mid flight, we have to wait for env to be ready for testing/deployment , priorities keep changing and worst of all ; often we hear <Our resources should give their 100%>, now how the hell can we give 100% with these constraints?"

Those are six different problems mentioned there. Let's address them one by one.

#1 - Unable to focus

The more things you do, the less you can focus. It's easy to focus on one thing, yet impossible to focus on a dozen things at the same time. We lose focus when we lack clarity of what matters - and what doesn't.

Likely Causes:

• Lack of transparency concerning value
• Lack of clarity on the impact of multitasking on outcome

Possible Solution:
Create an environment where limited WIP is possible, encouraged and enforced. (it's always possible, the rest is management mindset)

#2 - Borrowing mid-flight

This only occurs when there is confusion in the organization on what is actually important - and why.
It doesn't even make sense to divert people from doing the most important thing they can do.
Again, that's a management mindset problem.

Likely Causes:

• Confusion around priorities
• Managers who are unaware of the disruptive impact of their behaviours. Closely linked to #1.

Solution:
Create a stable environment where only ONE priority 1 exists at a time.

#3 - Waiting for environments

Consider the "Developer's bill of rights" - if your organization isn't willing to invest into the best possible technology, you lost the game anyway.

Likely causes:

• Managers who forget the opportunity cost of saving a few measly bucks on tech. 

Possible Solution:
It's essential that technology is an enabler for developers, not an impediment. A company that doesn't let their developers maximize the value of their time is paying high-cost talented people for twiddling their thumbs and getting frustrated instead of delivering results.
Developers must create a plan how they would solve this and what they need, then management must grant both the procedural and financial way to move forward.

#4 - Priorities keep changing

It's very, very simple for managers to change priorities - yet very hard to get things "Done" when the priority is different before something is. 

Likely causes:

• This is the same as #1 and #2. 
• Manaers who are unaware of the cost of change.

Possible Solution:

Make the cost of change visible. Enforce a strict policy that any change to work which is currently in progress requires the requester to sign off the investments up to this point as "burnt money". For example, if you sunk 20 dev days into a feature already and priorities change, the requester of the new priority causes a loss of 20x10 dev-days, e.g., $20k to the organization. Ask them if that's what they want.

Accumulate burnt costs, when they approach hundreds of thousands (which they quickly do) ask if it wouldn't be better to hire more people.

#5 - Demand without enablement

There's a memorable quote, not sure I get it verbatim: "There's nothing more cruel than setting a goal without providing the means" - yet this is exactly what's described here.

Likely causes:

• Organizational structure
• Separation of accountability and responsibility
• Separation of Planning and Executing
• Management philosophy

Possible Solution:

This is a tough nut to crack and will definitely take a long time. It requires management to reconsider everything they are doing. At a minimum, managers must move from controllers to enablers - even this step can take years to be fully anchored.

#6 - De-humanization of workers as "resources"

That's entirely a mindset issue occurring in organizations where people aren't being treated as people.

Lean thinking is built on "respect for people". "Resource" in regards to people is a very dis-respectful concept that needs to be banished out of the organization, without any form of replacement. That alone will have a positive effect on motivation, morale and therefore, ability to get things done.

Summary

The good news: Those aren't many problems. They are all somehow different faces of the same coin. There is only one problem: a communication gap between managers and developers. Everything else is a consequence thereof.

At the heart of it, managers need to stop "doing manager stuff" and start talking with their people. Try to get NEAR.

A good coach can help here.

Q&A: Our Customer says that our software is buggy?

Question: "When a stakeholder says to the Scrum team that our application has a lot bugs although the team has a good test coverage, what could be the team's take on that?" (source)

Dear Saad,

that's a good question.

The simple answer: Tests do not guarantee high quality software. 

Many Scrum teams feel that when their DoD is met and the Product Owner has accepted their Product Increment, they are "good to go". 

They might justify their behaviour based on whatever was agreed between them and the Product Owner. That might be quite revealing if the PO is the person who claims there are bugs. That would make a great team alignment&trust topic to discuss in a Retrospective. The key question here would be: "What does justification help - does it help us earn money?"

When another stakeholder (e.g, prospective customers) evaluate the team's success, this statement reveals that team has missed something important somewhere along the line. It might be in their approach, in their DoD - or in their understanding of stakeholder needs. 

We could now get into an argument of "defect" vs. "bug" vs. "feature", but that doesn't even make sense, because we'd still have the problem of a dissatisfied customer that we want to resolve.

How should you deal with that stakeholder?

Ask them to clarify what they mean with "a lot of bugs". Let them show you examples. Pay close attention. Learn how they use the product and what is important to them. Be open-minded.There's a good chance you made past assumptions that can't be held up any more. Try to discover what you can do different in the future. 

While we can never rule out the possibility of an insane stakeholder, they are rare. Most stakeholders want a good product, although their understanding of "good" may differ from yours.

Here are some items you may need to consider:

From technical perspective:

First, you could have written the tests "around" the defective areas - and second,  there's this difference between "works as designed" and "works as intended".

From customer perspective:

When you walk into a fastfood shop and get a Chicken Burger with a glove in it, you don't care how many hygiene checks ("tests") the company has - you care for what you experienced.

Keep in mind the Agile Principle #1 "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software".

This leads to two questions:

1. Why all of a sudden "a lot of bugs"? Wasn't that stakeholder involved frequently?

2. Has the team aligned their definition of value and quality with the stakeholder?

I leave you with are a few extra questions:

1. Do you have good tests? 
2. Is your test approach adequate?
3. What is your defect strategy?
4. What's your approach to communication debt?

There are answers, but you need to find them by yourself.

All the best,

Michael