| Agile Project Management with Kanban |
|
Author: Eric Brechner Is Kanban a good technique for you? Read this book to find out.
Author Eric Brechner is the development manager for Xbox. Prior to joining Microsoft he worked for Boeing, Silicon Graphics, Graftek and Jet Propulsion Labs. If this doesn’t give him the authority required for this book, more important is the fact that he has always been interested in software development practices that increase his productivity while benefiting customers with better products. As he explains in the introduction, in the 1980s he focused on design patterns and unit test; in the 90s he relied Waterfall milestones and stabilization period of different duration, T-shirt estimation, asserts, bug jail, continuous integration, and design and code reviews. At Microsoft in the 2000s he experimented with Team Software Process, Scrum, code inspection, static analysis, planning poker, pair programming and test-driven development (many of which technologies you'll find discussed in our other Methodology book reviews). He concludes this catalog with: Now in the 2010s I've found continuous deployment, Kanban and a little nirvana. Brechner's goal in this book is to let others cut out all the experimenting and simply let others duplicate the success the Xbox teams have had with Kanban by following his pragmatic and prescriptive step-by-step instructions. As well as the general and detailed guidance Brechner also provides two files you can download and use – an Excel workbook with the sample spreadsheets that he uses and the sample letter introduced in the first chapter.
Chapter 1 points out that prior to adopting Kanban you need to obtain management consent and rather than discussing this the chapter includes an open letter to the person you need to convince. This is a clever move as it succinctly summarizes why switch to Kanban; what it is - a simple project management system based on one developed by Toyota for just in time scheduling; its key features; and its risks together with their mitigations, before outlining a plan of action for introducing Kanban. The chapter concludes with an “Inside Xbox” boxout which explains how readily the teams Brechner first introduced to Kanban adopted it. With the preliminaries over, Chapter 2: Kanban quick-start guide is where Brechner puts his approach into practice. It assumes that you already have a team and a backlog - a set of work items to occupy them – otherwise yiou need to skip forward to the next chapter and return to this point later. The chapter outlines 5 steps in very practical terms: Step 1: Capture your team's high-level routine – although Brechner discusses more types of work he want us to focus on three steps Specify, Implement, Validate. Step 2: Create a Kanban board with two columns for each of the Specify, Implement and Validate steps plus a double width column to the left for the Backlog. Here he points out that Kanban means “signboard” in Japanese, while in Chinese Kanban translates as “looking at the board”. Step 3: Set limits on chaos - Brechner introduces this step by saying: This step is so important that you can often identify the essence of a project management methodology by how it limits chaos. So in a traditional waterfall approach chaos is limited by specifying all the work up front, enforcing a formal change request procedure and synchronizing work across all teams at predetermined milestones. In Scrum it is achieved with time boxed sprints which in Kanban it is done by directly limiting the amount of work in progress. The idea is to use the smallest work in progress limits that keep the team fully engaged in delivering value to customers. To explain how to determine the WIP limits Brechner presents the values from one of his Xbox team, using a spreadsheet that readers can access for themselves. Step 4: Define done – In Kanban there are two columns for each of Specify, Implement and Validate – the column on the right is for a work item that is active and the one on the left for items that are “Done”. Definitions of “pull criteria” that indicate when an item can be moved to the left are given for all three steps. Step 5: Run you daily standup. The standup is where cards relating to work items are moved across the board and how this operates this is explained in detail, followed by examples of troubleshooting where problems are identified. By the end of this chapter you'll understand the Kanban process and appreciate its simplicity.
Chapter 3: Hitting deadlines takes us a step back to planning a project and staffing a team. It applies the Kanban approach to providing predictability with scheduling and enabling you to match the size of a team to the project you are to undertake and looks at how to fill the backlog on the left side of the Kanban board. Again spreadsheets are provided for the examples. Chapter 4: Adapting from Waterfall and Chapter 5: Evolving from Scrum target specific audiences. Both chapters rely on extensive Q and A (referred to as Rude Q & A ) based on real questions that have been posed by developers coming from these two backgrounds. Chapter 6: Deploying components, apps and services is about what happens when you reach the right side of the Kanban board. It looks at continuous integration, a technique dating back to the early 1990swhich involves automating your build and testing it as you go along; then continuous push which is continuous integration applied to distributed version control systems such as Git; continuous publishing (early 2000s) whereby content published as soon as ready and updating to take account of feedback; and taking this principle further continuous deployment (mid 2000s). A boxout looks at continuous deployment inside Xbox and other Microsoft teams. In Chapter 7: Using Kanban within large organizations, Brechner uses his experience at Microsoft to look at some of the mechanisms needed to co-ordinate a track the work of large numbers of people engaged on large projects. Topics here include: Deriving a backlog from big upfront planning Ordering work based on dependencies Fitting into milestones Dealing with late or unstable dependencies As ever, example worksheets are used and we get more insights into the workings on the Xbox teams. Chapter 8: Sustained Engineering is contributed by James Waletzky and looks at Kanban workflow applied to software maintenance after release, including a section on troubleshooting that considers the problems associated with it.
click on book cover for more The final chapter is Further resources and beyond. Up to this point the book has been highly practical and focused. Here we encounter some wider issues and are presented with further reading. As well as expanding Kanban to other areas, the chapter looks at mixing Kanban with Agile and Lean and asks why Kanban works so well. The answer to this is: It's a combination of visualization, minimalism, Little's Law, single-piece flow, the theory of constraints and drum-buffer-rope. If you are tempted to ask “what?” to this last item, then you need to read this book! Eric Brechner has a highly accessible style – which he honed in a previous title under the pseudonym I.M Wright. The book's readability is aided by layout devices such as the boxouts already referred to and a checklist at the end of each chapter. If you want a quick route into Kanban this comes highly recommended.
This title is among those chosen by Kay Ewbank for inclusion in an article on Programmers Bookshelf where we recommend the very best books on a programming language or topic.
|
|||
| Last Updated ( Saturday, 25 August 2018 ) |
