There is a special relationship between Scrum and Extreme Programming (XP).

Scrum is one of many iterative, incremental development (IID) processes for developing new products services. As such, it produces a complete and functioning set of deliverables (functionality) at the end of every iteration (‘sprint’). Strictly speaking, Scrum is defined by only three roles and a few simple processes; however, real projects require more processes to succeed than are technically included in Scrum. For example, requirements elicitation and documentation, solution design, estimating, planning, and quality assurance processes are all absent from the pure definition of Scrum. These processes are typically included in other methods, such as Extreme Programming (XP) that are often combined with Scrum to create a complete project methodology. In fact, Jeff Sutherland, one of the co-creators of Scrum once noted that in 1995, he “provided Kent Beck background information on the creation of Scrum to help him create Extreme Programming. XP engineering practices then evolved along with SCRUM and the two leading Agile development processes work well together.” In fact, According to Sutherland, the two processes are often inseparable: “The first Scrum team starting in 1993 rapidly achieved a hyperproductive state by implementing all of the engineering practices now known as XP, along with some that are not in XP. […] Few implementations of Scrum achieve the hyperproductive state for which Scrum was designed (5-10 times normal performance). Those that do all implement variations on XP engineering practices.”

Even though the “pure” definition of Scrum creates an incomplete methodology, widespread use of the methodology over the years has led to the emergence of typical Scrum practice, which borrows heavily from XP and other methods.

Nevertheless, Scrum is best characterized as a project management methodology for product development, rather than a technical development methodology. The difference is important. Most other agile methods include a mixture of both project management elements (what work needs to be done, when it needs to be done, why it should be done, and who will do the work) and technical elements (how the work will be done). For example, in the twelve principles of Extreme programming, there are project management items (whole team, sustainable pace, planning game and small releases) and technical items (paired programming, continuous integration, refactoring and shared code ownership). In its purest form, Scrum is a project management paradigm only. It consciously avoids defining processes for the technical work that actually builds the product or service; rather, it focuses on only how the overall work is to be managed and how the project team will interact with the outside world (e.g. reporting progress to project stakeholders or how requirements and change are to be managed).

With Scrum as a product or service development project management paradigm, almost any technical method can still be used to deliver the actual project work – the activities that build the desired product or service. As mentioned above, a common implementation is Scrum being used to manage a project whose technical efforts follow the Extreme Programming practices. While this leads to a very agile and efficient project, in some instances Scrum managing a project structured as a chain of small “waterfalls” can be nearly as effective and, in fact, this latter is one of the most common implementations of Scrum in the workplace. With the project divided into iterations, and with the other project management elements of Scrum implemented, you gain nearly all of the benefits of agile, without overly impacting the project technical teams – they can still be using their traditional waterfall development approaches (though only on one iteration/waterfall at a time).

Latest Events