Microsoft released Word for Windows word processor in $1989,$ after five years of development. The product received significant acclaim, and the sales concluded higher than Microsoft$$s projections, however, the project faced several project management issues in its execution $[1].$ The project had issues ranging from ill$-$defined requirements, lack of planning, inadequate project management, and random role assignment $[1].$ Most of Microsoft$$s products at that time were among the best available products on the market. Though the product was built in Microsoft$$s standard style, Office Business Unit project needed a structure $-$ a process framework to guide the development. Following points were noted before identifying the software process and framework: Microsoft work culture: The work culture at Microsoft at that time was informal $-$ software engineering staff handled project execution decisions; roles were interchangeable, and projects were carried out without formal requirements documentation. Microsoft$$s release strategy: Microsoft$$s preferred strategy was to deliver the product in many small releases with short durations. Time constraint: The initial project was scheduled to be delivered in one year. Focus on programming: Microsoft$$s projects at that time relied heavily on programming aka build and demonstrate model. It had always worked for them in the past. Developers and managers were not very concerned with the software architecture or process methodologies. Small team sizes: Development team size was typically limited to $10$ people. Unclear requirements: The requirements for the project were not well defined. Microsoft wanted to add as many innovative features in the word processor, without defining the project scope. Based on the above factors and as per $[2]$ an agile process like Extreme Programming $($XP$)[14]$ would be a better fit for the OBU project. Below are potential reasons as to why extreme programming would serve the project better: Time criticality $/$ Small releases: The primary focus of Microsoft was to release the product to market as soon as possible. With XP$,$ it could be achieved by releasing an early version of the software and then incrementally adding functionalities to it with later releases. Such incremental deployments are not feasible with traditional software processes like Rational Unified Process $($RUP$)[11],$ due to its monolithic development style. With Agile, the product can be built incrementally; particularly with Extreme Programming $($XP$)$ process, a simplistic model of the system is released to production and newer versions are released in short cycles. Undefined requirements: Since the requirements were unclear and volatile, it makes sense to choose an agile process that could quickly respond to changes. Code$-$centric development: The nature of the project suggests that it was going to be code intensive $($a word processor with many innovative features$).$ Also, at Microsoft, significant emphasis was on programming, rather than on system architecture documentation. In XP$,$ programming forms the core, and it allows programmers to take decisions about the design. This would have worked well with engineers like Hunt $$ one of the programmers responsible for deciding on the features for Word. Informal work culture: Traditional methodologies are rigid and do not work well in informal settings $[13],$ but XP can work very well in such configurations. For example, pair programming, one of the tenets of XP$,$ can be beneficial when developers are comfortable working closely with each other. Small team sizes at Microsoft could support such practices. Furthermore, it is unrealistic for them to use a cumbersome process such as RUP which requires a highly structured and complex team with many roles and requires tool support. Focus on quality: Bill Gates wanted this to be the $$best word processor ever$$ and much time was to be spent on getting every feature right. Characteristics of XP such as refactoring $($restructuring the program to improve quality$)$ and continuous testing $($continuously writing unit tests, which must run for the development to continue$)$ would serve this purpose greatly. Having a working system at all times: Some Microsoft managers were of the opinion that a List a couple of reasons why Agile was most suitable for Microsoft