Project to Product
I want to focus on one specific aspect of project to product development from the Open Source First article. Coordinating upstream (publicly licensed) and downstream (private non-licensed) development work. In any organization that is developing and supporting software, there are some number of engineers that work on public projects. It is a common problem that the Development Managers and the Scrum Masters do a poor job of tracking that public work. Let’s assume that the Development Manager is aware and supports the public development work.
Support the Developer
What typically happens is that upper management is not aware of what the upstream work purpose is and its importance to supporting the overall development strategy. What likely started as support or even direction from the Development Manager to work on the public project evolves into a fog of light understanding.
Many months later, when performance reviews and head count updates come around, typically the upstream developer gets lets left out, as the public work is not part of what upper management understands. This leads to either dropping the upstream work, alienating one of your likely best developers, and/or the upstream work continues, but with zero Development Manager insight. In some cases all three things happen, in which case, you now have a increasingly separated, forked development effort, with a increasing annoyed developer, that is going to be putting in more and more time into the public projects. Not a good workplace situation for the developer or the manager.
Treat Public Projects Like an Company
It takes more work, but there is a proven solution. Treat the public projects like another engineering organization. If you are going to work with another engineering team, you expect to have a clear understanding of responsibilities and timelines. You need to have the exact same expections when working with a public project.
Right at the beginning, when the developer has plans to work upstream, set out responsibilities and timelines. This is just as much to protect the developer as is it is the company. Define what the public work deliverable will be and when it will be delivered. Make sure your Product Managers understand how the public work contributes to delivering the product. Make sure the Scrum Master works with the upstream developer just like the rest of the downstream developers. The upstream developer is still part of the team. As the upstream work starts to take shape, get the code into a testable branch on your software pipeline. Make sure you have quality unit and build tests to verify the upstream work, so it can be more easily merged into your code base trunk when the time comes.
Track all your development work and report on progress. Highlight the upstream and downstream work. Update leadership on the upstream progress. Keep up to date with the public projects release schedule and strategy. Publish both your private release schedule along side the public projects release schedule.
Make It Happen
This is just the broad strokes. You will need to take this and put in specifics for your implementation. Organization structure and tools vary greatly, but hold to the basic tenants outlined above.
