First ever PMI-ACP preparation course in Mexico

I was about to blog about this when I received email from PMI-SFBAC so I am directing you to their news on this instead of wasting time writing about the same.

http://www.pmi-sfbac.org/associations/4587/newsletter/?nbr=761

Handling ticket issues with Kanban

David J Anderson's book on Kanban shows us that a way to handle ticket issues is by attaching a color tag to a ticket to make it visible. An issue is ticket-related event that becomes an impediment to its value flow, such as a defect, insufficient definition, unresolved dependency, etc.

What I encounter often is people have natural tendency to move the ticket to where the dependency lyes. Although Kanban does not stop us from doing so, this might not be the best of actions. If, for example, in the images here the dependency is on Patient Checkin it might be tempting to move the ticket to the Checkin column.

Doing this brings some difficulties. 

• We lose track of where the issue occurred (Treatment)
• Quantification becomes tricky. Cycle time measurement for the ticket becomes unreliable. It is better to leave the ticket under Treatment so that we know the issue occurred during Treatment and the red ticked affixed to the yellow ticked indicate the dependency with Check-in. This is better because we don't lose track of where things are at and quantification remains unaffected
• WIP handling becomes very tricky. What would happen if Checkin is at maximum capacity and we tried to move the ticket from Treatment to Checkin? We either violate WIP or keep the ticked under Treatment on some sort of stale state until Checkin has capacity (ugly)
• Root cause analysis becomes harder also. It is better to keep log of the activities under Treatment, where the issue actually occurred to make root cause analysis easier, otherwise it becomes a bit harder to understand the space-time-event relationship

There is another solution by Duane Bradbury, Alex Hui and Taimur  Mohammad, which I like. I'm posting this with permission (thanks Duane!).

This is how we treat defects and the parent standard card...

1- card is in progress in QA,  

2) when a defect is discovered it is created in the Fix QA cell...

3) if QA is unable to continue the Card is moved down to Fix QA as well.  (if not the card remains in progress until they are unable to continue,   maybe the defect will be fixed before they are stuck)

4) the defect lives in this location until it is addressed/assigned, basically 

if someone is working on it, then it goes to where that is.   for this example it is the developer looking into it.   so the defect moves to the Build in progress...

so at this stage it is known that these cards are related (due to naming conventions) and it also shows the status.

5) once the defect is addressed and resolved it is moved into completed.  flagging the QA to pick up the defect and see if it resolved.  retesting

once the QA is able to pick it up both cards move into in progress QA.   showing retest is happing.   

Although this solution requires extra real state for the Fix swim lane it makes visibility and tracking much easier. 

—Masa K Maeda

Visualizing cycles in Kanban

At a training session in Kitchener Waterloo, Canada. I was asked how to visualize and handle cycles in a Kanban board. The images below show a way to do it as a physical board and on an electronic board. Tickets within a cycle move from left to right, from one column to the next until and cycle back as many times as necessary and once done they move to the Done column at the the end of the cycle. Note that columns inside the cycle can contain their own Done columns.

For quantification purposes it is better to do so for the entire cycle only and not for columns inside the cycle. This is because quantification inside the cycle becomes tricky an might not necessarily be of much use (if anything, some might need to quantify the number of cycles but even that may vary from one task to another). If you are using an electronic tool make sure to get your settings for quantification adjusted accordingly.

A case of advantage on maturing the Kanban board

Organizations new to Kanban that have no experience with Agile usually find it easier to design 
their boards than those with Agile background because Kanban recommends the board to reflect 
the actual process rather than an abstraction. Compare for example Board 1a, quite common in 
agile practices, with Board 1b. 

Board 1a  

Board 1b 

This is a good start. As we all know, a project’s behavior changes over time. This means the 
Kanban board should keep up with those changes, but unfortunately many Kanban 
organizations don’t go about keeping the board up to date and that has undesirable 
consequences such as fake visualization and forcing the real process to adjust to he board 
process. Both of them affect quality and value delivery. Oh but there’s more to it. We miss big 
time on the identification of opportunities for improvement.

 I will illustrate the benefits of keeping the board up to date through a real case. One of my 
customers is a small Telecom business that provides technical services to some of the biggest 
Telecoms in the world. The very first coaching session I gave them right after finishing Kanban 
training consisted on helping them create their first functional Kanban board. As a coach I didn’t 
build the board for them, of course, but rather had them create it providing guidance as I saw it 
necessary. During that session I realized that the last portion of their process was convoluted so 
I decided to dig into process details with them rather than focusing on creating the board. 
Throughout the discussion the team agreed that part of the process was suboptimal and I made 
a recommendation which we agreed upon and so the first Kanban board was created reflecting 
the actual process but already suggesting a small but important change at the end. The change 
had to do with the customer verification phase.

I visited them to do a second round of coaching and was very pleased to see they had modified 
the board to be a show on Board 2a. I asked to a team member to explain the board to me and 
he did a pretty good job; and at the same time I noticed some hesitation explaining the sub-
column labeled “Pending”. I decided the to dig in to it. Discussing this with the team it became 
clear that it had to do with dependencies they had with their subcontracted providers as well as 
with internal dependencies, and their cycle time was being affected by it. 

Board 2a  

I then suggested to them to further visualize “Pending”. The result was Board 2b. We added a new
column to visualize de 3 subcontracted providers and also kept de original sub-column which was
to be used only for internal dependencies. 

Board 2b  

This change allowed to better understand the behavior of each subcontractor a well as to see how
the customer was taking care of its own dependencies. The subcontractors behavior was quantified
(the rest of the process had been quantified before from the beginning) and that allowed to show
them how their response time affected final delivery. This motivated the subcontractors to improve,
one of them started adopting Kanban also, and that resulted in significant improvement on delivery
to customer. This also motivated a behavioral change on the team itself to take care of their internal
dependencies more efficiently. The rend result was an increase of on-time delivery to customer from
86% to 99%.

Additional benefits surfaced from this such as the obtention of more contracts without having to 
increase staff.

--Masa K Maeda

First ever PMI-ACP Preparation course in Chile

The first ever PMI-ACP preparation course in Chile took place last June 25-27, 2012 in the city of Santiago with 20 attendees from 8 companies including Microsoft and Motorola. I gave this course with the fabulos logistics asistance of Gestionarte, a management trainig company in Chile. Attendees had a lot of fun! Some of the comments we got at the end of the course are: "Thanks for going above and beyond the course curricula, we learned much more" and "This is the best course I have attended in my entire life!"

First ever Accredited Kanban Training in Chile

I had the privilege and honor to give the first ever Accredited Kanban Training in Chile on June 28-29, 2012. We had an amazing group of 14 people from companies such as Telefónica, Zweicom, and other. The training was very upbeat, with high level of participation from everybody. Masa pointed out this is the course with the broader variety of talents since for the first time one of the participants was an artist (painter and sculptor) with no tecnical or scientific background and explaining Kanban wihtin that context was a fun and challenging task.

Keynote and workshop in Tlaxcala Mexico (old event - April 2011)

I ran into a blog entry about a keynote and workshop I gave at a conference in Tlaxcala Mexico back in April 2011.

          http://goo.gl/sfjqZ

Note: the blog is in Spanish