I announced to my boss that I would be hit by a bus in two weeks. After my tragic encounter only two development team members will remain with more than a year of experience with the products we have developed, a developer and QA guy. With 9 years of experience at the company I have accumulated a great deal of knowledge of the product. The inevitable question, “What does he know and how can we get him to share that knowledge in two weeks,” was posed. In formulating an answer to this question I quickly realized the areas which I would spend the most amount of time documenting and training would be things done prior to adoption of a number of agile practices.
What Hurt
Silos
As a fairly small development team we had some small silos of expertise. Projects were often tackled by a single developer from start to finish. The developer would set the design, implement, and release with little review. And when defects or change requests would come in it would be passed back the original developer. Occasionally a second developer might try to provide some insight into one of the steps, but most of the time the development process would be worked on by a single developer.
Code Review
Effective code reviews are hard to actually implement. And we were no exception. On the rare occasion that we would perform a code review it would be over a small percentage of the code. Suggested changes were rarely implemented because the feature was working and there was little to no incentive to actually change the code. The design had been settled and changing it would introduce additional cost in development and risk.
What Helped
Collective Code Ownership
Breaking down the silos was not a major hurdle in our agile transformation by applying the concept of collective code ownership. Our story writing and planning process quickly brought the entire team in to advise on the design of features. We tried to keep implementation details out of the stories, but by having the entire team available ideas would be tossed around. Members would suggest code from their silos to encourage component reuse, permission given implicitly to modify to their own needs. Rather than waiting for another developer to implement a required component or reinventing the wheel a developer felt free to modify any piece of code.
Pair Programming
Beyond just granting permission to modify the code, pair programming allowed developers to actually work together in developing a feature. Short of a Vulcan mind meld, pair programming is the best way to ensure multiple team members fully understand the design and implementation. While the code is being developed the code is under constant review, so improvements actually happen instead of being noted as suggestions and ignored.
References
No comments:
Post a Comment