This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Fixing What's Broken
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
Dan Gilmor: "One lesson is deceptively simple. When you remove the barriers to changing things, you also remove the barriers to fixing what's broken." This is in an article about wiki-webs, but also applies to Team Code Ownership, my name for the XP practice of not having individual code ownership.
Lasse Koskela: "Although everybody knows that the project management should take corrective action, customize the process, or whatever is within its power in order to bring the project back on track, we implicitly accept 'it was the process' as a valid explanation for our failures even though the people with the power did nothing"...
Perhaps the difference in cooperative improvements in wikis and in businesses doing projects, is that the wikis can have both anonymity (no blaming) and explicit permission to change things. To quote from Gillmor's column:
The Wikipedia articles tend to be neutral in tone, and when the topic is controversial, they will explain the varying viewpoints in addition to offering the basic facts. When anyone can edit what you've just posted, such fairness becomes essential.
``The only way you can write something that survives is that someone who's your diametrical opposite can agree with it,'' says Jimmy Wales, a founder of Wikipedia.
David J. Anderson wrote of "Manager as Permission Giver": "A line manager can act as this tipping person to change both the behavior of his staff but also the performance of his organization. The manager can change the culture by giving permission to change it.[...] One big caveat to this 'manager as permission giver', is the idea that the line manager must have gained the right to give permission from more senior management. The more senior managers may not be 'permission givers' themselves and hence, in order to change behavior, the line manager may need to pre-emptively up-manage the situation."
Team Code Ownership gives permission to the team to fix problems anywhere in the code, but it is restrained by practices of (1) requiring all unit tests to be passing before checking in the changes, (2) review/consent by the pair partner, and (3) of course, the acceptance tests must not stop passing as well, though that may be detected as quickly as a failing unit test. With Daily Standup Meetings and Open Workspace to encourage the team to communicate problems with the code, the entire team can be involved in the decision to fix problems and whether to do any big refactorings of the code.
Previous Topic
