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:

Ramping up production at the bottleneck
- by adding resources to speed up production
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.

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:

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.
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.
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.
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.

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:

All work products of a software project should be created at the same time.
All the quadrants in the model must be addressed, and there’s no skipping steps.
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.
The software product manager should focus a lot on making sure that each decision is based on risk data.
Each iteration of the Spiral should result in a tangible work product.
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.

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.