I remember the famous blog by Mike Gualtieri, an analyst at Forrester stating, “I don’t want DevOps, I want NoOps,” creating a passionate debate in the DevOps community about the importance and value of operations. After reading all the comments, it seemed that the solution was a sensible one: Organizations need balance – releasing software requires the skills of both operations and development. For some organizations, this means developers taking on more of the deployment burdens. For others, it’s operations creating automation that is used by developers. And in some companies, it’s Agile teams including operations specialists that focus on both deployment and operations. The bottom line is that DevOps calls for a balanced, thought-through discussion about the role of operations and development. It also calls for collaboration between these two groups.
But hang on a minute – aren’t we missing someone from this discussion? DevOps has focused on connecting development and operations – but mostly in terms of the technical, discipline-oriented work – such as defining techniques that allow builds, deployments, installs and configurations to work seamlessly. DevOps has even promoted the idea that the developer’s work management tools and the organization’s service desks should be integrated. But what DevOPs often misses is that it takes a village (or small city) to deliver software, and a key set of people called “managers” need to also be involved. We need to connect portfolio management to the practice of DevOps – we need to make DevOps, BusDevOps (Business-Dev-Ops). OK – I can hear the skeptic saying “why do management need to be involved?” Well, “management,” specifically portfolio management and the PMO, are responsible for making strategic investment decisions. They are also, in many organizations, responsible for the financial management of projects/ programs and portfolios. Thus, the process and work done by DevOps need to be managed, and more importantly, reported on by the PMO. This management might be as granular as deciding which trouble tickets to work on, or as macro as seeing the aggregated ticket cost grow and shrink over time and allocating resources accordingly. Depending on your organization, the governance and oversight provided by the PMO needs to be integrated into the process of DevOps allowing improved reporting and decision-making.
We’re bringing Business DevOps together
As part of the Sync 3.0 release we added ServiceNow and JIRA ServiceDesk connectors. These connectors allow tickets to be integrated into both ALM and PMO processes. For example, a service ticket in ServiceNow can generate work items in Clarity, which then are planned in Rally, allocated in TFS to be worked on, and tested in HP QC – all the time being the same “single source of the truth” even if living in many systems. Thus, consistent reporting, collaboration and workflow can be executed against this artifact in real time. With Tasktop Sync 3.0 we allow comments to stream seamlessly from different systems allowing developers, operations, project managers and testers to freely collaborate without leaving the comfort of their own tool. In addition to collaboration by integrating the data across discipline and application boundary, software delivery professionals can generate reports in the system that makes sense to them and of course, get cross discipline and artifact traceability. Integration between operations, development and portfolio management gives organizations the information infrastructure to be more efficient, collaborative and replace the need for manual processes and email and spreadsheets. In fact, one of our missions at Tasktop is to replace the need for email and spreadsheets on software delivery projects and this is just another example of how we can replace those tools. The creation of the ServiceNow connector was driven by customer demand. When looking at these customers there were two things that unified them:
- Increase the lifecycle feedback – Agility highlights the importance and value of feedback. For projects, getting feedback early allows problems to be uncovered earlier and corrective decisions to be made earlier. Though the adoption of Agile methods is widespread, most organizations still suffer from a disconnect between operations, development and the project office.
- The need for delivery speed – For many organizations software is crucial for their survival and success. Getting new features and products to market earlier has real impact on the bottom line. But as delivery cadence increased, many of the manual processes that glue together the different disciplines start to break. And while data exchange needs to happen in real time, spreadsheets and email actually start to fracture communication, rather than enable it.
Many organizations talk about Agility, but without automated feedback, Agility really only resides within the boundary of the development team. By connecting development, operations and project managers, organizations have the chance to effectively break down the barriers between those groups, moving to one integrated agile process without assuming that having one process means needing only one tool (which for many organizations is just impossible).
A call to action for Business DevOps
The idea that the way to increase Agility is to reduce the number of disciplines and replace everything with a super developer who can manage the team, work with the business, write great code, test it and then manage its deployment and support, is a pipe dream. Even the most capable developers cannot do everything and specialist practitioners, using the tools that make sense to them, will always be the reality. But that does not mean you have to give up on the dream, organizations can better integrate these groups and disciplines. By focusing on information federation rather than control all groups involved in development can get a better view of what is happening. Here is a three step program for business DevOps:
- Understand the information flow of the primary artifacts – for example, how does a ticket flow through the process from operations to the project office and then into development and test.
- Understand the transitions between the artifacts – for example when does a ticket become a new user story or defect and what information would make sense to share across those artifact boundaries.
- Replace spreadsheets and manual processes that connect the disciplines today. Connect up the end tools or adopt a software lifecycle integration business such as Tasktop Sync to make the transition smooth and happen in real time.
