Initiatives

DevOps Requires Integration

Operations teams and development teams are not just measured differently, they also follow very different processes and practices. Development takes advantage of Agile methods, or some combination of Agility and waterfall. Operations often conforms to ITIL and other very structured and prescriptive approaches to process. The tools that the two (or more) groups use, embody these disconnected processes. Lifecycle integration can provide a great first step to enabling better flow of information and collaboration between these two groups.

Integration enables DevOps by improving a number of key processes

• Collaboration on customer issues. Often, ticketing systems used by operations are not used by development. Issues raised by the customers are not communicated to development, other than in the form of emails or spreadsheets. Development and Operations have very different needs for work management systems, but there is some core information that should be shared. That sharing of key information in near real time enables better planning by Development, helps developers understand the problem, and ensures that status information is communicated back to the operations group … and ultimately the customer. Integrating the tools pushes collaboration deeply into the process and removes the need for email and other ad hoc collaboration schemes.
• Release delivery from Development to Operations. It goes without question that Development must provide to Operations a complete understanding of the software they’re putting into production. The DevOps movement rails against the notion that this information should only be provided at release time. But in many organizations, collecting and providing basic information, such as what features were developed, what defects were fixed and what known issues remain, is a very manual process. Integration between the tools the Development team uses and those the Operations team uses would turn this in to an ongoing, real-time process.
• A shared view on IT Service Delivery. Development teams are often dependent on the Operations team’s ability to provision development and test environments in a timely way. Unfortunately, because the two organizations use different work management software, they have no (automated) visibility into each other’s requirements or backlog of work. By connecting the work management system of Development with the Operations work management system, organizations can get better visibility into each other’s changing priorities and can ensure that any blocking tasks are managed.
• Development access to performance monitoring results. One of the most problematic divisions of labor between Development and Operations is related to application performance. The Operations team has the tools and techniques to monitor application performance in production. But the Development team needs timely access to their information in order to review and resolve any service level breeches. By integrating the tools the Operations team uses, to the tools the Development team uses, it’s possible to remove a number of manual processes, and to ensure that the developers have more timely access to the alerts being raised by the monitoring tools.

Scaling Agile requires integration

The more people that are involved in any endeavor, the more you have to rely on systems or tools, to enable those people to work together. But Agile has the additional impact of: reduced batch size; more frequent delivery: and an increased focus on team, rather than organizational, effectiveness. Unless everyone is working within the same system of record, and with the same process, automating the integration of the tools being used is crucial, for the following reasons:

1. Teams need information in near real time – Agile teams meet daily, changing priorities and adapting to improved knowledge. Getting information from other teams, and bringing that information back, must happen in the same cadence as the team works – with no delay. For example, if finding the status of a key dependency takes all week, it is very hard to manage it within a scrum. The team will just assume the work is not ready, and won’t integrate it into their work at the right time.   
2. Reducing the cost of corporate reporting – Compliance, audit or even financial reporting does not disappear because development teams have gone Agile. Often, the larger organizational processes are more waterfall, and have legacy process models that include reporting requirements that are burdensome to an Agile team. Because Agile is an incremental or additive process, the overhead of frequently updating status, or reporting progress on timesheets, is problematic.
3. Support corporate planning – For many organizations, high-level business planning processes occur on an annual cycle. For these organizations, it is important that time and effort can be planned, and progress reported, in a traditional way. They are neither Agile or incremental. However, by integrating these planning lifecycles with Agile development, and by having consistent translation of the key artifacts, the overhead of managing two plans, is reduced.
4. Compliance and governance processes – For many, reporting is not just important for the purposes of delivering the project, but also to ensure that the project is conforming to corporate standards. Supporting compliance often requires cross tool traceability and reporting.

With the resources below, you can learn how to design and implement Software Lifecycle Integration (SLI) patterns which are the fundamental basis for an enterprise-wide scalable integration strategy, and a necessary underpinning for SAFe®.

Pass the Baton SAFe(ly) - Part 1

Pass the Baton SAFe(ly) - Part 2 

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile Inc.