A standardised work management tool?

The papers published by the DevOps Forum are a fabulous contribution to the DevOps body of knowledge. I always learn an immense amount from them. But with the latest paper I can't agree with it. It is Overcoming Inefficiencies in Multiple Work
Management Systems
. My issue is with the underlying premise that standardizing everybody on the same work management tool is essential for visualisation.

    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.

I could agree with this premise on one proviso: that they were talking about within the scope of one value stream.

IT4IT framework is the best model I know of the fundamental value streams in IT. it says there are four: Strategy to Portfolio, Require to Deploy, Request to Fulfill, and Detect to Correct. Within any one value stream there is great benefit in everybody being on the same tool to aid in work visualisation, but I believe there is very little benefit in trying to force people across all of these values streams to use the same visualisation tool.

If this paper was written within the scope of the Require-to-Deploy value stream - DevOps' usual scope - there would be no issue. But it clearly is talking about the whole of IT. I think this paper is making a dangerous assertion which will generate turf wars between the software development life cycle tools like Jira and the operational tools like Servicenow and Remedy.

The key word in all DevOps automation is tool chain. The essential requirement is that work can flow through every value stream and where necessary between value streams. Certainly each group of people should be free to adopt the tools best suited to their value stream and I can assure you that Jira is not the best suited tool for managing Request to Fulfill nor Detect to Correct. In addition there are underpinning functions such as networks, security, and operations, none of whom will be happy if you attempt to standardise them on software development life cycle tools.

I work very hard these days to stay away from technology so I would not describe myself as a tool expert but in my limited experience there isn't any work visualisation tool suitable for all areas of IT. Even if there were, the disruption and bad blood of forcing people off their current tool in the name of "standardisation" isn't worth it a d is highly unlikely to succeed anyway. You will generate resistence and outright subversion. Culturally this is an awful idea. Keep it within each value stream.

Even within a value stream, the idea of standardising tools to aid central reporting rather than empowering teams to aid flow of work sounds to me very unAgile. Governance should always come second, the servant of the work. Find a way to consolidate the views rather than imposing tools.

Or have I misunderstood the paper?


[from my comment below:

Work flows between all value streams. But trying to force different groups of people onto the same tool for some sort of data purity is counterproductive. Its better to automate exchange of critical flows.if we can do it between workflow tool and CD tool, we can do it between workflow tools.
It is rare for development to provide all support or operations in any organisation larger than single-product producer. The only problems that build teams are.concerned with are defects in code (application and infrastructure). That's a subset of problems.
If it's greenfield and you can roll one tool out for everything, great. That's not what I would do, I'd go for best fit tools chain, but whatever. But if it's a legacy organisation, then standardising everyone on one tool across all value streams is culturally destructive and political suicide.]

Syndicate content