In Total Quality Management, the 1-10-100 rule states that prevention is 10x cheaper than correction, and 100x cheaper than failure in the field. We usually apply this principle to our thinking around defects and as a driver for continuous delivery and feedback loops. However, in much of the Agile discourse these days, the traditional requirement gets left behind.
Development has been transformed, from the bottom up by open source and inexpensive tools like JIRA, and from the project management level down by the Agile movement. But in large-scale software delivery involving very complex products and supply chains, requirements are the tasks that connect strategy to shipping software. The trouble is that the tools that we use for requirements management are completely disconnected from the modern Agile delivery process.
Consider a requirement to add a web service API to an app. Sounds great when expressed in Microsoft Word with direction from the CIO. After being passed to development, SOAP technology is selected on the merit of being present in other parts of the product line. A few developers comment on the corresponding user story that SOAP is inefficient and could cause serious CPU overhead, but both the business analysts (BAs) and the Ops folks are well out of the loop as they never log into JIRA where the discussion is happening. The solution is deployed, passes basic scalability tests, then after going into production it becomes clear that the SOAP solution will not scale to support the projected user base without a massive new infrastructure investment. So three months after the requirement was defined, the business analyst gets to realize all of this, learns a new acronym (REST) and another round of implementation is scheduled for the upcoming sprints. That’s the 100x cost scenario that we see all too often. Had the BA seen some of the comments in JIRA, a lot of waste could have been prevented.
This problem was partly addressed a decade ago with the Rational Unified Process (RUP), which created a homogenous Application Lifecycle Management (ALM) stack from requirements right down to development. But that approach constrained developers to the point where the Agile and lightweight ALM tool rebellion transformed the landscape. We now know that an efficient application lifecycle is capable of leveraging best-of-breed tools, with stakeholders such as Developers, Business Analysts, Project Managers and Testers working in the individual tools that make them most productive. Until today, only a few brittle point-to-point integrations existed between requirements management tools and the rest of the ALM stack. With today’s release of Tasktop Sync with integrations for IBM Rational Requirements Composer (RRC), IBM RequisitePro (ReqPro), CA Product Vision, and improvements to our existing integrations for HP ALM and QC Requirements Module as well as Accept 360, requirements are now a first class citizen that can span the lifecycle.
While the new support for sync’ing requirements is the biggest part of the story of our ongoing quest to connect the world of software delivery, there are many more highlights to the Tasktop 2.4 release, including major new features for ALM integration administrators such as a web dashboard for monitoring and IBM ClearQuest support. To learn more see: