KanBan - An introduction

Note: Refer Project management main page here

Kanban is way for teams and organizations to visualize their work and identify and eliminate bottlenecks.
Kanban is a method to gradually improve (any business function can benefit from applying Kanban).

In Japanese, the word “Kan” means "visual" and "ban" means "card", so Kanban refers to visual cards. Kanban is a concept related to lean and just-in-time (JIT) production.

Kanban was originally invented as a part of the famous Toyota Production System. It is associated with the design of pull systems and the concept of delivering just-in-time good

KanBan follows a workflow. In simplest terms, it can be a big board with cards placed for each hase.
There are numbers at the top of each phase and these are the limits.
Limiting the amount of work-in-progress (WIP) reveals bottlenecks dynamically so that one can address them before they get out of hand.

Read below for practical explanation:

The board below shows a process where there is a workflow to be followed:

1. Requirement phase (limit of 5)
2. Design Phase (limit of 3)
3. Development Phase (limit of 4)
4. Testing Phase (limit of 3)
5. Release (limit of 5)

One can see that the process cannot progress until the testers have finished a task.
This dynamically reveals the bottleneck (in this case its the testing phase).

 Once the testers have finished a task, the task is moved from "Testing" to "Release" and the workflow can now move ahead.

As the workflow moves ahead, its helps to dynamically track the bottleneck. It may not be Testing all the time. Each time (based on various factors like resources, requirement skill etc) a new phase could become a bottleneck.

 If a bug is encountered in the Testing phase, a new requirement is created for the same.

Do let me know your views.
Stay tuned for more Agile based articles.

Project management

This page lists all the articles in this blog which are related to project management.
As more articles are published, we will update this page accordingly.

• Project and Project management (Introduction)
• Quality management
• Seven tools of Quality management 
• Benefits of being agile for an organization
• Basics of agile methodology
• Agile principles and values
• Introduction to Scrum
• Introduction to Kanban

Agile - Principles and values

One of the most important things to remember is that AGILE is NOT
- A set of tools
- Process
- Methodology

AGILE is a set of values.

The Agile Manifesto as per wikipedia reads, in its entirety, as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over Processes and tools
• Working software over Comprehensive documentation
• Customer collaboration over Contract negotiation
• Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.
As we had mentioned in our previous agile article, continuous feedback is very important.
Point 1 above is on similar lines where continuous feedback is more important when we mentioned "individuals and interactions".

Working software will definitely get more value over documentation, but it does not imply that documentation is not at all needed.

With time a customers needs can change. Even due to marketing dynamics, needs can change. Hence, customer collaboration and continuous checks on delivery will help to deliver a model which the customer can appreciate.

As mentioned, market dynamics and conditions may make the customer change his requirements. Incremental reviews and phase wise delivery and continuous feedback and collaboration will help us deliver a product close to customer's needs (at that point in time).

The Agile Manifesto, as per wikipedia, is based on twelve principles:

• Customer satisfaction by rapid delivery of useful software

• Work closely with the customer and provide timely incremental delivery of the product
• Incremental reviews for customer feedback
• Capture acceptance criteria on each discussion
• Prioritize the pending requirements
• Conduct surveys to find the satisfaction level of the customers

• Welcome changing requirements, even late in development

• It is widely accepted that customer needs can change with time due to market dynamics
• One needs to embrace this change to provide value to the customer
• Evolve a process that accepts these changes
• Changes need to be prioritized with existing requirements

• Working software is delivered frequently (weeks rather than months)

• Frequent incremental delivery of software.
• These are sprint reviews (may be in a couple of weeks and not months).
• Automated, performance and load testing plays an important part in testing such small delivery cycles continuously.

• Close, daily cooperation between business people and developers

• In non-agile models, business and development teams rarely interact. This could lead to a delivery of a product that may not adhere to the customers need at that point in time.
• There should be frequent interaction between business and development teams.
• Development team benefits from knowing the business perspective (about the function of the software)
• Business teams gets insight into development details that they may not have an idea about when they conceive the product needs.

• Projects are built around motivated individuals, who should be trusted

• Motivated employees need to be encouraged and involved in the product.
• Employees feel empowered and result in higher output and better product

• Face-to-face conversation is the best form of communication (co-location)

• Lot has already been mentioned about communication, hence not delving much into this point.

• Working software is the principal measure of progress

• Self explanatory - a working software is a measure of progress.
• In waterfall, there is no working software at any point in time (in the schedule) except at the end. Thus, from customers perspective, there has been no progress to see.
• For every incremental release, there should be a working demo which should go through automated set of testing.
• Customer feedback is gathered at the end of the demo and any new changes need to be prioritized and embedded for the next subsequent releases.

• Sustainable development, able to maintain a constant pace

• Pretty much self explanatory, constant pace need to be maintained.
• However, need to ensure that members of teams do not work crazy hours/weekends (maintain 40 hours a week)

• Continuous attention to technical excellence and good design

• I guess this is a no brainer. Team members need to have the the technical expertise to deliver a quality product.
• There should also be a focus to continuously learn and improve upon coding standards, design, integration and testing.

• Simplicity—the art of maximizing the amount of work not done—is essential

• Reduce non value added work of team members.
• Simplify process of deployment or remove extra features etc

• Self-organizing teams

• As the product evolves, there is a need to change the architecture, requirements, design etc. Team members must be involved in decision making leading to greater ownership and responsibility.
• This is not easy and requires a lot of team work and an open culture that promotes team based rewards etc

• Regular adaptation to changing circumstances

• Periodically, there should be an introspection on how to become more effective and be able to adapt to changing demands and requirements.
• Self organizing teams are the key to real improvement.
• There should be a commitment to adapt and improve with every iteration over a period of time.

Benefits of "Being Agile" for an organization

One of the biggest benefits of "Being Agile" is that it helps you increase your revenue.
Read on to find out how.

Customers needs change with time. Thus, it is important to have the customer engaged throughout the lifetime of the project.

If the requirements are fixed at the start of the project, and the project is finished within the budget and schedule, but it does not deliver what the customer wants (at that point in time), we could lose the customer or need to incorporate the new changes requiring a change in budget/time.

Agile helps in building customer value and empowering the employees.
Thus we end up getting a satisfied (and loyal) customer and happier employees.
Both of the above lead to successful projects which lead to better revenues.

Still not convinced?

What are the most common problems that we see in a software development project:

• Requirements may not be crystal clear
• Requirements can change with market conditions
• Schedules become tight since the initial information (on which the schedules are based) was not enough
• Too many processes
• Testing is at the fag end since schedules are tight

If you also face any of the above issues, Agile will help you out. Are you sure? Yes.

"Being Agile" will help to:

• Enhance customer value (there should be continuous customer engagement to ensure we align and adapt with the changing needs of the customer)
• Can help to manage change and improve project visibility
• Can help to improve end product quality
• Improve employee productivity
•   Provide a work environment where they feel ownership of the work and can make their own decisions (This improves morale and productivity)

Customer engagement:

Key focus of Agile is to deliver customer value.
Value is the benefit a customer will get from your product or the functionality if you align with their needs.

Customer value = Customer needs + On Time delivery + Meeting budget costs

As mentioned above, there should be continuous customer engagement to ensure we align and adapt with the changing needs of the customer.
Needs of a customer change and so do market conditions.

Traditional waterfall methods take up a fixed set of requirements up front as a phase.
The longer the time of phasedelivery (from requirement gathering), the  higher is the risk of delivering something which customer may not want/need (due to changing requirements and/or market conditions).

In Agile, there is continuous customer engagement so that requirements are continuously validated during each iteration review (Sprint review).
Due to continuous feedback loop, there should be a narro gap in what was delivered and what the customer needs at that time.
The narrower the gap, the more happy the customer, the more customer loyalty and revenue for an organization.

Employee Engagement

This is a very important aspect for "Being Agile". How? Read on.

Employees are an organizations critical assets. If the employees are disengaged, the productivity suffers. However, when they are engaged, they bring motivation, innovative ideas, go the extra mile.

Levels of employee engagement/empowerment

1. Encourage employees to play a more active role in their work
2. Ask employees to become more involved in improving the ways things are done
3. Enable employees to make better and bigger decisions

Thus we work on the three aspects -Encourage, Involve and Enable.

Agile teams are self-organizing. There is a common goal and work is interdependent. Collaboration is the best way to achieve the goal. Employees increase their share of ownership (accountability and responsibility).

Companies gain from such strong employee commitment and performance.

The below picture should help to make a point to the above theory

There will be more articles on "Being Agile". Have fun!!!

Scrum - An introduction

Related post: Basics of Agile methodology

Scrum is an iterative project management methodology that is most commonly used for Agile software development project.

Scrum provides a framework for business areas to identify and prioritize required work.

Sprint
A sprint (or iteration) is the basic unit of development in Scrum.
Sprint is restricted to a specific duration (typically 2 to 4 week iteration) to deliver the above identified requirements.

Resources needed in Scrum:

Product Owner:
Product owner represents the business and is responsible for providing high level requirements.

Scrum Master:
Scrum master facilitates the teams work and ensures appropriate practices are being followed.

Scrum Team:
The team working on the requirements.

Sprint planning meetings are held at the beginning of each Sprint.
Product owner, Scrum master and team review the highest priority items to be implemented.

Sprint review meetings are held at the end of each Sprint.
This includes:

• Demonstration of work done
• Review of next steps for continuous improvement

Backlog refinement
Backlog refinement is the ongoing process of reviewing product backlog items.
This is the list of work the Development Team must address during the next sprint.

Scrum of Scrums:
Allows clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
One member from each team is designated to meet other designated members (from other teams).
This daily meeting is called the Scrum of Scrums.
The designated members are known as Ambassadors.

Basics of Agile methodology

Related post: Scrum - an introduction


Agile Software Development

Wikipedia meaning:
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Why Agile?
It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight interactions throughout the development cycle.

Agile methods break tasks into small iterations (that typically last from one to four weeks).
Each iteration involves  planning, requirements analysis, design, coding, unit testing, and acceptance testing.
When one iteration completes, demo is shown to the stakeholders.
This minimizes overall risk and allows the project to adapt to changes quickly.


Waterfall method is very sequential. All steps are performed sequentially

• Analyses of Business requirements
• Design
• Implementation
• Testing

Any issue would imply going back to the drawing board and starting from Step 1.
This adds to the risk!!!

Agile mitigates this risk since evaluation happens after end of every cycle.
Agile methods benefit constantly changing requirements.