Agile Methodology: Extreme Programming (XP)

Here’s a quick review of the terms I have previously noted in my Coursera course: Software Processes and Agile Practices:

Software Process – models that you use to organize development into phases.

Software Practices – techniques or actions that you can use to help manage and track development

Methodologies – are defined groups of practices

Agile Practices and Agile Methodologies – practices and methodologies that are based upon the agile manifesto


One of the software development methodologies that adhere to agile practices is called Extreme Progamming. It is called as such because the practices applied here are taken from other methodologies but to an extreme level.

One fundamental component of this practice is all about client satisfaction. This means that the product manager and the development team will make sure that the client’s needs are met and that the client is as satisfied as possible. However, in a real world scenario, there are various types of clients and the practices of extreme programming does that.

Extreme programming values the following:

  • constantly delivering software
  • responding to change
  • effective team work
  • self-organization

Extreme Programming also focuses on these 5 aspects of development:

  • communication
  • simplicity
  • feedback
  • respect
  • courage

Extreme programming is also commonly defined by 12 basic principles. These are:

  1. Planning Game – the client and the development team work together to plan a product following these 3 basic rules.
    • They will come up with a list of new features that is expressed as a user story. Then, these will be converted to software requirements & client needs.
    • The development team will create estimates for how much effort they allot in the next iteration and how each user story will take to complete.
    • The client and the development team will then prioritize user stories, then decide when to release a working version of each feature.
  2. Small Releases – the release of the product has to be small and as frequent as possible.
    • The development team will plan with the client which features make good business sense and can be released early in the project.
    • The development team and the client need to find the right balance between what the client wants to complete and what can be developed early.
  3. System Metaphor – this is a metaphor that the team comes up with to describe the product to a non-technical person and what it does.
  4. Simple Design – here, the designs has to be as simple as they can be
  5. Continuous testing – the tests has to be written for a feature or requirement before the source code is written. This adheres to the test-driven development. The idea here is to use the tests as executable forms of requirement. There are 2 ways these features or requirements are tested:
    • Acceptance Tests – the client will test each feature of the overall product to see if it works as specified. These tests can be automated or they can be a script of user interface actions that a human follows.
    • Unit Tests – these are automated tests written by developers to test lower level functionality.
  6. Refactoring – this is all about restructuring the design of the code without changing the behavior of the code. It encourages responding to new changes.
  7. Pair Programming – two developers work side by side at one computer to develop and review the code. This way, the developments will more likely take calculated risks which can lead to innovation because they are not doing it alone.
  8. Collective Code Ownership – this practice suggest that the software product manager has to encourage the entire development team to contribute new ideas to any part of the product. This means that anyone can add code to any part of the product. With this, whether the product becomes successful or not, the whole team is responsible for it.
  9. Continuous Integration – this requires the developers to combine their code often and that all tests should pass 100% before and after the integration.
  10. 40-Hour Work Week – this is encouraging work-life balance among the developers, even with the most passionate ones.
  11. On-site Customer – this invites the client to be part of the development team and be around anytime to clarify and answer questions about anything that might come up.
  12. Coding Standards – this means that all developers code to the same standards. This means following a set of common code conventions.

In his first version of the Extreme Programming Rules, Don Wells has laid out 29 extreme programming rules; however, some of those rules are overlapping with the above 12 rules mentioned. There are management practices included in these 29 rules that is also interesting to mention here:

  1. Give the team a dedicated, open work space.
    • Work spaces should have multiple computers that belong to no one.
    • These work spaces should be located in the middle of the room and not along the walls to encourage the team to work together.
    • There should be a meeting table with white boards where the team can collaborate and brainstorm.
  2. Move people around.
    • This encourages communication and flexible work relationships. This means that everyone knows how to develop and operate all parts of the product.
  3. Change XP itself.
    • This means to fix extreme programming practices when it breaks. When something does not work, change it. By having frequent project retrospective meetings, it will be easy to determine what’s working and what’s not.

As the practice of XP has its benefits, it also has its weakness. These are:

  • The individual practices do not have as much value as the overall methodology. But sometimes, implementing all the practices is not practical.
  • XP is designed for small development teams.
  • There is lack of upfront planning with extreme programming. It does not encourage real upfront software architecture planning.
  • Difficulty to arrange an on-site client. In real world, clients won’t always be immediately available.

As such, extreme programming has many great practices for software development, but as a software product manager, it is important to find practices that work for the development team. This is just one of the many methodologies, but for sure, knowing a lot of this methodologies gives an edge for the team to implement what is effective.


University of Alberta (2020). Software Processes and Agile Practices. [Coursera Course] under the Software Product Management Specialization. Taken November 2020.

Patzelt, M. (2020). Extreme Programming. [Video]. Embedded under the course study videos under the Week 3 of the Software Processes and Agile Practices Coursera Course. Taken November 22, 2020.

Agile Practice: Continuous Delivery

