Maintaining large complex software is one of the major challenges faced by today's software industry.Refactoring is one way to do so.It is the process of changing internal structure of project code or software design without altering functionality.It improves software quality and reduces software entropy.This paper presents the preliminary results of an explanatory survey targeted at investigating refactoring practices by IT professionals.221 participants helped to reveal important facts about refactoring risks, benefits, limitations of tools, and how a team manages consistency between different artefacts while practising refactoring.Findings reveal that refactoring tools are under-used as they have availability, usability and trust issues.An automated system is the need of the hour to manage change consistencies, visualizing code structures, detecting code, and design smells, and performing refactorings.This study will enable researchers and developers to understand their role in a better way as prevailing issues with current state-of-art are exposed and challenges are reported.

This paper presents our experiences with a 120-person matrixed software engineering product team, spread across three countries that successfully scaled their adoption of Scrum. The product is a legacy, mission-critical software system that conforms to stringent healthcare regulatory standards. We are practicing Obeya wall that brings solution to our large team communication challenges and OYA day that helps solving challenges in fostering innovation, and learning culture and collaboration. We also are describing our experience of defining focus areas of project manager and product manager. These roles are not defined in scrum guide, however, is relevant in our experience in scaled up distributed scrum environment. The authors bring our experiences as a Scrum Master, Product Owner and an architect who have been integral part of the journey and establishing these practices over several years. These practices have helped in scaling as well as stabilizing the team to an extent where each product version is meeting milestones on time and taking strong steps towards shorter release cycles of quarterly releases. This paper also summaries our lessons learned, and recommendations.