From project-based to product-based development: succeeding with a you-build-it-you-own-it model
Blog: Capgemini CTO Blog
With the rise of digital and cloud-native technologies, application development has fundamentally changed, enabling unprecedented levels of business agility and creating the need for a shift to a DevOps way of working. In the traditional waterfall approach to development, phases were disparate and sequential: the business and IT requirements phases were siloed, as were the architecture and design phases. Given the limited duration and pre-defined scope for each phase, this has often been referred to as a project-based approach to application development. With the increasing uptake of DevOps, this traditional model has been turned completely on its head, and what used to be project-driven development is now product-driven development.
With a product-driven approach, there are no separate phases or siloed teams. Rather, a single team of cross-skilled people – a product team – works closely together across all aspects of development to ensure optimal outcomes, from provisioning to running the SCRUM team to product development, CI/CD pipeline, and product release. If a team owns a feature, it owns it end-to-end, so there is no longer a single team responsible for testing
and nothing else. It’s a you-build-it-you-own-it model in which everyone shares responsibility to maximize speed and agility.
For many organizations, shifting to a product-driven approach to development represents a major cultural and technological shift. To get it right and see optimal returns, there are a few considerations all organizations need to keep in mind:
Ensure it’s a joint initiative between business and IT. The reason for shifting to a DevOps way of working is to align business and IT teams and create a continuous feedback loop from both sides that allows for greater agility. Because of this, ensuring a DevOps initiative is fully owned by both the business and IT is critical to success. But achieving this can be a challenge given that development has historically been an IT-led and IT-specific endeavor. To be successful, the business needs to be a core part of the DevOps team. A POD structure should be composed of cross-functional and multi-disciplinary teams where the business (the product owner) provides continuous feedback, governance, and guard-rails to drive technology evolution, and IT brings in the right toolsets and controls to drive feature richness. But it’s not just about having new processes. This alignment between business and IT also represents a major cultural shift that leaders need to plan for.
Make operations an integral part of the process. One of the most important components of the continuous feedback loop inherent to a product-driven development approach is ensuring operations is woven into the overall DevOps process. Traditionally, operations has been an afterthought and a separate phase that was overshadowed by other phases of development and testing. In a product approach, the development team and operations team are one and the same.
In the POD- based model, developers have to think more holistically about factors like the automation of potential error or defect scenarios from the very beginning of the development process because they are ultimately responsible for fixing defects when they arise. If they don’t consider them or build them in at the start of the process, development isn’t going to be optimized or efficient. Because this emphasis on operations calls for a significantly different set of skills than what a traditional developer would have, a strong training and recruitment plan needs to be put in place.
Ensure you have the right tooling. We often see organizations struggling to fully realize the benefits of DevOps because the tools they use haven’t shifted alongside the significant process changes they’ve made. For example, while Excel and Jenkins are perfectly appropriate in traditional development models, Jira and Slack are more appropriate for the DevOps way of working.
Also, in an optimized POD-based shared-responsibility model, it is important to automate the maximum number of tasks that require multiple teams to collaborate for a single outcome. Test automations should include not just functional tests but also security, infrastructure, and network tests, otherwise teams will find themselves falling into the traditional model where multiple teams perform siloed tasks. Organizations need to rapidly shift from DevOps to DevSecOps, where security is no longer thought of as an external component or team.
Remember that velocity takes time. It’s important to remember for product visioning and grooming and release plans that it takes time for the team to achieve the level of collaboration and efficacy required to see results. We often encounter teams with unrealistic expectations about how soon they will see gains in agility and speed, but in our experience it takes at least four to five sprints along with a robust change-management and governance plan. Being realistic is important for managing expectations, and while it may take time to see high velocity, remember that once you do, it will continuously increase at a much faster pace than in the traditional model.
Rishi Kulkarni heads up the cloud-native practice at Capgemini North America and Jigar Pathak is a member of the application and cloud technologies solution team. For more information about how to harness the power of cloud and application technologies to make digital business a reality, access The digital CIO’s handbook here.
Author
Jigar has 19 years of IT experience in delivery and architecture of Digital transformation and B/OSS solutions.
Leave a Comment
You must be logged in to post a comment.
