MS Direct
Release Management
Software quality
Build the service
Field Services
Costumer services
Roll-out Management
Release Intake
Release content
Release planning & roadmap
Release scope changes
issue description:There is limited visibility on the roadmap prohibiting the internal and external client (e.g. customer delivery managers, field services, operations etc.) to anticipate and prepare for the upcoming activities. In the current situation we encounter difficulty coordinating 1) the different project in a release and 2) the different releases
Issue description: In the current situation a requirement management process is available but limitedly adopted, the critical success factor of this process is encompass the interest of both the internal and external stakeholders
Issue description: The scope of a release is continuously changing
Sub Issue: The high level requirements provided consistently require clarification: for the majority of the high level requirements, it is necessary to go back to the requestor. Only when the high level requirements are clarified, the detailed requirements can be drafted
Rootcause: Unclear service request i.e. functional requirements
Sub issue: The planning, budget and content of a project are continuously redefined due to missing requirements: it often occurs (internal) requirements are not incorporated, for example the requirements for the platform teams, suppliers etc.
Rootcause: Missing functional requirements leading to missing non-functional requirements
Sub issue: The high level requirements do not specify exactly what to build: the team interprets the purpose of the requirements and builds accordingly: increased risk of delivering something different than required
Rootcause: Unclear functional- and non-functional requirements
Sub issue: The high level requirements do not specify exactly what to build: the team interprets the purpose of the requirements and builds accordingly: increased risk of delivering something different than required
Root cause: Unclear functional- and non-functional requirements
Sub Issue : The detailed requirements do not specify exactly what to test.
The detailed requirements are the basis for user stories, test cases, test scripts etc. The requirements are often high level and open to interpretation
The user stories are written in a technical language: not from a functionality perspective therefore it is unclear what the objective of the tests should be
Root cause: Unclear functional- and non-functional requirements
Issue description: The internal- and external clients (e.g. sales, customer delivery managers, field services etc.) of a release created by development are limitedly involved in the release management process, which; 1) prohibits them from providing relevant input and; 2) prohibits them from preparation of the upcoming activities
Sub Issue: The technical release notes are currently 1) limitedly translated to business language, 2) if so, not written from the merchants’ perspective and 3) limitedly communicated to the merchants (or customer services). The customers, and customer services are therefore limitedly prepared for a release – often they are prepared last minute
Root Cause: Quality of [business oriented] release note
Sub Issue: A service request of one customer is often implemented for all customers without consultation; there is no market research in to poll the needs or wants of the customer, the deployment of certain features is therefore mainly based on assumptions. Customers have no view on added or removed features.
Sub Issue: The roadmap has limited value to the company. the roadmap is created, updated every month and presented in a webinar to the business line and sales every 3-4 month.
The roadmap is heavily dependent on the release planning and changes continuously
Root cause: Scope changes
Sub Issue: The roadmaps are not harmonized between segments: there are roadmaps for software, hardware, terminals etc. without harmonizing the roadmaps we risk missing dependencies, synergies etc.
Root cause: Absence of responsible party for the consolidation of roadmaps
Sub Issue: Multiple internal clients are not aware of the existence of a roadmap: which prohibits them from preparing for the upcoming demand for their teams and required communication to the merchants
Root cause: Ineffective communication
Sub Issue: Inaccurate perception that the roadmap is not existing: the roadmap is publicly accessible to all and shared during webinars
Root cause: Limited involvement
Sub Issue: There are many (old) software versions in the field causing additional workload: new software releases require a high investment in terms of resources since dependencies and requirements for software migration
Root cause: Technical debt
Sub Issue: The prioritization and scope creep limits the efficiency of the development team: the team creates a breakdown of the work based on their availability and velocity. In the majority of sprints the backlog in changed and requests are added leading to a continuous (too) high work pressure
Root cause:
Suboptimal Agile WoW
Capacity in sprint 100% allocated
Sprint backlog changes during sprint
Sub Issue: Vicious circle of priority setting results in continuous delay: priority is generally given to the project with the (perceived) highest pressure (from the client) to deliver; other project get pushed back. As a consequence, the pressure to deliver increases for those customers of those ‘pushed back’ projects. As a result, the priorities of projects changes continuously
Root cause: Re-active release and deployment strategy
Test preparation
Test coverage
Test execution
Collaboration between Dev & Test
Issue description: There are three issues identified related to test coverage: 1) the test coverage is too low; 2) the test coverage is too often ensured by means of manual activities; 3) the test coverage in the automated test should increase
Issue description The time allocated to testing is too limited, reducing the quality of testing and therewith reducing the quality of software released in production. In addition, the bugs found upstream cannot be reproduced in the test environment.
Issue description : The collaboration between development teams and test teams is sub-optimal leading to inefficient handovers
Issue description: In the current situation the preparation of testing is of a low maturity level i.e. the test plans, test scrips and test cases require an improvement in quality
Sub Issue: The detailed requirements do not specify exactly what to test: The detailed requirements are the basis for user stories, test cases, test scripts etc. The requirements are often high level and open to interpretation
The user stories are written in a technical language: not from a functionality perspective therefore it is unclear what the objective of the tests should be
Rootcause: Unclear functional- and non-functional requirements
Sub Issue: Test coverage = one size fits all (Tier 1; KIA accounts):
The complexity of the software landscape (i.e. versions, hardware etc.) is limitedly taken into account
Sub Issue: Limited engagement in-. and feedback of the test strategy: a master test plan and test strategy is written for all projects (Audit purposes), it is distributed and obligated to sign
Rootcause: Sub-optimal testing strategy: mismatch with complexity software landscape
Rootcause: Not defined yet
Sub Issue: Prohibition of execution tests on encrypted packages: encrypting the software package 1) alters the content slightly 2) may create bugs
Rootcause: Segregation of duty
Sub Issue: TCC test team is prohibited from progressing on their task due to their dependency on development teams: 1) TCC idle time waiting for development to deliver an increment; 2) TCC has idle time and additional work waiting for development to clarify what should be tested for this increment and; 3) TCC has idle time waiting for development to fix the bugs found
Rootcause: Not defined yet
Sub issue: Progress of the entire project is blocked because the start date for the TCC test activities is postponed: the slot for test activities is pre-set and agreed, the development team is supposed to deliver the entire release package to be tested. The test activities are often postponed because 1) other projects are prioritized or 2) the development team isn’t able to deliver the entire package.
Rootcause; Implementation of Agile teams without cross functional teams
Sub Issue: Limited information sharing: the Agile WoW focusses on close collaboration instead of extensive documentation, however the testers are not integrated in the scrum teams – knowledge transfer is suboptimal
Rootcause: Implementation of Agile teams without cross functional teams
Sub Issue: Less that 20% first time right (including TCC testing). The problem is not that development does not understand the requirements, the problem is that they can not make them happen due to a variety of technical reasons. The lack of understanding contributes very little to the lack of first time right (80-90% of times development does understand the requirements)
Root cause: technical constraints
Solution: Use of confluence for Sales
Solution: make roadmap more elaborated