<<<<<<<<< Lean Gelateria | Part 6
This is the continuation of my
previous post – ‘
Daniel Brown and Mango’. I suggest that you read it to
understand the first part of Dan’s story.
Do you remember? The first 2 hours of demo after the fourth
iteration resulted in a list of 50 items – defects, minor changes, new features,
etc. That was the first demo with Alicia
and three customer support managers! In
a way, it is good that Dan proposed a one-week acceptance testing after feature
completion. However, after a week of
acceptance testing Dan’s list had more than 275 items! Alicia was not happy! Tom, Dan’s boss, was shocked! All this resulted in an escalation!
Dan’s team was distressed.
Dan’s first priority was to resolve
all issues in this project and deliver the application. The first thing he wanted to do was to have
an open discussion with Alicia.
Coincidentally, Alicia initiated
a 1-1 meeting with Dan! She wanted to
understand all options in front of them to arrive at a win-win solution. They decided to meet in the neighborhood
gelateria. They chose the flavor of the day – ‘Mint and
Choco Chips’ gelato.
This meeting helped them share
their views and settle down on what to do next.
They wanted to put together a joint response and formed a governance
team of 3 - Alicia, Dan and Tom.
Joint Response: Tom, Dan, and Alicia had their first joint response
meeting to discuss the situation. The question in front of them was about
prioritizing and closing all items in a timely manner in such a way that they:
- Address
high priority items first and move on
- Optimize
by grouping related items
- Test
adequately to avoid failure
- Understand
daily progress and make course correction
- Maximize
the number of items closed per week through weekly analysis
Visualizing the Workflow - In his
discussion with Tom, Dan stressed on the need to create a visualized workflow using
a white board in a common room or work area. Dan shared his experience on how this
approach is more effective than emails and outdated tools. Tom agreed.
The next day,
Dan came in early, took a hard copy of prioritized work items, and created a
visual board in the meeting room. His team members helped him with their ideas.
They created about 20 to 30 rows on the board and divided each row into
multiple columns. Each column corresponded to the standard work flow – analyze,
code, test, verify, build, user acceptance, done. Each row represented a work
item with a work item identification number, short description, and other such
attributes.
The Pull Factor: From that day Dan and his team would begin their work day with a crisp meeting in front of
the white board. They also ended their work days by reviewing the items on the
white board and discussing ways to improve throughput and quality in future.
During the first few days, Dan was orchestrating the team on task assignment.
Gradually his team started not only pulling work items, but also logically
grouping work items in order to optimize the time spent in coding and testing.
Limiting Work in Progress: Based on his
experience, Dan believed that mindless context-switching is a waste of time.
This happens as a result of keeping many items open, switching back and forth,
and losing focus. He coached his team to complete as many tasks on hand as
possible before moving on to the next work item. He also shared with them the
ill effects of keeping several work-in-progress items. His team members grasped
the truth behind his suggestions.
Collaborative Learning: During these
tough weeks, every daily meeting or weekly retrospective was a learning
experience. Team members shared debugging techniques, domain-specific issues,
etc. with the rest of the team to enrich their knowledge and prevent similar
issues. Even during the first week they found ways to minimize the number of
defects by discussing and implementing simple techniques to improve quality in
each step of the workflow.
The Outcome: Eventually, Dan’s team
became faster and smarter. Dan could see an increasing trend in the completion
of work items. Seeing these positive signs, Alicia regained her trust. Within four
weeks, the list of pending items had shrunk to 20.
By the end of
the fifth week, they only had ten low priority issues on hand. With a schedule
overrun of about 6 weeks, Alicia certified the application for user training
and implementation.
Reflection and Recognition: A week
after the initiation of user training, Tom and Alicia sponsored a dinner for
Dan and his team. On the dinner day, Dan convened a 30-minute retrospective
with his team. Alicia, Dan, and his team discussed several aspects of the
project including what went well, lessons learned, and areas of improvement. Everyone
agreed that as soon as they came across innumerable changes and new work items
they worked together to find a new approach and it helped them take charge of
the situation. The key factors that enabled them deliver results were:
- Visualizing Workflow
- Limiting Work-in-Progress and Minimizing
Context-Switching
- Measuring and Managing Flow
- Nurturing an Open Environment and Making
Processes and Policies Explicit
- Identifying Improvement Opportunities
Both Alicia
and Dan agreed that they needed to consider demos to end users and
retrospectives at the end of iterations in their projects in order to minimize
the spurt of changes and ideas at project completion.
Kanban Know-how: Years after this incident Dan reads an article titled
‘Introduction to Kanban” and later attends a Kanban workshop. He is able to relate
these to his project experience – he identifies many similarities and some
improvement ideas. He feels proud of himself and his team and shares his
thoughts with his team mates. He feels proud because he can connect with the
essence of Kanban in his approach. He feels proud because his experience and
knowledge make him realize the power of Kanban!
With hindsight, he feels that he
could have used yellow stickers or a tool to improve effectiveness and
optimized the time spent managing the visual board. He could have hired a
Kanban coach to help his team in areas such as value stream mapping. However,
he realizes that the popularity of Kanban in the software industry has grown
only in recent years.
Six months after these happenings
and with a promotion at work, Dan continues to execute projects using Agile,
Lean and Kanban.
What has been your experience related to implementing Kanban?
