In this post, you will learn how we performed dependency management for a team using a dependency management tool. This information can serve as orientation for your own projects.
As part of an IT program, we led a team responsible for dependency management. Dependency management includes:
- The identification of the scope and time dependencies and maintenance of the corresponding documentation
- Recognition of supply bottlenecks and their immediate elimination
- Measurement of quality assurance coverage and elimination of test gaps
Based on our experience, we would like to describe in this paper the approach and the key success factors on a very detailed level as a basis for similar challenges in complex IT projects.
Dependency management is a task that should be an integral part of the product development process. An after-action review associated with high effort and short response time. Dependency management requires a coherent methodology during the development process. It is relieved when the entire product development process follows these premises:
- The planned change or transformation must first be worked out at the business process level, e.g. following the eTOM framework: User Flows in our project context
- The vehicles for elaborating and documenting the IT change should be derived from the targeted user stories: User Stories
- Delivery vehicles should contain a well-defined set of user stories and refer to a delivery version: Change requests
- The integration test cases (in addition to unit and component tests) should relate to the user stories (requirement level) and to the target user flows (process level)
- The incidents and defects should relate to the test cases
Based on the given traceability, a health check of user flows over multiple delivery-release cycles can be determined and reported. The report can be used for Go/No Go decisions for commercial launch of the end-user product. The “User Flow Cockpit” represents the dependencies between all important factors: Process, Scope, Delivery, Test and Defects.
In an enterprise-wide view, each delivery release must begin with a planned change to user workflows, triggered by multiple projects and harmonized by process owners on the business side. After launch, the repository of user flows is baselined and reflects the “as-is” state. In SAFe terminology, key business processes can be mapped to value streams.
To complete the delivery and dependency view, a view of central services in the form of a repository (e.g., payment services) is also required (the solution dimension in the SAFe framework). A business process transformation can lead to a change in the set of services. Versioning of the interfaces used by the services can provide high flexibility in the delivery-release process up to continuous delivery.
ARIS: Business Process Modeling
CONFLUENCE: Descriptive elaboration and documentation of user stories
- Tracking and control of user stories
- Tracking and control of change requests
- Effort estimation based on requirements and solution documents
- IT Capacity Planning
- Gating workflow
- IT budget planning
- IT fault management
JIRA + X-Ray Plug-In:
- Staging integration tests
- Production integration test
- Business Acceptance Testing
The following data model shows the path of traceability between all factors:
Our added value: The dependency tool
The standard tools used are specialized tools in their field. An E2E view from the business process to the IT defect is not supported by the standard functions, so we decided to implement a central dependency tool that allows us to do this:
Reading out all relevant information from Jira, Confluence using the Rest API.
read all relevant information from ARIS via a file-based nightly export
Automatically create ARIS business process relationships (e.g., user stories mapped to user flows) in Jira:
- Derive the correct delivery information (release, resources …) and automatically update the scope artifacts in Jira.
- Automatic generation of requirements documents in Confluence and as a PDF file for a selected CR with reference to the associated business processes
- Generation of a complete business process cockpit view (health check along multiple releases)
- Generation of a complete delivery and budget cockpit view
The scaling and orchestration of processes, epics, user stories and solutions could be configured according to a simplified SAFe setup. This was not our mission in the customer project. Therefore, it is interesting to conceptually analyze the SAFe approach and elaborate the tool chain in this case. An ideal topic for a new blog post.