This is a quick blog post in response to a question I received on a previous article: Close the gap between R&D and Customer Support. Between my long-winded answer and the fact that this subject deserves a post on its own, I decided to respond here.
I came from Google, search for interface between R&D and CS and apparently I came to the right place. Most of your article is clear to me as we are doing it day to day, more or less. Although I’m in the opposite chair (CS manager), I do understand the pressure on R&D as well as on CS. Question is, in an organization which has a habit of issuing new sub versions and major versions quite often (and of course CS attention for bug solving decreases) what can be done in order to assure timely bug fixes, as well as keep releasing new versions as often as possible.
The question of “how to manage frequent release cycles with minimal turmoil and maximum alignment (R&D, CS, Marketing)” is a good one. I highlighted our processes and best practices that worked well for my team. These should not be a surprise, as they are aligned with the agile development best practices. However, note that implementation and execution of these practices require vigor and disciple for all parties involved. I would love to hear from others’ experiences.
Depending on your situation, management and development processes, organizational structure, or a combination of both will help you build a solution that best works for your organization. Please realize the different roles and responsibilities that are needed for successful execution. With that, build the needed reward and recognition into your structure for all involved. At the end, it takes a team to deliver, even if on the surface some happens to spend more time at the bench than others.
Agreed upon philosophy and decision-making framework for managing releases.
You cannot minimize turmoil and increase alignment if there is no predictable schedule or decision-making process for product releases. Your framework should help to:
- establish predictable schedules for minor and major releases;
- differentiate between minor vs. major functionality;
- outline a process for managing your “Big List” of functionality and capturing it as a product roadmap;
- establish an escalation process for resolving conflicts;
- publish and communicate the POR (Plan Of Record).
Small program team with regularly run scrums (2-3 times weekly) who prioritize, schedule and manage the “Big List” of functionality and upcoming releases.
Your small cross-functional team has the empowerment to:
- establish an agreed upon theme and set of features for each planned release;
- manage the product roadmap details (specific features and goals) for at least the next 2-3 release cycles (depending on your release schedule, of course);
- resolve resource conflicts by re-prioritizing scheduled minor & major release features;
- say ‘No!’ to urgent but unimportant requests, and follow up with ‘and here is what we can do instead’.
SCM infrastructure with a branching strategy to support your build & release cycles.
An effective branching strategy is needed to establish a structure for managing your code, delivering multiple releases and supporting parallel development. Note, this is a full time job (especially at the beginning) that also requires your senior engineers to be involved in the definition. Your branching strategy will impact your architecture, your code structure, how you version, how it fits with your build & test structure, and even how you document.
Test infrastructure, test automation and rich test library to support needs of your agile development.
Yes, a good test infrastructure is a must for quality assurance. However, to effectively support your branching strategy (creating new branches and merging back in), you need to pay even more attention to your test automation and test library by providing smoke tests, integration tests, compatibility tests, validation tests, regression tests, … Your engineers will thank you!
Organizational Structure
Effective management of engineering resources is required to support parallel development and multiple release cycles. Goal is to maximize engineering productivity by minimizing splitting of time between defect fixing and implementing future functionality. As it can be challenging to balance the short-term demands with long-term needs, many organizations establish a separate team to support the current products: Current Product Engineering (CPE) team. Focused ONLY on the current product bug fixes, minor product releases and closely aligned with Customer Support team, these teams usually have a separate reporting structure as well (to minimize distractions.)
As an example, to support our product customization needs (different than minor releases), we established a CPE team. This enabled quicker response to customers without impacting our product platform roadmap. However, it also further stressed our branching strategy and our release management process. In addition, the separation can increase the complexity of internal communications, as it means yet-another-team to coordinate and bridge silos with. Building your CPE team might be a challenge as well, as many engineers prefer to be on the cutting edge of development. However, right incentives and recognitions, along with focus on customer connection and satisfaction should help with your recruiting activities.
Final thoughts
In my experience, there is no perfect structure for managing frequent product releases with parallel development. As Deming’s cycle of: Plan, Do, Check, Act illustrates, this is a journey: it is an iterative process, that requires work and discipline. Hopefully these practices will help you get further on your journey.
What has worked for you and your teams?
Technorati Tags: product release cycles, current product engineering
sharing insights and practical ideas on product strategy and technology management
