Providing Visibility over Multiple Work Management Systems

Adapted from the DevOps Enterprise Forum Guidance Paper Overcoming Inefficiencies in Multiple Work Management Systems by Scott Prugh, Dominica DeGrandis, Rosaline Radcliffe, Pat Birkeland, and Keanen Wold.

Large enterprises are traditionally organized by function and managed to optimize vertically for specific outcomes. In IT, this often means organizations specialize in functions such as design, development, QA, and operations. Many decisions are made in the context of those functional silos as opposed to the end-to-end flow of delivery across those teams.

This mode of decision-making affects work management practices as well as tool selection for each group. In traditional operating models of siloed teams, this is certainly an issue when creating an environment of task-driven queues. Common countermeasures usually involve the introduction of other groups (release management, change management, project management) to help manage the “flow” of work, but these groups yield marginal returns, if any. (See figures below.)

As enterprises adopt Agile and DevOps, this mismatch between SDLC and ITIL practices, as well as tool silos, impedes both flow efficiency and work understanding within individual team and across teams. Additionally, business stakeholders are continuously frustrated because work disappears into the IT “black box,” and IT leaders are unable to provide timely delivery, let alone estimates and visibility into the work that it takes to both build and run the service. This dysfunction erodes trust between the stake-holders and the teams that are delivering and running critical services for the business.

THE PROBLEM

Multiple work management systems that originate in functionally oriented silos or independent teams create long-term inefficiencies at the enterprise scale. Communication between business people and IT people has long been an issue. It can seem as if the two groups speak different languages. Lack of visibility into IT work leaves business people confused and guessing as to what IT is doing. They think to themselves, “IT is a black box. We have no idea what goes on there.” Furthermore, IT people struggle to articulate operational risks and problems to business people—particularly, the question of why IT appears to rarely meet the needs of the business. If meeting expectations is a measure of success, IT frequently comes up empty handed.

No doubt, multiple causes contribute to this lack of understanding. One cause that stands out is the use of different work management systems. Some examples of different work management systems are as follows:

• A product management tool to manage roadmaps and requirements.
• An SDLC tool to manage features/user stories/defects.
• A test tool to manage test cases and regression testing.
• An ITSM tool to manage and approve service requests and change.
• A help desk tool to manage incidents, problems, and knowledge.

When each functional team uses their own set of tools, long-term inefficiencies can occur. Many software delivery organizations waste time on manual data entry, handovers, status meetings, spreadsheets, and chasing down missing information. This leads to high coordination costs, often because of dependencies.

SOLUTION-GUIDING PRINCIPLES

A necessary condition for dialogue among IT and business stakeholders is a visualization of the work. Visualizing work helps others see risks and problems. Visual landscapes provide a level of tangibility that might otherwise be considered too abstract to stakeholders. Mapping value streams and defining feedback loops within the value streams helps to optimize flow. Because a focus on flow improves the delivery of business value, organizational objectives can begin to be met.

Given the importance of work visibility, we suggest using the following guiding principles to form an improvement cycle for both the work management system and the nature of work³ being done:

1. Make work visible.
2. Use visibility to improve system behavior.
3. Adjust work management to make work visible.

COUNTER MEASURES

There are multiple ways to address the problems caused by lack of visibility of work across the entire value stream for a product. This section will describe a number of the approaches that have been used by different companies. Each has its own advantages and disadvantages. The goal of these strategies is to provide examples of ways to make all the work visible across all teams, including the “black box” of operations work.

This section is primarily focused on the tooling used in the work, as it is the tools that interfere with seeing end-to-end work and overall problems. Once all the work is visible, then improvements to the flow and system mechanics can begin.

The first step is to identify the different tools used to capture the work. This will include development tools such as Jira, TFS, RTC, Word documents, and emails; help desk tools such as Remedy and Servicenow; incident tools such as HP ALM, Jira, and Remedy; and testing tools such as HP ALM, RQM, Jira, and email. With all of the solutions, an additional requirement is to move out of email and non-trackable sources. One other important factor with any of the choices to consider is that other tools and other processes will be discovered, and those will need to be included and addressed as part of the update.

The first of the choices described here is a syncing methodology. There are tools, such as Tasktop, that allow you to sync multiple work item processing tools. With this choice work fields are mapped and then synced across the different tools. This allows teams to see the entire work; however, this increases the complexity and cost in the system by adding yet another tool to be synced with instead of removing tools. This option has been used most effectively as a starting point to make work visible. This should not be seen as an end point in the migration but as an early step in an overall plan.

The second of the choices is to use a consolidation, replication, and strangle approach. For this approach, you select the primary tool that will be used to show work across all teams. Most organizations select the development workflow tool for this consolidation point. This is based on the fact that Operations needs to move to a more development-based methodology for their efforts that includes capabilities such as infrastructure and code. Those doing operations work will need to track their software updates as changes, manage their scripts in the SCM, and, as this is already set up and integrated, move all work into the development pipeline to make this process simpler.

In the consolidate and strangle countermeasure, help desk tools such as Remedy or Servicenow generally remain as help desk tools, but incidents created are synced into the development backlog. This approach still leaves multiple tools in place (but generally fewer) and it provides a realistic approach that can be implemented over time to gain value. With this approach, once the work is visible the improvements start to flow and system mechanics can be implemented primarily in the single manager of work item managers.

The last of the choices described here is referred to as the rip-and-replace strategy. This is the most risky of the options. With this option, you have to have the executive support and funding to complete the activities, and you have to be prepared to change the processes and the tools at the same time. The approach is to select the desired end-state tool for work items and then move to that tool for all teams. Organizations that have selected this approach generally don’t have modern tools in use in the development area from which they’re selecting. Finding and migrating all the existing data into the new environment is important to seed the system with the current work. With a new tool for everyone, there is a single place for visibility, but it requires training and a conscious effort to support the change in processes.

With all of these approaches, you also need to work with the teams to capture all the hidden work that is currently not tracked in any tool or that appears only in email or other less integrated sources. This is a change, but by having teams see all their work, it becomes easier to do the proper prioritization and allows the organization to see what people are spending their time on.

In this proposal, you see that we are recommending you select a single tool, which conflicts with a common general principle that teams should be able to select their own tools. Flexibility for teams is important, but there are a few key areas where standardization brings more value than any gain by teams using different tools. Those key areas include the work item management system, so all work can be visible, and the source code manager, so that the work created is visible to all with the task of tracking it.

BENEFITS

Our brains are wired to process information visually. Visual communication is a must-have skill for organizations, because it’s often the only way to make sense of the work being done. By taking the approach of tool consolidation, data replication between systems, and toolchain strangling, we can achieve better visibility into the work being done, improve flow and system mechanics, and gain better customer visualization of capacity, velocity, and IT priorities.

Visibility into the work being done within the “black box” provides product owners with an appreciation for all of the patching, compliance, and other activities that IT does to keep the lights on. It also allows teams across the value stream to see how they are involved in the work and how their work affects other teams. The result of this visibility can help get teams out of the mindset of “this is how I’ve done it for years.”

Improving flow within a pipeline allows us to eliminate the manual processes between tools, avoids overlapping functions between tools, and reduces complexity for team members, resulting in faster delivery. Improving system behavior by connecting, reducing, or passing data between systems allows us to reduce or eliminate handoffs, wait times on requests, and multiple sources of records.

• Visualizing work allows customers to see IT capacity and velocity.
• Visualizing work creates the ability to build a shared awareness between stakeholders and teams executing work.
• Awareness of the work unlocks the ability for teams and stakeholders to begin to make both system and process improvements.

Conclusion

By following this guidance, enterprises can break down inefficiencies that exist in typical vertical teams and eliminate tooling exhaustion that often creates disconnects in visibility to tasks that are being carried out. The “black box” of IT is now visible by product owners, and those product owners can prioritize the efficiency work related to the process improvement, resulting in better awareness and visibility, happier and more fulfilled staff, and more consistent delivery.

Download the full DevOps Enterprise Forum Paper Overcoming Inefficiencies in Multiple Work Management Systems.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•