THE CHALLENGE
The organization I currently work with, had started adopting Agile processes from 2K16 in specified teams throughout its multiple geographical sites. However, these were acting individually and the organisation was not benefiting from their individual activities. Dependencies still caused havoc with planning and operations. Timelines were still getting missed due to defects arising during system integration between deliverable of the multiple teams. Plans could not be worked out as they were not in sync for all teams working on a product line.
In this scenario, the challenge for management was to try and implement a model involving multiple teams situated in 4 geographical locations involved in a new product line which resolved these issues.
ANALYSIS
As part of the transition team, problems were identified in following areas through brainstorming sessions.
Site based approach - Since teams were based on 4 different sites, they approached planning in a site based manner. E.g, if Team A was based in Europe it planned for deliveries and dependencies which only impacted Europe. This did not take into account requirements of the product as a whole.
Lack of systemic view - the teams working on the product lacked a systemic view and approached the development in silos. Hence, even though the teams individually might be following Agile processes, the technical community did not focus their attention towards the product as a whole.
Lack of transparency - Product management got status update on weekly basis from each individual scrum team. However, these updates were rarely throwing light upon the actual status of the product as each individual team was sharing their updates and demos tuned to their particular deliveries. Similarly, the development teams were not getting a proper view about the usefulness of particular user stories from business perspective as business leaders rarely met with development teams.
Discordant decision making - Product management lacked a lean-agile process of decision making for new requirements or ideas. Hence, these often resulted in management allocating new requirements incoherently to different teams. This caused the teams to sometimes lose focus and waste effort without adding value.
Cadence - Multiple teams were using different sprint durations which caused a break in cadence for the complete product cycle. This caused a negative impact on product timeline as work needed to be synced between multiple teams.
In order to solve the above problems, Scaled Agile processes were sought to be setup which would synergise all teams involved in a particular product line. The processes were discussed and setup in 2K17 and implemented in 2K18 product line.
THE BASICS
As part of the transition consisting of 3 Agile Leads, the basics involved in setting up the scaled agile processes were studied in detail. These turned out to be the following:
Which Framework to be used - Numerous frameworks allow an organisation to scale processes based on its requirements. LeSS, Nexus etc are all frameworks which are extremely useful. However, considering the specific needs of TPVision regarding suppliers and geographical locations, SAFe was chosen as the ideal framework to be chosen.
Which project to target - The targeted project was to deliver a product line which would be active in the market for 7 years. This would target the EU market and a variant would target the NAFTA market. The project would have development and validation teams spread out in 4 geographical locations, 1 in EU and 3 in Asia. The total number of engineers and architects working in the project would be approximately 125.
What timeline was to be followed - The final product was to be made available in the market by wk 1844.
IMPLEMENTATION ROADMAP
The primary objective was to identify the various aspects of roadmap which needed to be implemented. It was decided to start by implementing the ESSENTIAL SAFe and then scale to LARGE SOLUTION SAFe. This was because of 2 reasons:
Suppliers - For a meaningful SOLUTION TRAIN setup, suppliers needed to be an integral part of this implementation. However. suppliers could not be convinced to be part of the SOLUTION TRAIN. Convinced that bringing all suppliers on-board will take time, it was decided to reduce scale.
Complexity - As per the CYNEFIN framework shown below, it was judged that introducing SOLUTION SAFe initially would cause the operations to move to Chaotic. Hence, to handle the Complicated scenario, ESSENTIAL SAFe should be initiated which could be scaled up to SOLUTION SAFe
The Steps taken for this was for the the Lean-Agile leaders to take up SAFe course and use the knowledge to disseminate information regarding the Core Values, Mindset and Principles of SAFe and most importantly in identifying and setting up Value Streams and Release trains. Based on the consultations among the leadership team the setup details as given in below section was established.
IMPLEMENTATION STEPS
The initial step was already successful as Agile teams ( a total of 10 ) were already available in all locations with designated Scrum Masters, Product Owners and cross-functional teams. Most of the teams had been following Agile for some time and hence, were ready to adapt to the scaled models easily. Other teams were given the introductions through basic Agile training. They were then prepared for Scaled model through an in-house training.
The next item to be created was the Lean Product Management (LPM) team. This team consisted of 2 System Architects and 2 Product Managers. Initially no Release Train Engineer (RTE) was designated. However, as we moved forward, the necessity of a RTE cropped up. Hence, one of the Agile leaders was designated as the RTE during the second PI planning. The RTE ensured a weekly Meetup of Scrum Masters to discuss any dependency/problems within the community. He also ensured that any problem which needed LPM support got the desired focus from LPM team.
Business owners were designated from the B-Level managers of Marketing Department representing the specific product line. This group was best suited to handle the tasks of Business Owners as they had the historical background to note the prioritization of objective/tasks based on business value.
The initial Program Level Backlog was created with the help of Lean Product Management team translating the most important and essential business requirements derived from discussions with the Business Owners. This was a prioritized list with higher priority task representing essential and higher business value activities.
The Agile Release Train (ART )was setup using the Agile teams identified in (1). Even though they had already been trained, the ART setup took about a month of setup as Continuous Integration and Continuous Deployment meant that merges to mainline were automated required substantial changes to CI processes. Alongside this, changes to validation processes were also required as most product test cases needed to be automated.
Once the ART was setup, it was time for the initial PI planning. The initial PI planning was extremely chaotic even though preparation had been done for quite some time. The PI planning was held through video conferencing and required one team to adapt to the timings due to the regional timings. It was decided that the Iterations would be of 3 weeks. The total length of PI would be 14 weeks, with the last 2 weeks being used for IP. System demos were to be held separately at the end of each iteration and jointly at the end of IP followed by an Inspect and Adapt process.
The Product Backlog derived items from the Program level Backlog and allowed Business Owners and Product Management a chance to prioritize and review business value to be achieved through such tasks. These were identified further through the PI Objectives which were set after the PI planning. Every I&A cycle allowed teams to review the prioritization and business value achieved and to be aimed for in future.
One of the most important activities derived out of these processes were the mechanism of feeding Enablers into the Product Backlog through activities such as IP, Retrospection meetings, Community of Practitioners (CoP) or derived from Program level Backlog. These helped the architectural teams pave out the Architectural runway for future activities. Though simple to sound, these activities were extremely difficult to prioritize as they did not have an immediate business value which could be associated with them and hence, was likely to be overlooked by the LPM and BO groups.
A CoP was also created where architects regularly met in order to interact and understand problems of each team. This enabled the technical community to keep itself updated about systemic issues and solutions.
OUTCOME
The outcome of above setup was seen to be extremely positive. Development cycle of approximately 87 weeks in 2K15 was reduced to 45 weeks in 2K18 through above setup. The addition of various regional markets and clients and the complexities associated with such changes were handled quite seamlessly unlike in the past.
However, the biggest success was the focus which was now obtained throughout the organisation for these tasks. All teams, ranging from Marketing to Validation, focused solely on the success of meeting as high a business value through their joint effort as possible.
About Me : A passionate Agile leader having 16+ years of experience in software industry, I have handled Agile projects of various complexities. Having successfully handled Agile transition for multiple organizations, I write about my experiences, challenges and some solutions.