With the December update, we have made a huge breakthrough in 2 major areas which have been in our backlog for a long time and have been repeatedly requested by customers across the globe. “Visualization” is the primary goal of Kanban and the Kanban board is the heart of any Kanban system. Any team working with Kanban follows one key principle – to have all the work items visualized on the board. But over a period of time, as more and more item-types get added, it can become difficult for team members to keep track of important work items and their status as they are spread across the board. In large team Kanban systems, this can be a significant issue.
It started on a rainy August morning of 2016 in Mumbai. I was thrilled to be attending the Kanban Design Practitioner workshop and was eager to learn Kanban concepts that originated on the manufacturing floor of an automobile company. The concepts are now being relentlessly applied in Agile practices of Information Technology organizations across the world. I hoped to understand the concepts that made the Kanban approach so universally popular. The masterclass started by introducing what essentially is Kanban and the very important concepts around ‘Flow’ and ‘Visualization’.
Of all the roles in a software or product development organization, I will argue the Product Manager’s (or Owner’s) job is the most challenging. On the one hand, the task of figuring out just what to build is complex and multifaceted. On the other hand, in any reasonably mature product organization, there is so much work that is going on and so much new demand, that the Product Manager can wish all they want in terms of product innovation and focus on the product roadmap, but failure and customer demand pretty much hijacks most of the Dev capacity in the organization.
It’s been more than 10 years since the launch of the body of work that ultimately led to the Kanban Method for knowledge teams by David Anderson. During last month’s Lean Kanban India conference (the very first official Lean Kanban conference in India), which we were very proud to co-host and be a Title Sponsor of, David presented a journey down memory lane of 10 years of Kanban. During this period, Kanban, and the Kanban Method, have emerged, depending on who you talk to, as an “alternate path to Agility”, an alternative to Scrum, a way to improve your Scrum
Energetic, responsive, trying harder – those were some of the best compliments we received from our customers. As one of them, who switched from a competing product to us, said, «It looks like you guys are always trying harder and better than the rest of them.» Absolutely! The past 12 months have been truly exciting. 2013 was the year in which organizations ranging from boutique consulting companies to global automotive giants, high-security government agencies to Fortune 500 global brands trusted us and our products with their technology.
That was the question posed in a recent discussion. The question further provides the following details – “I work within an agile team. We have a released product and we are still working towards a future release. Every sprint we receive anywhere from 0 to 5 tickets to fix bugs in the released product. Our team is composed of software engineers (to handle new development) and maintenance software engineers ( to handle tickets). My question is how do you account for the maintenance hours during sprint planning. Currently we have a story called maintenance buffer where we allocate some hours to solve tickets.
Within the SwiftKanban development team, we have evolved our Engineering practices, combining principles of Test Automation, Continuous Integration and Kanban thinking. At the same time, as we look to hire people for such a development environment, we have found it difficult to get people who understand such an environment, even though we can hardly be called bleeding edge! Hopefully, this post helps in understanding in our Engineering environment. The day starts with a stand up meeting at around 9am. Since we are distributed team across three different locations (3 cities, 2 countries), many of our team members join the call remotely.
Over the last more than 18 months of steady-state usage of Kanban in our product management and engineering teams, we have achieved a number of dramatic improvements. Even considering that for us, it was – and is – a case of eating our own dog-food, these improvements are nothing short of incredible for a small product company where every minute, every dollar, every feature that is value to a customer, counts! So, we thought we should share our experience and benefits with the software and IT community in the hope that some of these will help you benefit as much or more than what we have been able to do. This post is the first in this series.
Try SwiftKanban Enterprise Plan FREE for 30 days.