Freelance Mistakes: What I Learned in Starting my Journey

I love learning and I dream of going freelance all the way. So when I decided to dive into freelancing, I did not expect that what I’m doing can be a mistake most freelancers do, with or without experience.

The Pandemic Reminded me of my Dream

When I started my career in training and product development, I have this desire to always learn and improve myself. I have learned all the tools I need to use, communicate effectively across various levels of organization, and manage my projects effectively. Back then, I dreamt of being my own boss, and providing my services to businesses who would benefit from my expertise. So when the pandemic happened in 2020, this dream has become my lifeline to continue and move forward. To hope for a better future.

My journey to freelancing is a tough one. I have been going back and forth in my mind whether or not to dive into the freelancing industry. Maybe because of fear, or maybe because I am not familiar with the freelancing landscape. However, when I decided to become a freelancer, everything just fell into place.

Right now, I am learning a lot about marketing, design and development. I will be using my blog as a diary of my journey. So if you are interested to go with me, just hit up the subscribe button. 🙂

CHANGING MY PERSPECTIVE

For the past months, I have been trying my luck on freelancer platforms to offer my services on my niche but have failed. I am not able to get even one client, and most of my time has been about preparing resume, preparing my portfolio and honing my skills. If this is effective, I will not be frustrated with my process. So I have decided to attend the Philippine Online Freelancing Conference and get training on how to start freelancing.

freelance mistakes of a stressed black male entrepreneur working on laptop in park
Photo by Ketut Subiyanto on Pexels.com

After attending the training, I realized about the 3 mistakes I have been doing all along:

Talking about my service.

I focus on the words that would impress the potential clients for so many time that I start to realize if it is really effective. I realized that to be successful in freelancing, I need to put the right offer in front of the right market. What does this mean? I need to find a client with a problem that I can solve and offer my services instead of just talking about my skills.

Selling my service right away.

When someone has a problem and looking for a solution, it has been default for me to offer my services, what skills I have and the certifications I gained. However, when a client needs a problem to be solved, he/she doesn’t care about my skills and certifications (though they still look at it though). Their first instinct is to know if I can solve their problem.

As a freelancer, I learned to have a consultative approach, meaning, look into the client’s problem first, dig deeper and analyze a solution for them. That way, whatever proposal I send will be tailor-fit to their concerns and will be accepted with wide open arms.

Impressing clients with my freelance portfolio and experience.

Similar with the previous mistake I did was to send proposals focusing about me and what I can do, instead of solving the client’s problems. In freelancing, one of the edge that premium freelancers do is they help their clients solve problems, not just offer their services. The portfolio and experience will come naturally once I have solved a couple of problems. But at the core of it all, the driving force for freelancers should be to extend help to businesses in a way that their services will solve their client’s problems.

Learning To Freelance

As I start this journey of freelancing, I am taking up as many online courses I can find to gain my knowledge and skill in this path I have chosen. The course I recently took, Learning How to Learn: Powerful mental tools to help, really helped me a lot to absorb all the concepts and lessons. To learn more about this course, check out my post, Understanding more about Learning.

Agile Methodology: Kanban

Kanban is a methodology that was developed alongside lean manufacturing. It was originally designed to be used with lean manufacturing, but it can also be used independently of lean.

So what is Kanban?

Kanban is a project management system invented by Taiichi Ohno, an industrial engineer at Toyota. Kanban involves a technique to organize and track project progress visually, which is widely used even outside Agile or Lean software development.

Kanban is considered an agile methodology that accounts each component to be tracked for, and the process notifies each phase of its status. With this, it is easier to identify when to create new component. In lean manufacturing, this is called Just-In-Time manufacturing.

When a component is used, the process that replaces the component is notified so that a new one can be created. Basically, when a bin is emptied, a new component is created and placed into the bin as soon as possible. This strategy of continually using and refreshing items in bins on the factory floor is called the pull method.

In software development, this process is visualized using a task board, with each software development activity represented as a column on the task board.

The Kanban Board.
Screenshot from the video Kanban, part of the Coursera Course
Software Processes and Agile Practices

In Kanban, all of these phases are coordinated. If a piece of work is done in one column, it’s ready to be pulled by the next column. However, an opening must form in that next column to allow the piece of work to be pulled into that phase, continuing the cycle.

Work In Progress – the amount of work currently in development in each phase

Bottlenecks – the slower parts of the process. A bottleneck occurs when one phase cannot keep up with the work created by the preceding phase

Two ways to address a bottleneck:

  1. Ramping up production at the bottleneck
    • by adding resources to speed up production
  2. Decrease production ahead of the bottleneck
    • by moving resources from one phase to another. Examples are multi-functional developers who may be in the development phase, moved to acceptance testing phase so the bottleneck in acceptance testing phase will be addressed.

Work in Progress Limits – this is limiting the amount of work that must wait to be pulled into the next phase.

Cycle Time – this is the total time that it takes for one piece of work to go through one full cycle of doing the work. This is the metric software product managers check to know if a change in the bottleneck has made any difference.

To measure cycle time in each phase, it is important to know when a piece of work is started and when it’s finished. Then, calculating the number of hours between these timestamps and we get the cycle time.

Cycle time is important because it’s a measure of what the process can handle and the quality of practices rather than a measure of the development team’s effort. A software product manager knows something is right when the cycle time is decreasing and the product quality is remaining constant or improving.

So, in summary, Kanban is a set of practices that allows the team to track their progress over time through the Kanban board, and ensures that the Just-In-Time development strategy is followed. In turn, waste is reduces and decisions are made as late as possible.

An effectively managed Kanban board will give a software product manager a clear picture of your project status at a glance. It can also help with improving efficiency, productivity, and collaboration.

References:

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

Poelette, B. (2020). Kanban [Video]. Embedded under the course study videos under the Week 3 of the Software Processes and Agile Practices Coursera Course. Taken November 25, 2020.

Agile Methodology: Lean Software Development

Lean Software Development is one of the methodologies in Agile that is gaining traction in the industry. Originally, it started when Toyota adopted in the mid-90s the lean thinking concept as a way of reducing risk within projects. Here, the focus of the approach is to reduce waste, start new work only when necessary, reduce process bottlenecks and work only on things that will add value to the project.

Further, when Mary and Tom Poppendieck in 2003 wrote Lean Software Development: An Agile Toolkit, a book about adapting the Lean manufacturing principles to software development, the concept gained traction and became popular.

To start, Lean is a mindset or a set of core principles to reduce the project’s risks and deliver high quality products to the clients quickly.

In software development, Lean consists of seven (7) principles. These are:

  1. Eliminating waste
  2. Amplifying learning
  3. Deciding as late as possible
  4. Delivering as fast as possible
  5. Empowering the team
  6. Building quality in
  7. Seeing the whole
Screenshot from the Video: Agile Variations and Lean Software Development
in the Coursera Course Software Processes and Agile Practices

Let’s look at each one:

ELIMINATING WASTE

Eliminating Waste means having to decide to look at the process and makes sure that when putting everything together and integrating all the work product after, there is no unnecessary work product. An example of how a software production can be wasteful is when a developer is busy all the time, creating new features instead of the core features, the developer might run in to be developing unnecessary features that can either bog down the quality of the end product, cause issues with the main product or not end up in the final product. The software product manager will not want this for the team.

AMPLIFYING LEARNING

In Amplifying Learning, ideas are explored further by checking alternative solutions before proceeding with actions. For example, the development team creates the basic list of user requirements then already starts to develop the basic functionality. This is normal. However, before moving on to the next functionality, the team will stop and check for alternative approaches for that basic functionality. As a consequence of this, the product has its best chance of meeting then the client’s needs.

Also, running tests, and involving the client in the development process along the way is a great example of amplifying learning. This allows the the development team to learn through trial and error when they constantly presents a working software to the client.

In short, in amplifying learning, the team builds the right product through developing alternatives, continuous feedback and refinement.

DECIDING AS LATE AS POSSIBLE

Here, the core idea of deciding as late as possible is not about delaying anything for the project or buying time to complete the work product. It is about making decisions when the data and information you need is available.

For example, the client informed the team his requirements for building the product. The development team started working and is able to produce a prototype. After the initial feedback, the client says that the prototype is good to go. Instead of starting on further development, you work hard to ensure that there are many alternatives. Decisions made before you have enough information are bound to result in poor outcomes. Deciding late as possible ensures that you have the information you need first.

DELIVERING AS FAST AS POSSIBLE

