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.

Concepts in SPM (Agile Software Development)

In any project, there are parameters for measuring success:

  • on-time delivery
  • completion of project within budget
  • delivery of complete features or requirements

In software product management, it is the same. However, there are added items:

  • The number of post-release bugs
  • The technical support needed after a software release
  • The software product’s customer rating
  • The revenue generated
  • The client’s satisfaction

It is basically a lot, huh? Well, a software product manager will help identify the product and project success by checking the above parameters for and make sure that the development efforts are directed towards the delivery of a quality product.

Agile Software Development

Agile, from the definition of Miriam-Webster dictionary, is having a quick resourceful and adaptable character. So when we say agile software development, it is the set of software development principles created for effective and adaptive software development where it prioritizes 4 core values:

  • Individuals and interactions
  • Working software
  • Customer collaboration
  • Response to change

Below are the 12 Agile principles from the, with infographics designed by the University of Alberta for the Coursera Course: Introduction to Software Product Management:

Intro to Software Product Management

Pardon me if I am now using my blog as my online notes, but I am now on a learning journey! I have realized a lot this 2020, in terms of career, lovelife (that’s for another blog post ;-)) and finances. Now, I am taking one step at a time to improve myself, and the series of blogs I am writing are records of my learning journey. So if you are okay with learning more about my world, feel free to read and follow. 🙂

See the source image
screenshot about product management from

To start, what is software product management? Well, for one, software product management is different from project management. Though there are common features for both; however, the difference lies on the application. Project management is a broad field that can be applied in any development scenario (like preparing for a wedding, building a house, etc) whereas software product management describes practices for project management but particularly aimed for creating software products.

To achieve a better software, just like in learning, you must have a goal to accomplish. In software product management, there are three goals, particular for each member of the team:

  • Client – the goal of the client is to make sure that the software product meets their needs and solves their problem. If a client is happy with the product, the software is validated.
  • Developer – the goal of the developer is to make sure that the software they are developing are done right — meaning the design and the implementation frontend and backend satisfies the needs of the client. Here, the developers conducts reviews and tests to make sure the software is verified.
  • Product Manager – the goal of the product manager is to manage the development process of the software and organize the work of everyone involved. Here, the project manager makes sure there is clear communication, clear objectives and clear feedback so both the developers and the clients are happy.

In short, the goals in software product management are: clients ensures they have the right product, the developers verifies they have done the right product, and the product manager confirms that the requirements and process for both are managed right.

So, the role of the software product manager is important in any software development (which is basically what I do for a new project). A software product manager is in charge of the success of a software product. This role involves understanding the product from the client’s point of view and requires effective communication and motivation of the development team members.

So, am I ready to start learning and taking the Software Product Management Specialization, a Coursera course offered by University of Alberta? Well, yeah, that’s for sure!!

Please bear with me as I post more and more blogs on my learning journey, but if you are also interested in this field, feel free to read and follow. 🙂