In my last blog entry, I mentioned the Devops culture was often counter-intuitive for larger enterprises. How do we then implement DevOps in such companies? Remember, DevOps is a culture built on collaboration and communication across all IT professional units and key stakeholders while automating the process of software delivery and infrastructure change. From that perspective it is a fundamental change in the way IT departments operate. Rather than operate around technology silos, the idea is to rally resources around value streams, enabling a smooth evolution of a functionality from initial business requirement to fully functional module in production. This requires communicating and working together across organizational boundaries. Such fundamental transformation of an organization is not done in one day. This is why I suggest a step-wise approach focused around people, processes and technologies.
DevOps is not for all applications
A DevOps and Agile approach may not apply to all applications in the organization, so the IT department will, for the foreseeable future, have to combine the traditional way of working with teamwork performed by empowered groups. The only way to implement such transformation is by having the teams themselves experimenting the change in their daily work and build on the internal experience and the drive to innovation. I’ll describe a way to achieve this in a minute but let’s first discuss where we could start.
How do we find candidates?
In previous blog entries, I described a way to analyze your application portfolio, based on a simple 2*3 model, you see depicted in the picture here under.
DevOps adds most values in areas where regular releases are expected. The more releases, the more automation increases speed while reducing effort. As your company evolve to the digital enterprise you may want to experiment with new business models, with other ways to interact with your clients and end-users. Business teams must be able to experiment as the outcomes of such new approaches cannot be guaranteed upfront. This points to systems of engagements, the systems that interact with the end-users. For that reason, systems of engagements are the right place to start.
In the move to the digital enterprise, the business wants to differentiate itself from competition to disrupt the marketplace. So, it is not just any system of engagement that is the best candidate. We would argue the best place to start is with CORE systems of engagement. In Geoffrey Moore’s definition, CORE is what differentiates your enterprise from its competition. CORE systems are the ones supporting the true company differentiation. So start by asking yourself what is CORE for your organization. The applications you identify as CORE systems of engagements are ideal candidates for implementing agile and DevOps approaches. Systems of innovation could be considered as an alternative. However, these systems are originally developed for experimentation and there is no guarantee they will deliver lasting benefits to the company. From that perspective they are less visible throughout the organization.
Implementing DevOps, one step at the time
Changing the way your teams are cooperating cannot be imposed top-down. For that reason I suggest to start small and have one or two teams experimenting with agile and DevOps. I would propose you to work closely with the business, understand what business processes they are looking to transform or create, identify the applications that support those processes and finally assess the development teams to understand which one is most capable of pioneering new development approaches such as agile and DevOps. This team is your candidate.
Once you have one or two teams identified, set-up a one week workshop where you get the developers and operations people in the same room. Ideally also get key business representation from the areas they are working on right there with them. Alternate training, discussion forums and actual working sessions. Train them on the concepts surrounding DevOps, allow them to discuss their future way of operations, what they will change, what key operating principles they want to highlight and how they will self-organize their teams. The training should be given by specialists that remain on hand during the whole time and become their coaches and go-to team every time they struggle with one or another aspect of the change. Have them also experimenting with the tools you’ve chosen (and we will come back to that choice).
When the week is over, have them return to their work, but ensure they operate along the principles defined during the workshop. They will start working in sprints which will allow you to quickly see progress. Keep the coaches available on demand during the first one or two months. Communicate widely about what the team is doing, what the benefits are and what they achieve. Celebrate visibly each achievement. The objective of this is to demonstrate to other teams that this new approach is interesting, cool and fun. You want to attract more people as, once you are convinced of the benefits of the new approach, you will want it to spread across the organization. You will want to identify the next one or two teams you want to transform. This time, rather than using external coaches, identify some members of the first teams and have them sharing their experience. It recognizes the pioneers while making things more tangible for the next group.
Over time increase the teams involved. When all your CORE systems of engagements are further developed using agile and DevOps, include the CONTEXT ones. For systems of innovation, wait till a new development is started and initiate the activities directly using the new approach.
As most systems of records will not gain much from going agile/DevOps due to the low number of changes required, you will have plenty of work for your employees not willing to experience the new approaches.
What tools to use?
I’ve been talking about the human side of things, but there is also an automation side. Where do we start here? In parallel with the workshop, start looking at the automation. Maybe you’re already doing something. If not, you may want to look at Continuous Integration first. This implies the automation of most of the testing. Have your test engineers think through how they could automate some of the tests they already do. Do that during the workshop. Make sure they get help for choosing tools and methods to automate testing by including a test coach.
Change the way development is done. When developers work on some new functionality, have them first describe how this functionality should be tested. Their colleague responsible for testing will then automate the test procedures while they develop the software. As soon as a first version is out, it can be tested. The benefits, a faster identification of issues. This ultimately benefits the developers as it increases their productivity.
Once that is done, start working on continuous deployment by including a couple operations people on the teams. Have them describe what they have to do in the deployment process and which difficulties they face. Initiate an open debate. It is not about who to blame but about how things can be improved. Once an initial understanding is created, get the operations people working on deployment automation. Use a topology-based approach where specific deployments can be identified for middleware and database. Re-using the same topologies for these components leads to consistent installations and facilitates operations. This however implies that governance is put in place early on to define what installation approaches are taken. In case a developer requires a different installation they should go through the governance process to gain approval. The benefit here is consistency and ease in operations.
Many tools exist and new ones are appearing on a fast pace. So, realize you will probably want to change the tools you choose today sometimes down the line. So, don’t go overboard, chose a small number of tools upfront. Focus on source code management, a continuous integration service, a build service, some testing tools and a deployer. For team communications you may want to use a “chatops” environment, a tool that facilitates social media type communication while including bots presenting information gathered during similar conversations.
Have your own R&D
Set-up a small team that supports the progress of agile/DevOps in the organization and continuously monitors the tools market to look at what tool could bring value to the actual teams. That team may become the guardian of the knowledge gained by the organization and initiate the lessons learned and experience sharing activities.
Focus on the human side
I cannot mention it often enough, focus on the human side. Make sure your teams understand what they can gain from using DevOps. Have them experimenting it. Make sure they are recognized for their pioneering, and let them have fun doing it. This will attract others and this is how you enlarge the traction for this new way to approach development and operations. But make sure the management team understands how important their attitude is for gaining traction. So at all levels in the process, make sure they are fully engaged and buy into having their engineers working in a collaborative manner across organizational boundaries. If you do not do that, management will kill your efforts by not supporting your approach.