Transparency or inspect and adapt is central idea in Scrum. When you start breaking windows on a project you get:
- A developer had 2 hours for actual coding and 14 hours for defect resolution on a single feature. When prodded the developer admitted that they really didn’t expect any defects, but the actual coding would probably take about two days along with some needed refactoring. Rather than explain that this simple feature would take over two days of coding because it involved a lot of design changes the choice was to hide the work in defect resolution. My reading, not knowing better, was you were going to slam some crap code in about 2 hours and then you expected a lot of defects. Instead this developer was doing the right thing, but not letting the product owner really know what was going on. The developer felt like they needed to have some buffer time to maintain the quality of the code, but they felt guilty trying to explain that to the product owner and Scrum Master.
- Product owner only informs management that a decision has been made on running a 30 versus 35 day iteration. The team has to find out about the decision days later from their own management chain. Self managing teams have a really hard time when important decisions take place without their input and even then decisions are only slowly leaked out.
- On some teams they don’t have impediments anymore. They still have them, but they’ve assumed that no on will act on the problems so they just take them for granted. Thus they may be waiting on someone so they can move forward, but they don’t even bring it up and suffer in silence.