Are case-studies an effective way of getting efficiency-focused team members to be willing to trade some efficiency for quality? [closed]

Question

• Firstly, this does not suggest that efficiency and quality are in conflict... only that some methods prioritize them differently.
• Secondly, this is not a question of whether you agree with Scrum practice or not.

An expressed goal of Scrum is to create high quality increments of a deliverable product. This does not exclude that it might be done efficiently, but efficiency is not the focus.

Most programmers want to both deliver quality products and be efficient about it. Scrum's requirement to add product backlog items to a sprint backlog from the top of the prioritized list only... will often result in resistance from programmers, such as:

"But it will be more efficient if we add these other two items, from further down the priority list, to this sprint".

Perhaps the prioritization of the product backlog items could have been influenced differently by the Scrum Master, while working with the Product Owner. Such could be addressed in the next product backlog refinement session.

Setting aside such issues, are case-studies (of other teams' effective uses of Scrum) an effective way of swaying reluctant team members? (particularly on the issue of efficiency) Or, is there something better than case-studies?

Answer 1

Setting aside such issues, are case-studies (of other teams' effective uses of Scrum) an effective way of swaying reluctant team members? (particularly on the issue of efficiency) Or, is there something better than case-studies?

Case studies really are a poor substitute to general experience and even if people read them, it likely won't make any big difference.

Your problem is one of ulterior goals. A Scrum team is forward thinking only in terms of getting items into the backlog that need to be worked on. They are also forward thinking in "Sprint Zero" mode where they are planning the project overall, high level design and environment buildouts. That is it.

Everything else should be a short term goal for the scrum team, completing the next sprint to product owner acceptance.

If your team members are thinking about later rework then they are right to bring it up as a concern during Sprint Planning, but the decision to bring it into the sprint rests solely on the Product Owner. Rework is only a concern when the Product Owner considers it to be a problem but he/she should be aware of the technical implications of what she is committing the team to.

So how should you convince the team?

You need to get everybody on the team aligned with the same goal in mind. Report potential technical issues and risks, and spike when you don't have enough information, but ultimately, when you commit to a story your feelings should be left at the door and you should do it regardless of the down stream impacts. The team just needs to be clear about how much effort will be expended to do this and if it is realistic in terms of the allocated sprint time.

If developers are concerned about having to write a bunch of code that will be thrown away later then they are not aligned.

The goal is quickly delivering business value NOW, not preventing future rework. It is not about them and their worries about refactoring and future workload, get them to abandon these goals by stressing the importance of Minimum Viable Product and quickly delivering business value.

Answer 2

There is something better. It is called 'authority'. Product owner decides what goes first and what goes after.

However, it's expected from developers to communicate to product owner that some things might be more efficient doing one way or another.

That being said, authority is still the product owner, and based on the input from developers, product owner has to decide whether to stick to his plan or alter the plan a bit.

Professional developer is the one who informs the product owner of possible optimizations, but not the one who refuses to do something because "he believes so".