This is intricately related to deciding as late as possible. In deciding as late as possible, the development team will explore possible approaches to further deliver the client needs. Because of this, the client now has an opportunity to see the prototype in three different approaches, and correct any wrong notions or decisions that could have further delayed the project. Once the client has made the right decision about the feature, or the product itself, it becomes easy for the team to build the right features and not wait for several months before changing a feature that is eventually unnecessary.

Imagine having the go signal from the client, the development team started further development on the features and after three months, the client wanted to see 2 new approaches? It will take another 3-6 months for the team to develop the features, wasting time and resources when these can be fixed initially during the prototype sessions.

This is the importance why lean software development operates in short rapid iterations.

The development team will build a basic product, make sure it works, and get it out the door and then worry about the next steps. By operating in short bursts, the product evolves at a rapid rate and allows client feedback at frequent intervals throughout the process.

EMPOWERING THE TEAM

As a software product manager, instead of micromanaging the development team, it is important to focus on your efforts to understand the client’s needs, remove the developer’s roadblocks and get out of the way. Lean software development encourages managers to listen to their developers. Software product managers are encouraged to let the developers imagine solutions that satisfy the client requirements, and to allow the the team to work how they want to work.

Trusting the team to make the right technical decisions not only does make the developers productive, but it also boosts their morale. A happy development team is a productive and an efficient team.

BUILDING INTEGRITY IN

In this principle, it aims to ensure that the development team are provided the best practices in software development to avoid errors.

Example would be using the test-driven development principle. Also, the team can apply the pair programming if it works for their development practices. Another practices would be well commented code, good documentation, refactoring code to be more efficient and automated testing. All these serves the purpose to make the product better.

SEEING THE WHOLE

What it means to see the whole is to see the software from more than just a lot of little components put together. What the end user should see is a cohesive product with components that flow into each other logically and smoothly. So in Lean software development, it’s important to think about the product as a whole before releasing it. This means that the developers must be constantly aware of how their piece of the puzzle fits into the big picture. Seeing the whole allows your development team to build a product as a cohesive well-designed whole.

Mary and Tom Poppendieck has additional principles that software development teams can apply:

  • Use the scientific method when building a system
    • As a software product manager, doing experiments to test ideas and collect data allows everyone on the team make informed decisions. ‘
  • Encouraging leadership
    • This means enabling initial individual developers to be courageous, innovative, inspirational and collaborative.

In summary, lean software development is a methodology that allows the team to create better software and have happier clients. It also encourages fast-paced iterative development, client interactions and the use of proven software development techniques to be successful.

References:

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

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

Agile Practice: SCRUM

What is SCRUM?

Scrum is a lightweight agile practice that doesn’t take too much time away from production, uses both the iterative and incremental system process models, and enhances predictability and mitigates risks.

Pillars of SCRUM

  • Transparency
    • It means that everyone can see every part of the project. This means that both the Scrum team and the client is familiar of the development updates.
    • Here, the team is agreeing on using common terminology to use through development.
  • Inspection
    • Scrum encourages frequent inspection of work products and progress to detect undesirable deviations from expectations
  • Adaptation
    • When the team has found themselves deviating from the software requirements, they should be able to easily adapt and adjust. Also, called Scrum events, these techniques to help with this are:
      • Sprint Planning
      • Daily Scrum
      • Sprint Review
      • Sprint Retrospective

All these events are time-boxed, meaning the Scrum team needs to specify a maximum time for the duration of each events and adhere to that. Let’s look at each one.

Photo from http://www.enliveningedge.org under CC BY SA 4.0

Sprint is a development phase of a specific amount of time, in which a working prototype is delivered to the client. Here, the sprint lasts one month or less, typically 1 or 2 weeks. After each sprint, a working prototype is delivered to the client. Each spring consists of the four scrum events, which are:

Spring Planning – occurs at the beginning of the current Sprint to determine what will be completed in Sprint.

Daily Scrum – this is a daily meeting that occurs at the beginning of each day so that the team can talk about the tasks they will need to accomplish for the day.

Sprint Review – this occurs at the end of the Sprint. This is also where the working prototype is delivered. It reviews what has been accomplished, what has been tagged as “DONE” and what needs additional increment for the next sprint.

Sprint Retroactive – this is where the suggestions that will change the Sprint goal will go to the Backlog, to start the next Sprint as the product owner decides.

How is a feature considered ”DONE“? A feature is considered done when it is coded, tested and documented. During a sprint, a requirements change is not allowed if it is outside the sprint goal.

ROLES OF THE SCRUM TEAM

