Islands of Information – Typically Not a Paradise.

“Islands can range from beautiful tropic paradises to desolate rocks. While may way claim to wish they could run away to a deserted island, few would actually enjoy (or even survive) the experience.”

Islands of information in a software development and operations environment can be quite similar. Each information set seems to be quite good, but the isolation between them is a significant inhibitor. Unfortunately, many are so focused on their own island that they do not even realize the limitations until severe problems arise.

Consider that 40 years ago, even something as simple as “Source Control” often meant filing cabinets full of punched cards, paper tape, or other media. Most of the other areas of modern concern, were not even considerations.  By the early 1990’s tools specific to software development were appearing, but they were isolated, focusing on only one specific aspect and having limited (or non-existent) ability to share the information with other systems.

When Microsoft introduced TFS (originally named Visual Studio Team System) in 2005, things changed. Here was a major vendor providing a single tool that integrated most of the key aspects of software development. The islands were no longer isolated, the information had become a single community.

People, Process, Tools

Before proceeding, it is important to note the order of these three terms. It is people who do the work, and need to be kept at the front. As the Agile Manifesto states “Give them the environment and support they need, and trust them to get the job done.” The first part of this environment is a codification of information into a process that promotes effective delivery of working software by the People. Once there is a process, then tooling to facilitate the process becomes important.

This sequence has been demonstrated to be key in many ways; but, there is also a feedback cycle that is often overlooked. A given set of tools provides capabilities that impact the feasibility and effectiveness of a given process. The set of potential (effective) processes places bounds on the ways that people can work. As a result, consideration of all three aspects in a concurrent fashion provides many benefits.

Integrated or Aggregated Tools

There are many tools on the market that focus on specific aspects of ALM, and most of them have some type of ability to integrate with other systems. As a result, it is possible to choose different tools and build an integrated solution. The results (especially in terms of cost) of this approach vary greatly. What typically happens as usage of this homebrew system increases, limitations are encountered. Maintenance costs (in house labor) increase and often fall behind. Once this happens, the usability of the system deteriorates, and may even be abandoned.

Microsoft TFS takes the approach of providing a complete integrated solution – with the capabilities of extension, customization and integration of third party tooling. This means that one starts with a complete working system and only needs to invest in customization or integration when there is a documented justification in terms of ROI [Return on Investment]

Island Fever

With the above information in mind, let’s take a brief look at some common problems that occur when there are various island configurations.

• Separation of Work Planning/Execution (Backlog) from Work Product (Code) – Difficult to determine a view of the overall Task, the associated Value Proposition, and higher level Business aspects (i.e. Why was this code written?). In the other direction, is becomes quite difficult to determine exactly what code is likely to be impacted in the (Welcomed) event of a changed requirement.

• Separation of Test Definition/Executions from Backlog/Code – If value delivery (story/pbi) are not have associated acceptance tests, it is challenging to determine if it is done. tests are not linked back, how do we know the impacted areas of a failure? If tests are not associated with code (perhaps via the work tracking) then determining which code is responsible for the failure becomes more difficult.

• Separation of Build from Work or Test – Determining the capabilities (stories/PBI) included in a given build is valuable in many ways (e.g. creating release notes). Creating builds without a minimal set of tests [BVT – build validation tests] increases the risk that a given build will not be “working software”

• Separation of Deployment from Build – Most defects are found once the work has been deployed to an environment/stage. As a result, it is key to know what specific build has been deployed to that environment. Unfortunately, this is often difficult to do - especially if there are manual changes (not under source control, not tracked as work).

• Separation of Defect Management from Backlog/Code/Test – Defects are inevitable. Ideally, they are found prior to production use, but that is never 100% achieved. Without correlation to the work (story/pbi/task) there is difficulty in differentiating between “incorrect requirements”, “unclear requirements” and “implementation error”. Without correlation to the code finding the “root cause” and then other use-cases/scenarios that could be impacted rarely occurs. Without correlation to testing, mitigating future occurrences by the creation or alteration of a test can fall through the cracks.

These are just a glimpse of the impediments that may arise if one does not have effective integration of information. Even if one is not currently using all of the aspects, it is likely that they will be adopted to varied degrees over time and failing to have the base data as well as infrastructure can greatly increase the cost and reduce the (at least short term) quality of adoption.

Conclusion

For over a decade TFS has been providing an integrated solution. Each edition [2005, 2008, 2010, 2012, 2013, 2015, 2017 as well as VSTS] has improved the capabilities over the previous. With the ability to work in Windows, Linux, Android, IoS environment, and the inclusion of not only the development team, but all corporate stakeholders, it virtually eliminates the islands of information and the associated risks.