Overview Making the Big Move From Waterfall to Scrum Wiredrive faced two major problems that…
Case Study
Value Stream Optimization: SAFe® Case Study with SK Hynix
Company Details
Industry: Semiconductors
Company Size: 22,000 Employees
Location: South Korea
Cprime Services:
Executive Summary
SK Hynix wanted to optimize their Value Streams by empowering people to self organize. They needed to improve product delivery processes while being mindful of people's opinions within the organization. With the help of Cprime consultants and trainers, they underwent a SAFe transformation that resulted in improved transparency and predictability, and a significant reduction in defects.
The Challenge
Optimizing SKHMS’s Value Stream
SKHMS leadership analyzed how to optimize the Value Stream (flow of information and material from concept to customer) by empowering people to self-organize around the work. This strategy moved the organization away from cost centers and functional groups, to one allocated budget per train to help deliver the Value Stream. For example, think of a new expansion NFL Football team. When putting together a new football team with the goal to win the Superbowl, players, coaches, and domain experts are carefully selected. The goal is to put together the right mix of people based on availability, budget, skillset, team affinity, etc. Based on this strategy, they act as a cohesive unit instead of separate entities that are forced together. In the case with SK Hynix Memory Solutions, the value stream was to deliver best of breed, enterprise class solid state drives with industry standard interfaces. As part of this value stream, SKHMS leadership also dedicated a team of experts to test the various aspects of the firmware; from emulations to hardware in the lab, to qualification.
SAFe Pilot
SKHMS leadership, with Cprime’s recommendation, chose SAFe as the Agile framework because it addressed the complexity issues often associated with firmware development. For example, planning required and delivered for feature development. Therefore, the Agile Pilot kicked off with 5 Scrum teams and roughly 50 people to support the Agile Release Train. The product selected for the pilot was based on risk level, preparation work in place such as architecture, and enough features to span multiple program increments. SKHMS leadership did start with Scrum teams being component based versus cross-functional. For example, component teams for:
- Encrypted Storage
- Host
- FTL (Flash Transition Layer)
- NAND Device Driver
- Platform
Cross-functional teams were discussed, but careful consideration and analysis indicated more in-efficiencies and coordination than being productive. However, the goal is to learn from the current Scrum teams to what is the most optimal for product delivery
For the pilot, the Scrum teams were distributed across San Jose, CA, and Longmont, CO, but most of the Scrum team were collocated in one geographical location.
SKHMS leadership designed the Program Increments to be 3 months long (once a quarter) and followed a two week iteration cycle. Before starting the first PI Planning, there was a list of preparation work that needed to get done. This work was folded into Iteration 0. From cPrime’s experience, Iteration 0 needed roughly 1 week for a 3 month initiative. Since this was a 1 year pilot, SKHMS leadership agreed to one month to get prepared for launching the first Agile Release Train (ART).
SKHMS leadership also decoupled the Hardware group from the Firmware Agile Release Train because their work was not conducive to two week iterations with the Scrum Teams. Instead the Hardware group worked in a Kanban like fashion with SLAs on their work based on the Backlog prioritization. For example, knowing what features were coming down the pipe, they were able to prioritize their own work and in some cases, put out proto-hardware for testing purposes during the Program Increment. This coordination was possible because representatives from the Hardware group attended critical program level meetings as stakeholders and because they were part of the value stream for delivering the product.
The Solution
Program Backlog Prioritization
The Product Management in conjunction with the Firmware Architect came up with the initial list of Program Epics and Features for the Program Backlog. These Epic/Features were prioritized using Lead Time and prioritization. To be more specific we looked at the Cost of Delay and job duration associated with each work item in the backlog. In particular, looked at the attributes on the next page for Cost of Delay and assigned points accordingly using the modified Fibonacci scale.
Since features and architecture design required in-depth analysis, it was very difficult to create user and technical stories. At the same time, the design analysis required lead time given the complexity and resource gap. With this challenge, the Scrum teams decided to create Spikes to represent architecture and high level design work in the team’s backlogs. Based on upcoming feature prioritization and the intentional architecture strategy, the Product Owners were able to collaborate with their dev teams to create Spikes. Spikes were prioritized based on when the features had to be implemented. For example, if implementation of feature X was in Sprint 5, then the Scrum teams planned for the Spikes before Sprint 5. To further improve quality and limit costly redesigns, these spikes had a review component to it where key stakeholders of the dev team and external reviewers had to provide the necessary feedback.
The feedback from the reviews were discussed during backlog grooming, which was scheduled on a bi-weekly cadence as part of the Sprint design. In some cases, the architecture runway had to be implemented before feature development. In this scenario, technical stories were implemented to create the runway before the user stories for feature development started.
Program Increment (PI) Planning
Executive management was committed to the execution, and enabled everyone to fly to San Jose, California for the 2 day PI planning. This helped ensure that each team achieved an approved draft plan for the next 3 months’ worth of work with measurable, aligned objectives.
Continous Intergration
Perforce is a source code management and content collaboration software. For CI Builds, Bamboo with Perforce was chosen to meet the many operational challenges inherent in component-based development, provide enterprise-class version management for distributed teams of chip designers, engineers, developers, and testers using a wide range of design and development tools.
The Results
A Change Felt Throughout the Entire Organization
By taking a pragmatic approach to initiating an organizational change to help improve the product delivery processes, being mindful of people’s roles and opinions, SKHMS leadership was able to kick off an Agile Transformation that people felt good about.
If you’d like to see similar results for your organization, explore our flexible range of scaled Agile solutions.
About Cprime
Cprime is an industry-leading, full-service global consulting firm with a focus on providing integrated and innovative solutions around digital transformation, product, cloud, and technology. With over 20 years’ experience, we provide strategic and technical expertise to businesses across more than 50 industries. Our team of advisors and technical experts have the know-how to meet organizations where they are to develop actionable solutions and solve business challenges. We also collaborate with our expansive network of partners to design, deploy, and harmonize technology stacks across organizations. Our mission is to empower visionary business leaders and teams to reimagine the future of work to achieve better outcomes.
Want to share with a colleague? Download the PDF