This site uses cookies and by using the site you are consenting to this. We utilize cookies to optimize our brand’s web presence and website experience. To learn more about cookies, click here to read our privacy statement.

The Team with the Single Point of Truth

Bill and Tom managed two Agile-style development teams that operated in much the same way. Each used Visual Studio as code repository, but did nothing else with it as a SDLC tool. User stories were documented in Word, and stored in SharePoint after review. The test cases were in Excel on team member computers. Bugs from the testers were maintained in a separate issue tracker. UAT test scripts and bugs were in spreadsheets, managed in separate processes. Conversations about design changes, code implementation and bugs were in emails.

Making sure team members used the most up-to-date info was a pain point with both teams. On each iteration, Bill and Tom struggled with knowing what was developed, what was tested and what was left to do. Both teams worked many hours trying to accomplish the goal, often reworking code. At all times, it was difficult for the project managers to know whether or not the team was on schedule or what was causing any potential slip.

Bill continued using this same process, frustrating as it was, because “that’s the way we’ve always done it.” Tom knew other teams at other companies his size used a more efficient approach. Tom started down that path with a “small steps” approach to changing how his organization worked.

Since he had Visual Studio, he expanded its use. First he had the user stories captured in the Visual Studio. On the next iteration, new test cases were created directly in the tool and linked to the user stories. As time went on, the old test cases were easily imported from Excel, and separate regression test runs could be managed in addition to the tests for the most recent iteration.

As testing progressed, bugs were also input into the tool. Links were automatically generated between bugs and the test cases, for full traceability between high-level requirements and the final implementation of defect fixes. On subsequent releases of each iteration, UAT test execution results and bugs were also entered into the tool. The developers now had only one place to view and update bugs, and current test results compared to previous outcomes.

Within just a few iterations, Tom’s team was reaping the benefits of taking small steps towards having a single point of truth. His team members were relieved to not worry about having the latest and greatest. Tom was happy with the traceability and ability to make sure that key processes on his team were being followed. He was able to pull real-time reports about the status of the project. Any changes to user stories, tasks, tests and bugs were automatically tracked and visible in history logs, so an audit trail was maintained. Meanwhile, Bill’s team continued to struggle with having important information in multiple places.

As experienced IT professionals, we’ve all worked on teams struggling with communication, task management and organization. Getting stakeholders and team members to all have the same point of reference does not need to be hard. There are simple ways for managers to have readily-available statuses of development tasks and testing at any time, which streamlines the SDLC and provides a competitive advantage. It can be done in a few iterations, taking a few small steps toward a single point of truth.