All throughout the week, I have shared to you the most common software process models that a software product manager can best use for his/her product development. After the prototype is complete and once the product is ready for the client feedback, there are times when even if the prototype function well during development, it may not work as well for the client. To avoid this, it is an essential agile practice to automate the build of the prototype for testing, integration, and release of the product.

What is continuous delivery in the world of software development?

According to Stewart Hardy (2008), continuous delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

Continuous delivery allows the developers to deliver a product continuously, as it is being developed. Whenever a developer commits a code change, it will be built, tested, integrated, then released. The gap between the change and having it released is very short so it becomes noticeable for any problems that may arise. With this immediate feedback, the developers will be able to pinpoint immediately what went wrong and fix it in no time.

Further, continuous delivery prepares the product management team to release the product at any point, each to a specific channel or streams intended for different audiences for feedback. In order to support continuous delivery, the software product management team could use automated tools and these tools can be used to build and integrate the code, run tests, and package the product into a releasable form.

Test-driven development, usually used by large teams practicing continuous delivery, is an approach of writing tests before actually writing the code itself. The developers are actually solving the right problem by making the functionality they want. Here, the code is written, features start to take form within the product, and then with continuous delivery, the process is happening all the time and tested and fix immediately. If nothing breaks during the process, the prototype is ready for distribution anytime for testing by the users.

Check out this illustrated notes by Nhan Ngo continuous delivery:

See the source image
What is Continuous Delivery? – Continuous Delivery by Nghan Ngo


University of Alberta (2020). Software Processes and Agile Practices. [Coursera Course] under the Software Product Management Specialization. Taken November 2020.

Poulette, B. (2020). Unified Process. [Video]. Embedded under the course study videos under the Week 2 of the Software Processes and Agile Practices Coursera Course. Taken November 21, 2020.

Hardy, S. (2008). Continuous delivery: Introduction. [Article]. Retrieved on Nov 21, 2020 from

Software Process Model: Prototyping

In all the software process models I’ve shared, the spiral and the unified process models have used prototyping as a way to complete the phases. So, really, what is prototyping?

Software prototyping is the activity of creating prototypes of software applications. Prototypes are either a representation of the idea, or an incomplete version of the software product being developed. In other words, a prototype is a working model of a software or an idea with some limited functionality.

The five (5) types of prototypes in software development and the discussion for each:

  1. Illustrative
  2. Exploratory
  3. Throwaway
  4. Incremental
  5. Evolutionary


As the most basic of prototype, these are either drawings on a napkin, brief slideshow or just index cards with components drawn to them. These prototypes are usually in low fidelity and disposable image that is just used to share an idea and use as a way to weed out bad ideas. This also just gives the development team some guidance for creating solutions.


Exploratory Prototyping allows the team to focus on what the product look and feel but it allows a bit of development so the team will have an idea of the effort they need to exert to completely build the project. This prototyping usually allows the product developers to study the feasibility of some product idea so they can scope out the whole development process.


Let’s say the product developers have already created a prototype and has already a working version of the software, but with minimum features. The first product usually has various problems and when clients check, the team will realize they want a different version from the first. Instead of building further from the first prototype, the team decided to build a completely new version, based from the feedback and approach being learned from the first one.

The throwaway prototype gives the developers an opportunity to learn from past mistakes and for the business side of the project, it allows the client and the management to stop the product release, and improve the product further with a totally different version.


This type of prototype allows the product with limited functionalities to be used until the final product version. The key idea is to have a working software for each successive prototype, to which can be released on each iteration as a version of the software product.

In this type of prototyping, the product is developed in a triage system. Here, each system’s components are assessed and given priority. Based on that priority, the development team creates the product from the ground up. The most critical feature are a must-do and becomes the core features, while those aren’t absolute priority are tagged as a can-do feature added after each iteration, or each version of the product. Since the product’s features are prioritized, it is then becomes easy for the software product manager to map out and plan the development with the team.


In this prototyping, the development team begins creating all the features in basic form, then just refine or evolve them, over time. Here, the users will be using an early version of all the features and the developers will just build on successive prototypes of the working features until these are much more easier or flexible to use. In this way, the product evolves from a rudimentary working prototype to something feature rich and robust.


With illustrative, exploratory and throwaway prototyping, the initial set of work done after set aside to create a newer version of the product. Though for some software development processes, developers use illustrative prototypes to kick off the working product. On the other hand, the incremental and the evolutionary prototypes build upon the minimum set of features, and works to add or build more even after the final product is released in the market. In these types of prototyping, the working software from the initial build is already shown at regular intervals to the client for feedback and improvement.

In the end, the core idea behind prototyping is to gain feedback on versions of your product, right? So here, we see why prototyping is really important.


University of Alberta (2020). Software Processes and Agile Practices. [Coursera Course] under the Software Product Management Specialization. Taken November 2020.

Poulette, B. (2020). Prototyping. [Video]. Embedded under the course study videos under the Week 2 of the Software Processes and Agile Practices Coursera Course. Taken November 21, 2020.