1 Yes We Kanban! Introducing an Agile Methodology to Manage Your Team Bryan Morris, P.Eng., Verilab, [email protected] Abstract—This paper describes how a management tech- Most importantly, it is easy to adopt since you can start by nique known as Kanban can be adopted and adapted into an simply capturing your existing process, and then incrementally ASIC/FPGA development flow. The key advantages of following optimize your team’s or project’s processes. In other words, such a process is that it provides a visual overview of what your team is working on, current blocking issues and bottlenecks in you don’t have to change how your team is managed, but your process, creates opportunities for the team to proactively can instead gradually introduce Kanban into your flow in an discuss their process and blocking issues on a regular basis, and incremental fashion. is easy to adapt to most existing team management structures. If you want to know exactly what the current state your Index Terms—agile, kanban, lean manufacturing, ASIC/FPGA project in an easy to understand way, identify bottlenecks and management quickly identify risks that become apparent during develop- ment, try using Kanban. I. INTRODUCTION Lastly, while there are many tools that assist teams in A key verification challenge is the ability to coordinate following a Kanban approach, a key advantage of Kanban is and focus your team’s activities. Along with the increasing that it requires nothing fancier than a whiteboard and sticky complexity of the ASICs and FPGAs under test, it is now notes. This paper encourages teams to adopt this simplistic common for design verification to be the critical path for approach to start. many ASIC/FPGA projects. While improved tools and stan- While web-based Kanban solutions exist, I strongly dis- dardized methodologies will continue to help, I believe that courage their use while you are introducing this change it is also important to investigate other ways of organizing to your team. Ensure that your team is comfortable with your team. Software teams have been successfully applying the techniques and underlying principles using the simple, agile techniques such as eXtreme Programming (XP), Evolu- physical whiteboard and sticky-note method before attempting tionary Prototyping, Scrum and others for many years. The an electronic approach. techniques from these methodologies have been successfully adapted in several ASIC/FPGA development flows. A more II. CURRENT STATE OF AFFAIRS recent methodology called Kanban offers some interesting Before we delve into why you should consider using Kan- capabilities that can augment your teams existing management ban, it would helpful to capture the current issues that we face flow. in the design and verification of complex ASICs and FPGAS. Kanban originated in auto manufacturing [5] that became These issues include, but are not limited to the following: part of the Lean Manufacturing focus. It has since been • increasing complexity of ASIC/FPGA development adopted (and adapted) successfully for software development. • increasing size of project team which in turn, increases This paper provides background material to understand the the complexity of internal communications within the value that adopting a Kanban approach to your team man- team agement can bring. It also provides guidance on adopting and • multi-site teams again, increasing the complexity of both adapting Kanban into your existing flow. team dynamics and internal communications The key reasons to consider adopting a Kanban approach • understanding your project’s true current state, and in your IC development are as follows: • limited opportunities to explore new techniques and • Kanban provides a visual representation of your process methodologies while still in development. flow enabling your team to easily pick out where there Every project has experienced at least one of these factors. are opportunities to optimize the work flow (i.e., in the Our project management teams are highly capable individuals Lean manufacturing terminology to eliminate waste). usually with a great deal of experience and yet most teams are • It highlights issues and bottlenecks in the process so that incapable of producing a schedule and budget that doesn’t go the team can apply the correct resources to resolve any off the rails shortly after starting. I know because I’ve managed issues as quickly as possible. many projects over many years and have spent endless hours • It creates opportunities for discussion to ensure that the updating the schedule to account for something unexpected, team is always working on the feature that has the highest or some technical snag that’s preventing progress. customer value. It’s time we admit that we simply cannot create a schedule • It provides a more realistic view of the true current state that is believable. It’s not because we aren’t capable, the task of the project, and a view to planned completion through is intractable because by their very nature the ASICs/FPGAs improved objective project metrics. we create have too many unknowns and risks: • technical risks - we are usually building something that has never been built before. Therefore, we have no prior Todo In Progress Done experience to deterministically gauge its complexity. Feature 1 • technology risks - frequently we are forced to use a new Feature 4 tool, methodology or process technology. In most cases, Feature 2 Feature 3 being the bleeding edge of technology means that we’ll need to deal with unforeseen bugs. • people risks - the team we start with in most cases is not the team we end up with. Frequently, team members are P-1 shifted on and off the project, or need to support past BugFix work, or look at future possibilities. • resource risk - in many large companies any physical resources such as compute farms, licenses, etc. must be shared across multiple projects. Resource contention is inevitable at some point in the project which will likely lead to unplanned for delays. Fig. 1: Simple Kanban Board Kanban is not a silver bullet that solves all these problems. But it can help your team work in a focused, disciplined way, understand their next highest value task that must be done, Todo In Progress Done and a clear understanding of what’s left to do. Feature 1 III. INTRODUCING KANBAN FOR ASIC/FGPA Feature 2 Feature 3 DEVELOPMENT Compared to some traditional, and perhaps, other agile project management frameworks, Kanban is extremely simple Feature 4 to understand. I believe that that simplicity is its core strength P-1 BugFix and why I believe using Kanban can be a force for substantive change in the way we work. Kanban has six core practices: 1) Visualize your Workflow 2) Limit Work in Progress 3) Manage Flow Fig. 2: Kanban Board Movement - a 4) Make Policies Explicit 5) Create opportunities for feedback 6) Improve Collaboratively, Evolve Experimentally Todo In Progress Done Each of these are discussed in greater details in the sections below. Feature 1 Feature 2 Feature 3 A. Visualize your Workflow At the heart of Kanban is the idea that the team needs to see their workflow. Only by using a visual representation of Feature 4 P-1 your workflow can you find opportunities to improve it. In BugFix fact, Kanban is roughly translated from Japanese as signboard (or visual board). A simple whiteboard consists of columns representing dif- ferent phases in your workflow and any task or activities flow from the left (the start of your workflow) of the board to their completion on the right (when they are done). A simple Fig. 3: Kanban Board Movement - b example is shown in Fig. 1 where your team has defined three simple phases: Todo, In Progress, and Done. Similar to many Kanban boards in use, this diagram is representative of Leaving space in In Progress for Feature 2 to be a white board with sticky-notes holding the task/activities that pulled in from Todo as shown in Fig. 3 need to be accomplished. All activities are planned, tracked and visually represented Movement flows from left to right as room becomes avail- on a Kanban board. Regular and continuous opportunities are able from right to left. As shown in Fig. 2 where Feature provided to discuss as a team how to ensure that the team is 4 moves from In Progress to Done focused and working on the most important activity. As shown Page 2 of 7 in Fig. 3 expedited activities such as bug fixes can be visually ‘quick’ tasks that need to be done. Clearly, this is not efficient represented using a different colour. due to the need to context switch between tasks. It is more A more realistic example is shown in Fig. 4. This board has effective to ensure that each person is focused on a smaller multiple workflow phases: number of tasks and allow them to work them through to • Backlog : all the features/activities that need to be done. completion. That is the goal of this practice to Limit Work in • Analysis : allowing time to understand and analyze the Progress. problem, capturing the requirements, defining the “exit” Every project has constraints: people, compute power, li- or “done”criteria, and considering different architectural censes, planned vacation, etc. These constraints need to be approaches. clearly identified and captured on the Kanban board. This is • Design : capturing the initial design. done by assigning a work in progress (WIP) limit to each • Implementing : implementing the solution. column in a Kanban board reflecting the constraints. For • Verifying : debugging and/or verifying the implemen- example, let’s assume we want to assign a WIP limit to an tation is correct and meets the criteria defined during the Implementing phase. If we have four developers and make Analysis phase.