Following are two strategies that can be used to align means. To provide you with some ideas. To start the discussion.

Patterning – Going Through The Motions

In essence, with this strategy the project team is told what the means are; the larger organization knows best. This idea originates from Jeff Sutherland in “Shock Therapy: Bootstrapping Hyperproductive Scrum”. If you have a new team that has no experience with Scrum, you will put a very experienced Scum Master in charge and he will set the rules. Relentlessly.

Only a few rules, that make up the basics of Scrum, but they have to be followed with strong discipline. The Scrum Master will make sure this happens.
Set the rules first, than, after a while, let go when it becomes natural. This is called “patterning”.

Continuous Transparent Feedback

A human system always communicates with its environment and based upon the feedback it gets from it, alters its behavior. If a group of animals will drink water from a well and one of the groups dies because of it, they entire group may search for a different well. If a company introduces a new product, and sees its stock plummeting because of it, it might change its strategy.

It is therefor essential that the project members get continuous feedback on their own performance and the environment. This is where the use of analytics, metrics, “in-your-face” information visualization and plain old coaching comes in. By providing feedback to the team on how well they perform under the current project rule set, they will adapt to more effective means if needed.

Two Strategies For Aligning Means is a post from: Project Shrink.

So, the question if specifications are worth the effort is legit. Jeff Sutherland quotes some research in this area in his article Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects

Two metrics are mentioned: the productivity of the development group and the defect rate. In a tongue-and-cheek definition, the productivity is the amount of features / lines-of-code build in a given time frame, and the defect rate is the number of bugs found per amount of features / lines-of-code.

The article of Sutherland mentions that there is a strong relationship between the completeness of the formal specification and the productivity. The better the sense of the developers is of the desired end product from a functional perspective, the faster the program.

The other way round with completeness of design specifications and the defect rate. The relationship between them is found very weak. So, writing more detailed designs before programming doesnt reduce the amount of bugs.

Leaving us with the question what can we do about defect rate and productivity. In the mentioned article the following options are provided for lowing the defect rate: early prototypes, design reviews and testing at code check in. Increased productivity is reached by early prototyping and daily builds of the software.

Specifications and Productivity and Defect Rate is a post from: Project Shrink.