The Need for a change

For an automobile giant, A department was undergoing a bigger change, due to more vehicle sourcing and the need for a supplier on-boarding as with the modern ways of quick turn-around to compete in the market, and the legacy system with the traditional ways of software development, lead to the difficulty in making even a minor change to the software or gets into more volume of defect leakages. The Nature of the product has been built to make a seamless supplier on-boarding with integral approaches towards the approvals across the globe and to build the transparency of the on-boarding process and gain a better focus and quality. But the resistivity to make changes ended up with making around 80-100 defect leakages per release (approx. 30-45days). Which created many chaos and multiple escalations to the Quality team though the end to end coverage was working better

With the above escalations the Quality Lead of the team had brought up the Root Cause Analysis (RCA) for all the leaked defects for the past 6 releases and the reports were prepared and the container had the following items in the list

Lack of requirements stability: as mentioned above, the application required a major change and the application has resistivity, and the backlog flow to the team has become huge in a short time

Lack of Version Control: as the configuration management and the version controls were not so great organized, there were lot of overriding check-in conflicts and that caused some serious issues in the deployment

Adhoc Requests: As the need was increasing in a short span of time, increased requirements flow, and the ways of handling by the product management to push, made the development team to make instable product

Regression Methods, were used as End to End regression, still the issues were more concentrated on the Medium priority defects which turned up the product to be ineffective

Lack of Clarity on the requirements is another problem, as the large scale of changes led to more inflow of requirements, the Business Analysts are neither able to concentrate more on the development team, as well as write a detailed level of requirements nor the more communication with the teams.

Communication and collaboration was a serious issue, and it started with the push mechanism and the vision and goals were changing over the time.

Based on the first level of collaboration between the development leads and the QA leads and the Delivery manager, the above points were the high priority items to be addressed, and the methodology to handle is not known to the present team members did not identify rapid requests.

Scrum Introduction to the Team:

When the issues were stated to the Software methodologies group within the manufacturing giant, the Scrum and other Agile methods were discussed, and the team felt that Scrum would be the ideal framework, can be followed for the team. Also the Management team can follow the Kanban approach to prioritize the inflow of the requirements.

How did Scrum Journey Began:?

As the team were located at the different sides of the globe, 2 Scrum Methodology coaches were designated in both the locations, and the intense training of Kanban and the high level of Scrum has been given to the Product Owners, and the Delivery managers.

The rest of the team Development, Testing and Release Management etc. all has been trained with the scrum framework and the way to execute on top of it. Also the coach insisted on the Potential Shippable increment and the Minimum Marketable feature and its attainment with the vertically sliced features and user stories.

The communication channel has been established over the stakeholders and the development team in the Backlog grooming sessions, that built up the negotiation on the MMF and PSI over the period.

To start with the minimizing pattern of the defects, the team proposed Andon approach, to stop all the new development activities, and continue with the approach of validating the current issues in the system and fixing them on-time to maximize the utilization of the system.

Then started with the backlog refinement, and the ranking of features has been made and the Kanban board has been updated with the business values, and the expectation of the users.

That enhanced the visibility of the whole team members and the ability to negotiate with the alterable chain as per the design, and the clubbing of few requirements that enables the early delivery of features

And the ROI has been increased as per the development team efforts are properly streamlined towards the value delivery.

Timely releases with the Minimum Marketable features, and the PO acceptability and the end user preference made the team more energetic with the high positive feedback.

Benefits Seen over the Traditional Software development approach:

The traditional approach had the hierarchy that created chaos on the communication and the transparency of the need for the changes. Also the requirements were only pushed and the team didn’t have a change to negotiate.

The differences that the team felt are, everyone has been empowered as the clarity has been developed across team members on the importance of their development. The vision of the product development has been clear, and the appropriate decisions has been taken considering the design of the software as well as the business needs, that triggered additional happiness to the team and the lean management of backlogs, the team members have triggered additional improvements actions.

Team is happy with the modern approach towards the software development and the course of delivery with the quality has been improved a lot.