For enterprise level software organizations, technical leaders have to balance multiple concerns. Given the constraints of team members and time, the enterprise should find ways to create “re-usable” modules of code to lighten the project burden and avoid wasteful duplication of effort. I personally appreciate getting to collaborate with other technical leaders to some common project solutions. Two heads are better than one. Right? In our previous post, we outlined some of the challenges of growing a “share code” culture. This post will outline interesting themes to help steer your agile culture toward strategic code sharing.
Identify shared targets or missions: At the executive level, you have the perspective to see the requirements that cut across project boundaries. You can see the patterns of “common” requirements. Let’s say you have 5 projects that all require some flavor of data visualization. It might be interesting to facilitate a meeting to see if a shared code module approach might be attractive across these projects. At the C-level or portfolio level, it’s important to communicate these “shared requirement” opportunities. From the technical leader point of view, it’s important to promote clean code practices to encourage test automation and start building highly focused “lego blocks” that can be snapped together. Some of the “lego” blocks will become re-usable classes. As time permits, project teams can refactor and promote shared “lego blocks” to modules for consumption across project teams.
Staged approach to code sharing: In a post by Marck Oemar organization, he outlines a maturity model of shared code culture. At one stage, you might encourage software teams to open up their code repositories to each other and encourage them to document example code for some of the re-usable elements. This strategy starts communication across project teams. Teams can discuss opportunities to extract/refactor/encapsulate the shared code targets into re-usable modules.
Trust the shared code with happy customers in production: In Mark Oemar’s post, he hints at the idea that organizations should favor promoting “shared code” modules that have passed QA and has earned credibility in production with happy customers. I greatly value the evolution of Ruby on Rails. When DHH helped create BaseCamp, he did not focus on creating an awesome re-usable framework. He focused on creating a WOW product experience for his project managers while applying agile and pragmatic engineering practices. Once Basecamp started earning a revenue stream, DHH had the business opportunity and time to identify “re-usable” stuff into a library that eventually became the influential web framework we call “Ruby on rails.”
Plan and engineer together: : At this point, the enterprise has a strong “shared code” target that can benefit multiple project teams. In a post “Coding through silos (5 tips on sharing code)” from learningbyshiping.com, Steven shares some very practical ideas for planning the shared code approach across project boundaries. From the requirements point of view, it’s important to organize a backlog, negotiate priorities, and release plans. These planning sessions will need to discuss how to de-conflict requirements, draw good bounded contexts between projects ( a DDD discipline) and appropriately fund and allocate team members. On the engineering side, it becomes important to execute planning and sprinting together and agree on shared coding standards and quality targets.
Communication and Community execution: In any act of teamwork, it’s important for a leader to articulate and align a clear vision, incentives, resources, and plan for the project. In addition, it’s important for a leader to provide the tools and training materials required to execute well. On this front, I wanted to give a shout out to a wonderful a book by Jono Bacon called entitled The Art of Community Jono previously worked as the director of community for Ubuntu, one of the top Linux distributions. In this book, you’ll find coaching on planning your community engagement strategy, practical checklists, and patterns of communication. It’s cool that the book includes case studies of various popular opensource projects.
Leave a Reply