A Scrum team consists of the product owner, development team and the scrum master.

Product Owner – the one in charge of making decisions about the product and the product backlog. He/She can represent a committe but can be the only one who can implement the changes to the product.

Development Team – the teams in Scrum are self-organizing, which means that they are in charge of taking their backlog of features and turn them into increments of working software. The team are also cross-functional where each member can be specialists from different areas but are able to do tasks other members can do. Lastly, the development team has no subteams, and can only consist of about 3-8 developers.

Scrum Master – the scrum master is the coach of the team, and is in charge of making sure the team is adhering to the scrum theory, practices and rules. As a scrum master works with the product owner, he/she finds techniques to help manage the backlog, as well as facilitate scrum events. On the other hand, when a scrum master is working with the development team, he/she coaches the team to self-organize and remove development roadblocks.

Major tech companies like Amazon, Microsoft, and Adobe are using Scrum. To learn more about it, check out scrumguides.org.

References:

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

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

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

EXTREME PROGRAMMING

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
See the source image
Photo from dilbert-extreme-programming-three.gif (600Ă—213) (voidspace.org.uk) under CC BY SA 3.0

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.
See the source image
Photo from dilbert-on-extreme-programming.gif (600Ă—212) (wordpress.com) under CC BY SA 3.0

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.

References:

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

Reference:

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 https://continuousdelivery.com/.

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

ILLUSTRATIVE PROTOTYPE

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 PROTOTYPE

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.

THROWAWAY PROTOTYPE

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.

INCREMENTAL PROTOTYPE

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.

EVOLUTIONARY PROTOTYPE

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.

DIFFERENCES BETWEEN PROTOTYPES

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.

References:

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.

Software Process Model: Unified Process Models

I’ve already shared to you about the Linear Models and the Spiral Model, so now, let me share to you my notes on another iterative model of software development — the Unified Process Model or Unified Process.

A Unified Process is an iterative model of software development where its basic structure is to work in a series of phases which get repeated until the final phase is complete. How are phases deemed complete? In this software development process, the development happens in small iterations until a phase is deemed complete or when a milestone is reached. According to Miriam-Webster, an iteration is a repetition of a process. So here, each phase is being repeated within until a work product is provided for the next phase to work on. Note, however, that the unified process also allows the tasks done in one phase to overlap with another task. This is referred to as parallel development.

The Unified Process. Screenshot from the video: Unified Process under the Coursera Course
Software Processes and Agile Practices

As we can see on the photo, the unified process has 4 phases namely 1) inception phase, 2) elaboration phase, 3) construction phase and 4) transition phase. Let’s look at each phase:

  1. Inception Phase – during this phase, the team creates the basic use cases. Use cases outline the main user interaction with the product, and here, the project scope and potential risks are identified. This is the only phase where development does not happen in iteration. In this phase, the main goal is to see if there’s a strong enough business case to continue development and financial reason to build the product. At the end of this phase, the life cycle objective milestone is achieved.
  2. Elaboration Phase – in this phase, the small iterations to create the model or prototype of the product will be implemented. The requirements for the system architecture are laid out like the use case diagrams and high level class diagrams. Since this phase undergoes iteration, there will be redesign of the system requirements and architecture before the development becomes complete. This is also where the process of several activities are done in parallel.
  3. Construction Phase – this phase is just a continuation of the elaboration phase, but the emphasis is now more on testing and programming of the codes of the system. Whatever was completed in elaboration phase, this phase builds on it and thorough use cases are developed to drive product development. These use cases are more specified, developed and tested iteratively until the product is ready for release.
  4. Transitioning Phase -Once the development is complete and product is ready to be released, this is the phase when the team will start preparing documentation and implementation requirements for your client and the users.

So, in other models, all the software product requirements are narrowed down and polished at the beginning of the process. However, in the unified process, the development team can both design the product architecture while developing the tests at the same time. Its focus is on developing the design models along with the software product itself.

References:

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.

Software Process Model: Spiral Models

In software product management, knowing what tools to use for a particular project of software development is important to be able to make the right choice in using the appropriate process. Another set of process models I’ve taken note in the Coursera course, Software Processes and Agile Practices are the spiral models, or the iterative software process models.

Iterative Software process models are the ones which allow for repeating stages of the process. These types of process models allow the development process to loop back on previous steps, and accept feedback within the process. They can be considered as the pioneer in agile practices, but also allows sequential steps.

SPIRAL MODEL

This model was introduced by Barry Boehm in 1986 where he outlines a basic process for designing and implementing a software system by revisiting phases of the process after they’ve been completed. This model basically has four (4) quadrants which stands as the phase of an iteration. An iteration is considered the duration of one full spiral or all four quadrants being completed one time. In each of these phase, there are activities and once completed, the process moves on to the next to complete one (1) iteration. Afterwards, the development team can review the product at the end of each spiral iteration.

Screenshot from the video: Spiral Model from the Coursera Course Software Processes and Agile Practices

In the Spiral model, even though the projects might differ per case basis, there are always six (6) conditions that almost always stay the same. These are called the invariants of the Spiral model, published by Barry Boehm in his follow up paper in year 2000. These invariants are:

  1. All work products of a software project should be created at the same time.
  2. All the quadrants in the model must be addressed, and there’s no skipping steps.
  3. Every project implementing the Spiral model should base the amount of time they spend on any particular activity, on the amount of risk involved in carrying that activity out.
  4. The software product manager should focus a lot on making sure that each decision is based on risk data.
  5. Each iteration of the Spiral should result in a tangible work product.
  6. The focus of the process should be on improving the process, as a whole.

DISADVANTAGES OF THE SPIRAL MODEL

Well, for this software process model, there are definitely pros and cons, and as a software product manager, one should be able to identify the disadvantages to see if it fits the project as whole. These disadvantages are the following:

  • Planning tends to be done upfront at the beginning of each Spiral.
  • Depending on the duration of the Spiral, it can be difficult to make good estimates.
  • The ability to minimize risk in a calculated fashion requires an immense amount of analytical expertise.
  • The risk assessment tasks can consume a great deal of resources in order to get it right.

As a summary, Spiral model is an iterative software process model that allows for the revision of the product in certain intervals. It has conditions to meet, and disadvantages when implemented just like the linear model. Most companies who employ the Spiral model are those who are working on large projects where the development team has lots of experience, data and technical expertise at their disposal.

References:

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

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

Software Process Model: Linear Models

In software development, it is essential to learn the software process models. Understanding a variety of processes will greatly help to make the best choice of a process model appropriate for the project at hand. These are:

  • Linear Models
  • Spiral Models
  • Unified Process
  • Prototyping
  • Continuous Delivery

LINEAR MODELS

Linear process models follow a pattern of phases completed one after another without repeating prior phases. In this process model, the product is designed, developed, and released without revisiting earlier phases.

The linear process models screenshot based on the Linear Models video of Coursera course
Software Processes and Agile Practices

Samples of Linear Process Models are:

Waterfall Model – each phase in this process is fed into by an approved work product from the previous phase. This phase emphasizes documenting things like requirements and architecture, but it does not allow the development team to review and improve their product. It is not adaptable to changes and not very agile, since it is not designed to address changes midway of the project. Because of this, the V-model came into existence.

The Waterfall Model screenshot based on the Linear Models video of Coursera course
Software Processes and Agile Practices

V-model – this process also features one thing to happen after another in sequential order. However, it emphasizes verification activities to ensure the implementation matches the design behaviour and design requirements. It is a V-shaped model because it divides into two branches where the left hand branch begins with the requirements that feeds into system architecture and design. Then, the shift from design to implementation is the bottom of the V. Then, once implementation is complete, the process shifts to the verification activities on the right hand branch of the V.

The V- Model screenshot based on the Linear Models video of Coursera course
Software Processes and Agile Practices

Both the Waterfall and V-model is unable to adapt to change, but the V-model allows the development team to verify each phase of the process. How about involving the client along the way to give feedback? This is where the Sawtooth model comes.

Sawtooth Model – this process model is similar to both Waterfall and V-model, but it allows client feedbacks at meaningful times to be integrated with the development. This process is easy to apply, however, it also doesn’t adapt to changes well.

The Sawtooth model screenshot based on the Linear Models video of Coursera course
Software Processes and Agile Practices

What these models have in common? Sequential phases. As mentioned in the video, these early linear process models subscribe to a manufacturing view of a software product. This is machined and assembled according to certain requirements. Once produced, the product only requires minor maintenance upkeep.

Reference:

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

Wong, K. (2020). Linear Models. [Video]. Embedded under the course study videos under the Week 2 of the Software Processes and Agile Practices Coursera Course. Taken November 19, 2020.