The Agile methodology formerly in place for software development at Schneider Electric Engineering Workbench could not give the desired results. But a typical implementation of CCPM would not have worked either! The company innovated a flow model based on the core concepts of TOC which not only created a more harmonious work environment for the development team but also increased productivity by a whopping 33%! This is their story…
Schneider Electric Engineering Workbench, a product from its Process Automation, Industry business helps in automating the configuration and engineering of the instrumentation and control systems of brown/greenfield projects. Faster engineering helps in reducing lead time to start of operations and thereby improves profitability and reduces the risks of penalties for the Automation vendor.
Requirements (technical and marketing) are pooled in from globally distributed teams of technocrats and marketing personal and converted into a roadmap of deliverable products (software versions). Each product is a predefined bundle of features which has to be completed before the decided release date. Schneider’s project management team describes the user stories in each feature and then outsources the development of these products to software service companies.
CHALLENGES POSED BY AGILE METHODOLOGY
Outsourced companies of Schneider followed the Agile methodology consisting of sprints (4 weeks each) to develop the software. During each sprint, teams of developers and testers would create tasks for each user story, write code and test it. As user stories got completed, customer demo was undertaken followed by functional testing. Final round of testing was done in the last sprint of release called the Hardening sprint. Post successful passing of all features through these test cycles, the product was declared ready for release. This methodology unfortunately posed several challenges:
- Overloaded expert resources
Development and testing teams were expected to be self- sufficient in terms of skills of design, development and testing. But resources with environment specific skills like design and requirement analysis, which is only acquired with adequate experience, are few and difficult to hire for. As a result the Expert resources were heavily loaded throughout the sprint/release and would be found multitasking across stages- Requirements, Design, Development and Support.
- Priority conflicts
Since the expert resources were often busy, to make best use of their time, development teams would start work on the next user story, while awaiting feedback from the expert resources. This led to many partially open work fronts for developers. With increasing work packets open – priority conflicts ensued.
- Frequent rework
Testing was the primary source of feedback on design and development gaps. Consequently, continuous “flow back” and re-work became inevitable. Further, since design decisions often made within independent teams working in parallel, this caused conflicts at integration points creating further rework. Engineering Workbench was hence experiencing poor productivity, significant rework (about 20%) and effort overrun (about 30%) with about half of the defects leading to requirements and design.
- Compromised sprint closures
Towards end of each sprint, everyone worked to drive closures. But this effort spiking compelled compromises – some testing was skipped or some bugs were kept aside or some scope was set aside for later sprints. Therefore the features coming out from the periodic sprint cycles were not “usable” and the predictability (for customers) of release schedules was lost.
- Delayed planning of subsequent sprints
Moreover almost all resources in the team become extremely busy towards the sprint closure. As a result, the next sprint is started with insufficient preparation – i.e. inadequate detailing of requirement leading further into the viscous loop of rework and delay.
- Reliability and Quality reputation hampered
Because of this chaotic working, lead times were stretched (release would take up to 10 months) and marketing often complained of missed opportunities due to long lead times. Moreover, in spite of a massive effort towards the end of the “final release” to clear backlog, the pressure to deliver and overload of pending work led to further compromises. So when the product was eventually released, customers complained of defects and became unhappy.
The objective of TOC implementation was to bring about improvement in product development operational performance in terms of – improvement in on-time delivery performance, reduction in lead time and increasing rate of customer usable features delivered every year.
IMPLEMENTING THE TOC APPROACH
Core Conflict: In order to ensure productivity of development teams, the expert resources were needed to help them troubleshooting. But at the same time, to ensure that customer needs are met in the most efficient way, they were needed for understanding requirements and develop solution proposals.
Decouple resources: Expert resources were decoupled from implementation stage. They were assigned to focus on understanding requirement, generate high level design and map out software dependencies. Rest of team was split between detailed design and implementation & testing. Fixed short duration slots within a day were fixed, where upstream and downstream teams would meet to discuss and resolve issues.
WIP control: WIP on feature level was reduced to one at every stage, so that at any time, cherry picking and waiting time were reduced drastically.
Full kit: Entry and Exit criteria were clearly defined and enforced at all 4 stages - Requirements, Solution & High Level Design, Detailed Design, Implementation & testing. To reduce foresight errors, in solution proposal and HLD stage, following were made mandatory - Protos usage to check understanding and solution with Program Management, plus Identification of Testing boundary conditions by Validation team.
Active Task Management: Daily Active task management to identify and resolve flow obstructers was put in place.
POOGI: At end of every feature (this can be end of each Progression), flow obstructers origin was identified and fix incorporated in the next feature itself.
- Hopelessness: There was a lack of belief that anything would change the situation – many things were tried and even latest methodology- agile techniques was not helping
- Disagreement on problem: Since the software outsourcing partner (vendor) worked on a billing model, many in Schneider believed that they had no motivation to do clean releases on time. So changing the methodology of work was not expected to help.
- Resistance to cutting estimates by half: since it was believed it will further stress out the beleaguered team
- At the end of a year, past the eight-month assignment, Schneider reported the following benefit
- Frequent and lower lead-time in serving customer requirements (release every 3-4 months against earlier 9 months); 7 releases in year, post TOC!
- High adherence to product roadmap (roadmap variation only about 10%)
- Higher output combined with nearly on time delivery – high 90%s
- Defect density % reduced by 4 times, from high 40s to 10s (rework greatly reduced)
- Time released for pure R&D work – 1 patent filed and 3 RDIs completed
- Stress free environment – people in software industry are going back home on time!!!
- It is possible to decouple resources/stages in software product development, as in operations.
- Myths of Agile – self-organizing teams and usable feature at end of each sprint
Summary: The Agile methodology formerly in place for software development at Schneider Electric Engineering Workbench could not give the desired results. But a typical implementation of CCPM would not have worked either! The company innovated a flow model based on the core concepts of TOC which not only created a more harmonious work environment for developers but also increased productivity by a whopping 33%! This is their story…
1. Major challenges faced by software companies by following agile methodology
2. Major challenges faced in implementing CCPM in Software Development
3. Injections needed to address specific challenges in software new product development environment
Questions that can be asked by the audience:
1. What were the major roadblocks experienced during implementation - as software contractor is also involved?
2. What are the challenges faced in managing transition in a MNC with many stakeholders?