DevOps: Can R&d and Delivery work together? (#3)

Guest Post by Tommy Quitt - Business Mentor at WECHANGE

My previous blog was a bit pessimistic in a way. It concentrated on the differences between R&D engineers who think in a different way from their peers in the Operations organization. They’re interested in different things and use different tools. Still, today, organizations want to streamline their end to end processes from requirements all the way to go-live in one single process that will ensure quick and smooth delivery of the system to the customer.

So what should you do if you want an organization that fights less and works better together?

Shared Goal

It is imperative to set a shared goal around the main problem you are trying to solve. For example, if the main issue you have is that systems that are installed for customers are not stable you may decide to set the goal of “delivering a stable system that will maintain 99.99% uptime”. The contribution to that goal should come from both parties: R&D should build a system that does not crash, and Delivery should help by providing the right requirements early in the process, by stabilizing the implementation, testing in the labs, monitoring etc.

It is important to emphasize that with a shared goal, no single entity will be blamed on failure. It is the responsibility of the team to make sure that the goal is met. If failure happens, try to use it as a learning opportunity to see how the cooperation can be improved.

You may choose other goals, like delivering faster with less iterations to fix issues in production, you may want to improve performance, you may want to automate testing and deployment processes and a wealth of other possible objectives that may arise.

The shared goal has to be not only well defined, but also constantly reminded to the teams, especially in time of difficulty and crisis. In fact, remembering the shared goal is a good way to bring everyone back to the discussion table instead of focusing on the differences.

Processes

Keep in mind that end-to-end R&D to Delivery processes usually are more than the combination of two distinct processes. If you want to induce a real change, you must be ready to make changes to your existing processes to reflect the new way of working.

For example, product definition processes that traditionally do not take input from operations, should now include steps where system experts will be invited to define requirements that would be implemented in the product. This would be an opportunity for them to influence performance, stability, monitoring and other operational issues. Down the road, it also means that testing these requirements would become part of the responsibility of the product Quality Assurance processes. Just imagine what a big change this could be!

You may find yourself changing the Release process. If previously it involved only compiling and packing the product you may choose to build also upgrade and rollback scripts as part of the product release. This is something that previously used to be the responsibility of operations, but with a shared goal of smooth installation may move earlier to the product release stage.

In the same way almost every process in the organization may change. Keep your mind open and flexible. Do not cling to your existing habits.

Change Implementation

Try to be agile about the way you implement the change. People usually find it difficult to cope with big changes and respond better to smaller digestible adjustments. Additionally, there is no way for you to understand and plan everything before you hit the road. So simply do what we do in an agile product development: Go for continuous change that evolves over time, and prepare to be responsive to feedback from the field while you implement the change. Do not be afraid to change your plan as you go and make sure you are transparent about your motivations and your plans.

But these are only the first ingredients. Want the whole recipe? Hang on for the next post.