Improvements As Experiments
When change is presented as a mandate or “best practice” there are often destructive consequences that undermine the intended benefits. A better approach is to reframe and carry out improvement efforts as experiments. This can facilitate deeper learning and team building, not to mention create added value in unexpected ways.
This is the fourth article in a five-part series excerpted from the new book The Human Side of Agile. Part One looked at the Agile team leader’s responsibilities, Part Two described the team leader’s relationships with various role players, and Part Three showed how to help your team embrace the continuous improvement mindset.
Some changes, especially those coming down from management, are enacted as rules. For instance, some companies put in place the rule “X new unit tests per programmer per iteration” before starting a more formal Agile transition. Another popular rule is, “A story’s not done until its owner has applied the code reviewer’s comments.” The team or management establishes these rules for a good reason, such as improving quality or reducing costs.
This approach usually has two shortcomings, however:
> The rules are predetermined to be the right measure. No attempt is made to assess their effect on performance. Sometimes they cause an unnoticed reversal elsewhere
Please log in or sign up below to read the rest of the article.
|
Don't be humble. You're not that great. - Golda Meir |




