The Final Frontier for requirements practices

Posted by

In 1995 the Standish Chaos report cited the lack of good requirements practices as the principle reason why requirements fail. Since 1995 our industry has strived to improve the practice of requirements with approaches ranging from the Rational Unified Process to Scrum techniques such as storyboarding and JAD sessions. But there is still one frontier left to cross. That frontier is the ability for practitioners to access requirements in the context of their different tools / disciplines. For example, a developer seeing requirements in their IDE or a tester getting access to the requirements in their test tools. Improving the discipline of requirements only goes so far without the ability to make these requirements available to everyone working on the project.

Availability is not just about communication and comments, but also includes context to the requirements and updates the process associated with the requirement. With Tasktop Sync’s 2.4 release, we have extended our integration ecosystem to include requirement tools, allowing software developers, testers and project managers within their tools to access the same requirements that the business analyst or product owner is working on in their tool of choice. To put this into context let me tell you a story about a project that Tasktop worked on with a vendor where requirements were held in two disconnected systems and the pain it caused us. Of course, I have changed the names to protect the innocent (or guilty for that matter).

Time for a bit of dog fooding…

The project was a simple integration project between Tasktop and Vendor X. The Vendor was developing some additional capabilities to their tool and we were providing integration between their tool and the wide ecosystem of tools we support. In other words, a project we have done many times before, and have a lot of experience with. Because of time constraints and not yet having Vendor X’s integration available as a Sync end point, we did not use our own technology to connect their requirements tool to our development tool. In the past we, have bootstrapped on almost all of our ISV partners’ solutions when delivering an integration the moment it was showing tasks. Instead, we agreed to the practice of sending a spreadsheet every week to describe the progress of work and discuss any dependencies. Everything looked like it was working fine.

Progress was being made and both their development and ours was running on schedule. That is what we thought until testing got involved. Both our companies have testing teams, with Tasktop’s testers using the same tool as our developers to log defects, while the vendor’s team uses a different tool. Suddenly chaos started creeping into our project. Things that we assumed were working and that we understood were being debated. Defects on the requirements started popping up and both teams started blaming each other.

The spreadsheet, which was used to discuss the work suddenly, became a thing of terror and argument. And emails started flying around to resolve issues and problems. Often it was hard to tell what the true state of the project was without searching through emails, the spreadsheet and your own defect and requirements system. The pain level on the project reached epic proportions and we almost missed the release date, a hard thing to swallow for a team that prides itself at always delivering on time. We did deliver, but it required heroic management by both teams and relied on two people keeping everything in their heads. Ironic that a company that helps its customers to integrate their ALM systems of record did not follow their own advice.

Version two of the project did not make the same mistake with all three systems being sync’d, allowing our tools tracker and their JIRA and HP QC systems to be integrated. Email is only used now to remind people to look at these systems and for a regular ‘thank-you’. We learnt the following key points:

  1. Ensure that you have one view of the truth even if it is in two or three systems. The overhead of managing a spreadsheet in addition to each organization owning a system of record was too much for both our teams. By getting both teams to work on the same stories, even if they are in two different software tools, it helped us ensure that everything was on track and many debates about what version of the truth can be negated.
  2. The “e” in email stands for “evil”. Replace the heavy use of email between the different teams with a real system of record. That means that the number of emails can be used as a measure of system success. The larger the required number of emails the less the system is working. Emails seem like a simple solution to collaboration and communication, but too often emails are answered out of order, different people are emailed and there is no way to get a true picture of the truth.
  3. Spend time up front even if you are very smart to define the flow. We have been building integrations for years, and so thought that we did not need to spend time creating a working system with the vendor up front. But actually deciding on the process flow, and resolving process issues such as what we mean by BP1 or Priority A allows for a much more simple life. I am not saying that disagreements will be removed, it is a software project after all, but at least you will be arguing about the right things.
  4. Get real time information. The weekly spreadsheet and email became slow, with teams looking for other processes to get the right information, and because of time zone differences those processes often meant yet more email. By connecting the systems in real time our two companies created a continuous communication model. Also because the comments and discussions were being held on the original stories we had one place to look for history.

The cynical amongst you are saying “well that is a great story to sell your product” and yes you would be right, but there is nothing better for a product company than to experience the same pain as their customers. But immaterial of if you use Sync or just adopt one tool throughout your organization the value of concentrating on flow up front, and putting the process front and center is immense. Adding requirements to the Tasktop Sync story allows you to extend the flow into the requirements processes and helps to ensure that requirements are not to blame for project failure.