Over the last two decades, the swing of the pendulum from monolithic global tooling to highly specific tooling unique to each group and their needs has led to the birth of the tooling suite; the daisy chain of tools never intended to be linked together. One of the main challenges that has emerged is a plethora of disparate, often highly manual approaches to getting enough data to drive any kind of informed and cohesive decision making across value streams and portfolios.
The swing took us to today’s reality where large global organizations, traditionally manufacturing titans or insurance household names, are now software businesses at their core. According to Greg Gould, head of product for Rally at Broadcom, “These transformations were inevitable for companies to stay relevant in the landscapes of digital shifts and disruptions that upended entire industries. Companies have the increasing need to stay relevant and visible to end customers that have a wealth of options and information at their fingertips.” These transformations have also caused a shift in the industry from the days of expansive IT organizations that owned all of the tooling decisions across monolithic engineering groups, to a world of modular R&D organizations that are nimble and performant. These types of modern engineering organizations require the exact right set of tooling for each team’s particular needs.
Next the advent of Agile, and Agile specific tooling, contributed to huge gains to what we now know as modern product development practices. With a focus on team autonomy, small dollar value purchases were decentralized and could be made online with the development managers P card without requiring long procurement and approval processes. It was awesome. Teams could use whatever tools helped them be the most productive and new and upcoming startups offered slick solutions that could be purchased and implemented in no time.
However, there was a realization that teams of 7-9 people that were highly empowered and autonomous could only take a product and an organization so far. There was a need to scale Agile beyond the single team to effectively plan and execute at a large scale. Some tooling options took the challenge of scaling Agile in stride, gracefully bringing capabilities to the market to address the needs of not just the development team, but also the needs of Agile release trains, program and portfolio teams, product teams, QA teams, and DevOps teams. Some did not, but were already incumbents at the team level, and hard to replace without significant disruption to productivity in engineering.
Organizations were struggling to maintain dozens of implementations of various tools, typically highly customized to each group and discipline. While the teams were effective at the team level, it was complete spaghetti for anyone even one layer above the day to day of a team. Large organizations also faced increasing challenges in attracting and retaining engineering talent and attempted to solve the issue by forcing tooling onto developers, causing mutiny in the ranks. At the cost of hiring a new engineer, this was creating a situation organizations could not afford.
This conundrum continues to haunt large scale organizations and has been doing so for as long as Agile has been around. The concepts of interoperability in a tooling ecosystem were never new, but they were not applied up-front to this challenge. How could they have been? Disciplines have continued to evolve even after the arrival of the market standard tools that govern Agile development. Organizations are trying to run their companies and anticipate the shifts market without a holistic view of the data needed to make informed decisions. Companies struggle with poorly bolted on tools as a result of acquisitions and team preference for flashy options to suit every need. Gould has said of some of the largest Agile organizations in the market, “They manage financials and budgeting in one tool, Roadmapping and Agile program and portfolio level planning in another, and development and execution in multiple others. And while all of these tools are daisy chained together, the manual effort to pass data between them is cumbersome and a full-time job. That is what we sought to solve in our recent product the Rally Adapter for Jira”
However, there is light at the end of this tunnel, and we are beginning to see cohesion in at least some of the major players of these spaces. Notably, Broadcom’s suite of products including Rally, Clarity and the newly released premium add-on that brings visibility from the entire execution layer, even if it exists in Jira, has hit the market and found traction. These early and tangible solutions from a major player in the market demonstrate that with the right product and customer focus even a decade plus of silos in tooling can be tamed to provide a highly valuable set of data to drive a business’ decision making to achieve their overall goals and objectives. Gould noted that “Data normalization isn’t sexy, but the Adapter we provide between Rally and Jira is instrumental in the organizations that use it, driving visibility across silos in their value streams to make confident data driven business decisions.”
The post Taming heterogeneous tooling into cohesion appeared first on SD Times.
from SD Times https://ift.tt/3hwvsCM
Comments
Post a Comment