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.

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:

Eliminating waste
Amplifying learning
Deciding as late as possible
Delivering as fast as possible
Empowering the team
Building quality in
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.

Foundational Concepts of SPM

I am knowing more about software product management through the specialization Coursera course I am taking: Software Product Management taught by instructors from University of Alberta.

Previously, my notes covered about what is software product management (SPM) and Agile development. Today, I will be sharing my notes for the foundational concepts I learned:

In SPM, there are 4 core topics an SPM professional should take into heart:

Process
Requirements
Planning
Monitoring

PROCESS

In SPM, process is a good foundation to apply the Agile development principle. Basically, a process organizes the work of people into distinct phases or stages to develop a software product.

For example, in preparing a pizza, the phases include planning, preparation, assembly and cooking. In each phase, work tasks can be assigned accordingly with a timeframe so the one who prepares the pizza will easily deliver and the customer, who is waiting for their order, will have an idea of what is in their pizza and how long they will have to wait for it. Similar with SPM, a process organizes the work tasks into distinct phases so a software product manager can easily manage the whole project.

In SPM, the phases of software development process are:

Specification – This is the part where the client and the software product manager drills down the client needs into the product specification, and what the product will do.
Design and Implementation – this is where the developers and designers will actually check and put into codes the product specification.
Verification and Validation – after all he coding and developing, this is where we make sure the client is satisfied with the initial product (hence, validated) and the developers check if each code is tested and the product is done right (hence, verified). This is achieved by rounds of client inputs and demo, and testing on the part of development team.

Now, let’s say when you have an idea for the product, you went straight to developing instead of first writing down and planning how you will work it out, what items to include, how you will test. What do you think will happen? It’s like sitting at a keyboard and expecting a great novel to come out while you type. As a writer, I know it’s not gonna happen.

In SPM, this type of just getting it out there and doing it is called Ad hoc development. Ad hoc development is working on a product without applying all the agile development core values and principles; hence, wasting time, money and resources.

Having a well-defined software process enables everyone on the team to know what to expect and what responsibilities each one have; just like in any other project.

REQUIREMENTS

Specifying the requirements for a product allows the development team to be focused and efficient. This is making sure that the development team will be able to create the features according not only to the needs of the client, but also to the user. As what Bradley Poulette mentioned in his video for requirements, avoiding confusion is incredibly important in software development. It starts with knowing how to get clear requirements from clients, and refining these further to detect any potential errors in the product before it is being built.

PLANNING

In planning, it involves using processes and requirements to start organizing the tasks and schedules. This is where the software product manager and development team identifies who should do particular tasks and estimates how long each work will take. Estimates make sure that the team will also not over commit to the client.

Also, another part of planning is risk management. Examples of risks encountered are missing deadline/budget, software release bugs, development of team responsibilities, unforeseen events like team member quits, or the technology crashes. In all these risks, proper planning is ensuring these risks are managed and solutions created ahead of time.

As Alan Lakein says, “Planning is bringing the future into the present so that you can do something about it now.” True enough, effective planning makes any project successful.

MONITORING

Lastly, monitoring is important in managing software product development. While your development team is working on their own tasks, as a software product manager, you are to ensure that the development is on track, the budget is met, and the team’s environment is productive and efficient. Let’s say the development is ongoing, then no monitoring is being done. The next thing you know, the deadline is near and the team is cramming to make things work, only to sacrifice the quality of the product. So, definitely, we don’t want that to happen.

In monitoring, the development team and the product manager works together to monitor their progress in the project by each member being transparent with their progress, and each one of the team knows the project status. So in monitoring the progress of the each member in the team, it helps the whole project adapt to changes, meet deadlines and deliver the product required.

So, overall, understanding and applying these 4 foundational concepts in software product management will eventually ensure that the development of the product is on the right track.

Reference:

University of Alberta (2020). Introduction to Software Product Management. Coursera Course under the Software Product Management Specialization. Taken November 2020.

Patzelt, M. (2020). Why Process. [Video]. Embedded under the Week 2 course study of Introduction to Sofware Product Management. Taken November 2020.

Patzelt, M. (2020). Why Requirements. [Video]. Embedded under the Week 2 course study of Introduction to Sofware Product Management. Taken November 2020.

Patzelt, M. (2020). Why Planning. [Video]. Embedded under the Week 2 course study of Introduction to Sofware Product Management. Taken November 2020.

Patzelt, M. (2020). Why Monitoring. [Video]. Embedded under the Week 2 course study of Introduction to Sofware Product Management. Taken November 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 www.agilemanifesto.org, with infographics designed by the University of Alberta for the Coursera Course: Introduction to Software Product Management: