2. Introduction
The real challenges come after the first
release of your software product to
customers and users. Technically, this
phase is called the ‘Software
Maintenance’ phase and would span
across the most active life of a software
product.
This is a very crucial phase in the life of
your software product since most of the
real value is delivered to your customers
and / or users at this time. This is when
the software product goes through a lot
of changes to meet the changing needs of
customers, users & business.
With modern software development
approaches like Agile, we often land up
this crucial phase of software product
much earlier compared to the traditional
waterfall approach. You like it or not, the
moment your MVP gets into the hands of
real customers and users, you are in this
crucial phase of your product.
Post Shipping Challenges
Whatever the process or methods or
approaches or frameworks you used so
far for your software development is no
more sufficient for you - in fact,
sometimes it’s going to work against
you!
You may feel that your team is not really
cross functional in nature to address all
the new challenges. You may see that the
so-called ‘user story’ is just one of the
many work items your team needs to
deal with. You may experience that your
favorite ‘timeboxed’ planning is actually
working against you.
Suddenly your high performing teams
are under immense pressure & start
compromising quality and skip
commitments. Your business starts
complaining about the loss of
momentum in releasing the roadmap
items.
Some of the key challenges you are
going to face are,
➔ Varying types of work items.
➔ Varying work sizes.
➔ Constantly changing priorities.
➔ Unprepared teams.
➔ Inability to plan ahead.
Varying Types of Work Items
Post the first release, teams need to
address a larger number of work item
types. Some examples of additional work
items are,
➔ Customer / user queries.
3. ➔ Installation & migration
assistance.
➔ Configuration & data fixes.
➔ Log file analysis &
troubleshooting.
➔ Content changes.
➔ Defect triaging & fixing.
➔ Addressing performance, security
& usability issues.
➔ Adding additional customer
specific features.
➔ And many other ‘invisible’ work
items.
So, the features and user stories from the
original roadmap become a very small
part of the team's daily work. And often,
businesses are not aware of this and they
continue to believe that the full capacity
of the team is available for roadmap
development, whereas the reality is
entirely opposite.
Varying Work Sizes
The work item sizes will also vary
considerably. For example, a defect fix
may take only 2 days whereas a
performance fix may take months to
close. Most of the production queries or
data fixes can be addressed on the spot
whereas teams may have to spend a
considerable amount of time to replicate
some bugs reported by the users.
Sometimes, you may need months to
deliver a major enhancement to a
customer.
Constantly Changing Priorities
The priorities of these different work
items are also different. You can’t take
weeks or months to fix some urgent
defects, instead you need to fix and
deploy to production immediately. Some
usability changes are optional or
suggestive so you can take your own
time to deliver the same. There may be
some work items such as compliance or
security related, which the team need to
close by a specific date, otherwise need
to face some repercussions including the
financial and / or reputation loss.
Unprepared Teams
Many times, your current cross
functional team is not sufficient to
address some of these new found work
item types or their emergencies. Certain
parts of software can only be worked
with specialized groups’ support, or
certain specialized functions can only be
carried out by experts in those functions
such as security or performance testing,
writing database queries or stored
procedures.
4. And it’s quite difficult to form a small
cross functional team with all these skill
sets. So, it’s natural for you to depend on
outside services to get their work done
on time.
Inability to Plan Ahead
The demand or arrival rate of the work is
also not predictable. No customer will
wait till your next planning meeting to
consider an emergency bug fix.
Moreover, the priorities of some of these
work items keep changing, sometimes
multiple times in a day and hence any
advanced planning even for 2 weeks is
quite difficult & challenging for you.
It’s also quite difficult to maintain a
predefined rhythm for releases. Some of
the work items are so urgent that we
need to release them on demand.
Conclusion
In summary, we need to consider some
alternative approaches, which can
address our newly found requirements
such as,
➔ Ability to handle the different
work request types.
➔ Ability to handle the different
work request sizes.
➔ Ability to handle the varying
work request priorities.
➔ Ability to deliver on demand.
➔ Ability to collaborate with
multiple groups.
➔ Ability to reduce the context
switching costs.
➔ Ability to deliver value faster.
➔ Ability to handle interruptions.
If our process doesn't pay enough
attention to and address these challenges,
our customers & users become unhappy
with what we are promising and
delivering, our internal stakeholders
become frustrated & doubtful about the
potential and capability of our teams and
our once high performing team becomes
completely demotivated & directionless.
This is very obvious that either the
waterfall process or agile methods such
as Scrum or SAFe that are based on
deterministic approaches to planning,
estimation & prioritization are not
enough to address these challenges &
new requirements.
If the team continue to leverage those
inadequate frameworks, we can see the
team morale & customer satisfaction will
slowly come down due to,
➔ Missed commitments.
5. ➔ Estimation and planning are
taking too long and seem random,
error prone and just nonsensical.
➔ Urgent works arrive more quickly
than the sprint length.
➔ Pressure to break sprint
boundaries and add urgent work.
➔ Product Owners show favoritism
to one stakeholder over another.
➔ Product Owners have trouble
balancing demands from multiple
stakeholders.
➔ Stories are split over multiple
sprints.
➔ Actual customer service is very
poor with long lead times.
➔ Lack of predictability and
transparency.
This is the time to look for some
alternative approaches or methods. This
is where the KANBAN - the alternative
path to agility - can help us.
David Anderson, the creator of Kanban
Method, in his seminal book titled
“Kanban - Successful Evolutionary
Change for Your Technology
Business” (commonly known as Blue
Book) summarized recipe for success as,
➔ Focus on quality.
➔ Reduce WIP.
➔ Deliver often.
➔ Balance demand against
throughput.
➔ Prioritize.
➔ Attack sources of variability to
improve predictability.
6. KANBAN - The Alternate
Path to Agility
Kanban is a management method that
improves service delivery, catalyzes
improvements and evolves an
organization or team to be fit for
purpose.
Delivering work in a quick and efficient
way could be a challenge. The Kanban
Method suggests an approach of
managing the flow of work with an
emphasis on continuous improvement
without overburdening the development
team that focuses on productivity and
efficiency. It is a method designed to
help you optimize workflow and use
your team’s full capacity.
The Kanban Method has three parts.
1. Service Delivery Principles.
2. Change Management Principles.
3. General Practices.
Service Delivery Principles
As per service delivery principle, your
organization is a network of
interdependent services with policies that
determine its behavior.
Understand & focus on the customer’s
needs & expectations. This
understanding encourages the delivery of
outcomes that benefit the customer
instead of simply delivering outputs.
Manage the work, let workers self
organize around it. The collective
wisdom of the team yields better
outcomes than directives from a
manager.
Regularly review the network and its
policies to improve outcomes. Regular
reflection paves the way for small
changes that increase quality, reduce
overburdening and improve outcomes.
Change Management Principles
Change management principles are
designed to minimize the organizational
resistance and institutionalize a
continuous improvement mindset.
Therefore,
Start with what you do now.
Transformations are risky. Starting
where you are lowers risk, reduces
confusion & increases overall buy-in.
That means understand your current
processes as actually practiced & respect
existing roles, responsibilities and job
titles. Kanban doesn’t require a particular
setup and can be applied directly to your
7. current workflow. This makes it easy to
implement since there is no need to
change your existing process. The
benefits of Kanban are gradual and any
process improvement is adopted over
time.
Gain agreement to pursue
improvement through evolutionary
change. Instead of overreaching, make
small, evolutionary improvements as
people are ready to adopt them.
Sweeping changes can unsettle teams,
disrupt flow and damage performance.
Kanban is designed to incur minimal
resistance by encouraging continuous,
incremental and evolutionary changes.
Encourage acts of leadership at all
levels. Kanban teams should encourage
leadership and decision making between
all members. If the lowest ranked team
member has a bright idea, it should be
acknowledged and embraced. Everyone
should be fostering a mindset of
continuous improvement (Kaizen) – in
order for the team to reach optimal
performance.
By encouraging solutions from the
people closest to the work, the
organization makes the best
improvements.
General Practices
To put these principles in practice,
Kanban recommends 6 general practices.
1. Visualize (with kanban board).
2. Limit work in progress (with
kanban).
3. Manage flow.
4. Make policies explicit.
5. Implement feedback loops.
6. Improve collaboratively, evolve
experimentally using models &
the scientific methods.
Visualise
It’s important to provide individuals,
teams & managers visibility on the work,
workflows and risks associated with it.
Visualization can also engage sensory
perception and move people emotionally
and can create greater transparency and
empathy within & outside the team. A
proper visualization can make faster
decision making and enable
collaboration, better communication &
catalyze ongoing improvements.
Key benefits of visualization are,
➔ Makes that which is invisible,
visible.
➔ Ensures clear & correct
communication of info about
work items.
➔ Reduces overburdening by
visualizing & limiting WIP to the
8. capacity of the individuals that
make up the kanban system.
➔ Develops a shared understanding
of objectives, work status,
impediments & risks.
➔ Captures significant business risks
associated with work items.
➔ Facilitates timely & coherent
decision making, collaboration &
knowledge sharing.
➔ Develops trust.
➔ Reduces disruptions.
In summary, visualization brings
transparency, communication and clarity.
Limit Work in Progress (WIP)
Multitasking is the single culprit for
lower productivity and team motivation.
We need to discourage excessive and
damaging levels of multitasking to
improve the flow and quality of what we
are doing. Limiting WIP practice is
designed to relieve individuals, functions
and service delivery systems from
excessive overburdening.
Technically this practice is helping us to
implement a pull system on part or
across the workflow instead of the
traditional push system.
Key benefits of limiting WIP are,
➔ Allows individuals & teams to
focus on work value by the
customer.
➔ Makes the work flow through the
kanban system.
➔ Mitigates the effects of
unevenness in arrival rate & flow
of work.
➔ Makes bottlenecks visible.
➔ Makes visible delays due to non
instant availability of shared
resources.
➔ Amplifies the impact of blocking
issues & encourages their early /
swift resolution.
➔ Improves value delivery rate,
delivery times & quality.
➔ Improves predictability.
➔ Stimulates conversations about
problems in the process.
➔ Fosters collaboration, causing
people to work together on work
items in order to finish them &
get free capacity for the kanban
system.
➔ Facilitates achieving balance
within & between kanban
systems.
➔ Facilitates process understanding.
➔ Helps with reduction or
elimination of three core types of
waste - Muri, Mura & Muda.
That means, by limiting WIP, we can
finish things faster while increasing
quality.
9. Manage Flow
By observing and analyzing flow
efficiency, you can identify any problem
areas. The main goal of implementing
Kanban is to create a smooth workflow
by improving the lead times and
avoiding delays. You should always
strive to make your process more
efficient. Managing the flow (instead of
people) achieves fast, smooth and
predictable creation and delivery of
customer value.
Key benefits of this practice are,
➔ Affords a deep understanding of
the types of demand & how they
are processed to deliver customer
value.
➔ Identifies impediments in the
workflow & defines how to
eliminate them.
➔ Improves delivery predictability.
➔ Improves workflow efficiency.
➔ Establishes classes of service.
➔ Allows development of a
quantitative understanding of the
entire process & how to use it to
better manage capacity of kanban
systems, workflow & customer
satisfaction.
➔ Improves forecasting.
➔ Improves risk management.
➔ Improves optionality by enabling
ever later deferral of commitment.
In summary, flow encourages a constant
delivery of value to customers and users.
Make Policies Explicit
We need to establish clear rules for
managing work that allow for developing
a better understanding of the entire
process and improving it further with
consensus. When everyone is aware of
the explicit policies, each person can
suggest improvements that will improve
your performance.
Key benefits of this practice are,
➔ Establishes explicit criteria for
making decisions related to work
items & process.
➔ Establishes criteria & guidelines
for managing risks.
➔ Manages dependencies.
➔ Aligns strategy & capability.
Remember that policies that are shared
within the team and readily changeable
empower people to perform.
Feedback Loops
In order for the positive change to occur,
regular meetings are necessary to
provide essential feedback to the entire
team. The frequency of these meetings
varies, but the idea is that they are
regular, at a fixed time, and that they get
straight to the point.
10. Right feedback loops enable comparing
expected and actual outcome and use the
obtained feedback to evolve further the
process and policies.
Key benefits are,
➔ Establishes coherent management
of the entire process.
➔ Develops unity, alignment &
shared purpose.
➔ Develops short term shareholder
focus.
➔ Develops long term shareholder
focus.
It’s very important to remember that
quick feedback can promote business
agility tremendously.
Improve collaboratively, evolve
experimentally
Kanban requires constant evaluation,
analysis and improvement. When teams
have a shared understanding of the
process, they are more likely to reach a
consensus in order to evolve continually.
The Kanban Method suggests that
various models of scientific approach are
used to implement continuous,
incremental, and evolutionary changes.
Key benefits are,
➔ Learn in the process of defining
an improvement experiment -
predict the outcome - compare
actual & expected results.
➔ Understand the impact of taken
decisions.
➔ Improve risk management at all
organizational levels.
➔ Continually develop the ‘fit for
purpose’ capabilities.
In summary, use the scientific method to
bring small and continuous
improvements.
11. Getting Started with
KANBAN
To move your team from visualizing
your work to improving your process,
you’ll need to,
➔ Map your current workflow
➔ Visualize your work
➔ Focus on flow
➔ Limit your work in process
➔ Measure and improve
Systems Thinking Approach to
Introducing Kanban (or STATIK) is,
according to David Anderson, the main
approach for anyone wanting to adopt
Kanban. Its application generally occurs
in a group, involving all those taking part
in the execution of the service for which
the Kanban method is to be applied.
This approach is based on Systems
Thinking. Systems thinking, as defined
by Peter Senge in his book “The Fifth
Discipline”, is a way of analyzing
organization patterns from a broad point
of view, instead of looking at small parts
in isolation.
Peter Senge uses an elephant as a
metaphor for explaining systems
thinking. You can’t just consider one
part of the elephant if you want to learn
to handle it. Like an elephant, an
organization is a living organism and
therefore needs to be managed through
an integral approach, rather than seeing
only individual parts.
The STATIK method helps answer the
following questions.
➔ What is the purpose of this team
or functional unit?
➔ What are the services this team
/unit provides? To Whom?
➔ How is the current way of
carrying out the work?
➔ What are the sources of
dissatisfaction?
➔ What are the sources of demand?
➔ What is the current service
capacity?
➔ What are the workflows? What
kinds of services are there?
➔ How to design a Kanban system
that allows me to visualize and
control the work?
As an iterative approach, STATIK
suggests you go through the following
steps.
For each identified service,
1. Understand what makes the
business fit for purpose
2. Understand sources of
dissatisfaction with the current
system.
3. Analyze the source and nature of
demand
4. Analyze current delivery
capability
12. 5. Model the service delivery
workflow
6. Discover the classes of service
7. Design the Kanban system
8. Socialize design & negotiate
implementation
STATIK is applicable to just one service.
When more than one service has been set
up, Kanban practices & cadences are
applied to balance demand & flow across
multiple services, and continually
improve.
The ordering of the steps may vary in
practice & it is normal to revisit steps in
the pursuit of further improvement.
Kanban systems don’t model the
organization chart, they model the flow
of work to customers.
Understand what makes the
business fit for purpose
Try to understand and define the criteria
that ensure customer satisfaction with the
service delivery. These are usually
related to, but not limited to lead time,
quality, predictability and safety /
regulatory concerns. These criteria are
known as the fitness criteria because
they determine how the customer
evaluates whether the service delivery is
acceptable, or “fit for purpose.”
Once the fitness criteria is in place,
explore & establish expectation levels
for each criteria. These are known as
fitness criteria thresholds. They
represent the “good enough” or the point
where performance is satisfactory.
These metrics should become KPI & be
used to establish SLE or inform
negotiations on SLA where appropriate.
A sample fitness criteria we identified
for an internal team is shown below.
Understand sources of
dissatisfaction with the current
system
As the next step, we need to identify the
sources of dissatisfaction with the
current system from the perspectives of
both internal & external stakeholders. In
most of the time, the sources of
dissatisfaction from both sides can be
matched and if we fix one, the other also
gets fixed.
For example, a customer might complain
about unpredictable, late delivery, while
internally, teams may complain of being
13. constantly interrupted and disrupted with
unplanned or additional requests. If we
can address the sources of unplanned,
disruptive demand, we can eliminate the
interruptions and the service delivery
becomes more predictable.
Sources of dissatisfaction are a great
input for the Kanban system design. We
will try to design a Kanban System that
can eliminate as many problems as
possible.
A sample source of dissatisfactions we
identified for an internal Level 2 support
team is shown below.
Analyze the source and nature of
demand
Beyond user stories, most teams are
working on many invisible demands. In
order to design a suitable kanban system,
we need to have a holistic understanding
of the nature of the demand. After all,
one of the key reasons for implementing
Kanban is to balance the demand against
internal capacity.
➔ Who are the customers?
➔ What do they ask for?
➔ What is the arrival rate and
pattern of arrival requests?
➔ What are their expectations?
As the first step, we need to identify all
work items that the team is working on.
Once the work items are identified, we
need to understand the arrival rate &
arrival pattern of each of those work
items.
Understanding the volume of demand,
the nature of arrival and the expectations
or business risks associated with types of
request will enable us to design an
elaborate kanban system with capacity
allocation for different types and varying
classes of services to cope with demand
carrying specific risk profiles.
In mature and advanced
implementations, the demand is further
categorized as,
➔ Value vs Failure demand.
➔ Deliverable vs Information
discovery demand.
➔ Refutable vs Irrefutable demand.
➔ Planned vs Unplanned demand.
This additional analysis informs the
kanban system design but will also
inform further improvement actions that
may be taken later.
For an internal team, we recently
identified below work items as part of an
14. informal STATIK exercise. As you can
see, many stakeholders are not aware of
the non user story related work items that
the team is taken care of and often they
misunderstood the team for reduced
capacity for user story development
especially after every release.
So the key questions to be answered at
this step are,
➔ How work arrives?
➔ How frequently?
➔ From whom?
➔ Of what types?
➔ In what size?
➔ Etc..
Analyze current delivery
capability
Demand & capability are the two sides
of the same coin. One of the key
purposes of implementing a Kanban
System is to balance the demand against
the available capability.
Analyzing capability involves studying
historical data for service delivery such
as lead time, quality (both functional and
nonfunctional), predictability,
conformance with regulatory
requirements or standards.
It is common for a historical Cumulative
Flow Diagram (CFD) to be prepared as
part of capability analysis and some
calculation of flow efficiency may be
attempted if working time (effort
expended) data is also available in
addition to duration (elapsed calendar
time).
Key questions to be explored at step are,
➔ What’s our current throughput or
delivery rate?
➔ What’s our current average lead
time and how the distribution
looks like?
➔ What’s our current flow
efficiency?
➔ Where are we spending most of
our time?
➔ What’s our capacity allocation
across different work items?
➔ What’s our defect distribution
across different work items?
➔ How does the work leave the
team? Continuous? In batches?
➔ How often does the work leave
the system? Daily? Weekly?
Monthly? Quarterly? Yearly?
➔ Etc…
Model the service delivery
workflow
Workflow modelling means mapping the
series or sequences of dominant steps to
discover the new knowledge for a given
work item type. Since these knowledge
15. discovery steps are different for different
work item types, we need to perform the
workflow modelling for each work item
separately.
A sample end to end workflow for a
service is shown below. There are three
different teams involved in this service /
workflow - Product Discovery, Product
Delivery and Release Management team.
Discover the classes of service
A class of service is a set of policies
which describe how something should be
treated.
Typically with kanban systems, the
classes of service,
➔ Describe the queuing discipline or
priority of tickets.
➔ Describe policy that affects
workflow such as whether an item
should receive treatment from a
specialist or be tested to a specific
level of quality.
➔ Provide info regarding scheduling
or whether an item is allowed to
exceed the WIP limit or not.
The below questions are helpful for
discovering the classes of services.
➔ How do you decide which items
are more urgent than others?
➔ Do you have explicit SLA in
place already?
➔ Do you have any other explicit
policies that determine priorities
or sequencing?
➔ Do the ‘sources of dissatisfaction’
imply different classes of service?
➔ Do items with different business
risk profiles need different
policies?
➔ Do you need a class of service to
overcome emotional objections to
the kanban systems?
➔ Do you want to allocate specific
capacity for each class of service?
Kanban recommends 4 types of classes
of services.
1. Expedite → For critical items,
which demands urgent fix and
release.
2. Fixed date → Items that need to
be delivered on or before a
specific date.
3. Standard → For all other items.
4. Intangible → Long term
initiatives to improve work
(automation, use of new tools,
platform migrations, etc.).
16. Design the Kanban system
A Kanban system consists of four core
elements.
1. Kanban system with WIP limits.
2. Ticket design.
3. Board design.
4. Kanban cadences.
To design the kanban system, we need
the workflow model for each type of
work, the states of work based on
dominant activities for discovering new
knowledge and classes of service.
We will also need to define ‘kanban’ (or
WIP) limits for each state and possibly
allocations of kanban across work item
types and/or classes of service.
To design the ticket, we will need to
understand what information is required
at each state in the workflow, in order to
make a selection decision to pull an item
to the next activity state.
Typically, we need,
➔ Work item type.
➔ Class of service.
➔ Start date.
➔ Due date (if applicable).
➔ Specialist workflow or processing
requirements.
To design the board, we need to
understand the workflow for each type of
work.
➔ Make a decision to have a single
board for all work types and
classes of service, or to have two
or more boards.
➔ Decide how to allocate columns –
usually the states in the workflow.
➔ Decide how to allocate rows –
usually work types or collections
of work types.
➔ Decide how to allocate the color
of tickets – usually for class of
service.
There are a total of 7 Kanban Cadences
meetings in the Kanban Method. It is
common for new implementations to
start with a subset of these. It is also
common to repurpose some of the
existing meetings to suit for the Kanban
system.
Key decisions at stage include answering
some of the questions such as,
➔ Which of the standard Kanban
cadences you will be
implementing.
➔ What’s the frequency of those
cadences?.
➔ Which existing meetings will be
repurposed?
Also, select the facilitator, frequency &
duration of the meeting, the attendees,
17. what information each attendee should
bring, which decisions will be made in
those meetings, which metrics & reports
are needed for the meeting.
Standard list of Kanban Cadences are
shown below.
A sample Kanban Board designed for an
internal team is shown below for
reference.
And we can combine multiple Kanban
Boards together to establish end to end
value flow. There are three separate
Kanban boards in the below end to end
flow.
1. A discovery kanban board, often
maintained by the product
discovery team.
2. Multiple delivery kanban boards
maintained by different delivery
teams.
3. A release kanban board leveraged
by the release team.
Socialize design & negotiate
implementation
Finally, you have to socialize the design
and commence negotiations regarding
implementation.
Kanban recommends collaborative
workshops and boards as a means of
achieving this objective. In theory, all
stakeholders can take a slice of
ownership and pride over the system and
its design. This will make them more
accountable for their actions once we
start using the Kanban System.
Of course, getting a buy-in from
leadership carries a lot of weight and
remains paramount to smooth
implementation. It’s a good starting
point, but you should take things a step
further too.
18. However, it isn’t realistic that every
affected stakeholder can play a role in
the STATIK workshop. It is necessary to
circulate the design output from the
workshop in order to get a wider group
bought in to the design.
Walk the stakeholders through how the
new system will work, explaining it from
their point of view. Listen to their
feedback. You may get objections which
will require adjustments to classes of
service, capacity allocations, board
design, or reporting requirements. As
much as possible, promise to take these
changes on board.
Rework your design to accommodate
what you have learned from the
socializing. Revisit some stakeholders to
gain their agreement that you have
accommodated their concerns
adequately.
Once you have done this, you are ready
to hold a kick off meeting to launch the
Kanban initiative and the introduction of
the changes. Invite all the stakeholders.
Again start the meeting with the position
of humility.
Summary
Kanban provides a mechanism to
manage the dynamics of frequent change
in work that needs to be accomplished at
a fast pace. It provides unparalleled
visibility in terms of bottlenecks and
work progress that impede the smooth
flow of the work.
Many products post their first release
face different changes that can’t be
addressed by methods or framework
such as Scrum and this is where, I think,
the future Kanban lies. In fact, Kanban
can be easily scaled up to handle a large
number of inflows of work and to
prioritize and deliver them without doing
even a small reorganization of your
current team.
As David Anderson pointed out in the
Enterprise Agility Everywhere 2020
conference, Kanban can provide a
refreshing approach to managing our
business. Kanban can refresh the parts of
your business that other methods or
frameworks can’t reach.
Kanban can successfully refresh,
1. Our employee engagement.
2. Our product & service delivery.
3. Our customer satisfaction.
4. Our economic performance.
5. Our organizational culture.
6. Our business resilience.
Kanban deliver such a refreshing change
through,
19. ➔ Visualization.
➔ Evolutionary change.
➔ A sense of purpose.
➔ Explicit values.
➔ Relief from overburdening.
➔ Organizational maturity.
With the help of the Kanban Maturity
Model and under the guidance of a
competent Kanban Professional, it’s easy
for any organization, business or team to
take the full advantage of Kanban in a
short span of time frame.
Rajesh Viswanathan is a Principal Agile Coach
with over 20 years of experience in product
discovery, product delivery and product support
for large global B2C / B2B products with fortune
100 customers. He is an accredited Kanban
Coaching Professional (KCP) from Kanban
University. He is also an experienced and
certified Design Sprint Facilitator.