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

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.

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.