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.