Organizations often fail to optimize the collective use of engineering tools and setup despite making huge investments. I have mostly experienced that problems exist due to lack of cohesiveness among tools, processes, and development methodology. Before making further investment in a new tool to solve your pain points, I strongly recommend launching an initiative to analyze how different pieces tie-up with each other. In this article, I have tried to share my experience of conducting such a holistic exercise that can culminate in a profitable result.
With my experience of working as a process consultant, I have found that one of the major challenges faced by the teams is to make the best use of engineering platform. In general, an engineering platform may be described as an integrated suite of tools that facilitate software development lifecycle. I have quite often seen that teams blame existing engineering platform for various troubles related to inadequate productivity, incorrect reporting, inability to link artifacts, lack of visibility, and so on. Sometimes, people expect tools to work for them like a magic wand, which can address their needs and wants. I have also seen people having naive expectations from the tools, e.g.,– 'we need a tool that can manage business requirements’, ‘we need a tool that can generate requirement traceability' , and so on. However, no tool is capable of addressing your needs, unless you clearly define what works best for you. For instance, pre-requisite for implementing a requirement management tool would be a flexible, adaptable, and responsive workflow that simplifies the way requirements are gathered. Similarly, requirement traceability cannot be established unless all software artifacts are linked together in a cohesive manner. Thus, best practices and 'light-weight' processes are the main driving forces behind successful implementation of any engineering platform. Lack of association between tools and processes can be counterproductive just as computer hardware cannot work without software or firmware. Before setting aside budget for engineering platform, one should make reasonable investment to analyze existing processes in order to identify gray areas that may not be apparent in routine work. Sometimes, such a process assessment is kept on the back burner due to dire need to acquire a new tool, lack of time, or budget.
If you think you are unable to achieve desired results with your existing engineering platform, there is never a wrong time for you to perform a holistic exercise to assess end-to-end processes and development methodology vis-à-vis your engineering platform much before considering new tools. Based on my learning from assessments of distributed teams, I have tried to exemplify problem areas that are out of sync:
- Inadequate Integration of Tools –you may not be easily able to track files modified to fix a defect in absence of the integration of defect tracking system with source repository. Similarly, tracing back unstable requirements will not be an easy task if defect tracking and requirement management tools are not integrated to enable the smooth flow of information.
- Inconsistent Tools and Practices –this situation is very likely to occur after merger or acquisition of different organizations. Problems crop up when distributed teams use multiple tools for the same task. For instance, code integration problems are very likely to occur if teams in different locations are using different source control tools. On the other hand, simultaneous defect fixes done by the developers from different locations may not be properly updated in source code repository due to inconsistent check-in practices.
- Tools Unfit for Development Methodologies (i.e., Agile) –Agile methodologies are characterized with enhanced emphasis on collaboration. Agile practices can perhaps start to subside due to inability of development tools to integrate with collaboration systems, e.g., Wiki. Development tools that do not support real-time collaboration are not the best fit for distributed Agile.
- Process Overhead due to Complex Workflows –process workflows primarily drive engineering tools. Simple workflows allow tracking things effectively and thereby reducing process overhead. For instance, too many statuses and transition states in a defect tracking system may interfere with routine work and generation of reports and metrics. Sometimes, I have also seen that unnecessary statuses (i.e., On Hold, etc.) become