Agile Project Management with Kanban (Developer Best Practices)

Book Details

  • Full Title: Agile Project Management with Kanban (Developer Best Practices)

  • Author: Eric Brechner

  • ISBN/URL: 978-0-7356-9895-6

  • Reading Period: 2019.08–2019.09.03

  • Source: Ad-hoc browsing at the library

General Review

  • This book give practical information on how to use Kanban as a project management system in a company.

  • Read this book if you want to get a sense of what are some good starting points to structure the Kanban board, and what a typical Kanban issue would look like.

  • This book also compares Kanban with Agile/Srum.

    • The author is arguing from experience that Kanban is a better approach.

  • Microsoft Press publishes quite some great books.

Specific Takeaways

  • Main idea of using the Kanban approach is to keep tasks small, and limit work-in-progress at each stage of the Kanban workflow.

    • This prevents the team structure is balanced, and the output rate of each part of the pipeline is in line with the rest of the pipeline.

    • Keeping tasks small, and avoiding partially completed work from piling up also help makes the system capable of responding to changes.

To Internalize Now

  • When using Kanban, have a separate column of the concept of "done" that is before the commencement of the next step.

    • E.g., Instead of just Implementing followed by For Review, it would be clearer to have Implementing, Done Implementing, Reviewing and Done Reviewing. In the former, once an item is put from Implementing to For Review, we have no visibility on the progress of review (i.e., we don't know whether the reviewer has started reviewing, or it is pending review).

  • Kanban is a viable project management approach. It consists the following elements:

    • Clearly defined steps for the workflow: e.g., Specify, Implement, Validate

    • Each steps should be split into at least two columns—in progress, and done. There should be specific rules on when items can be moved to the done: e.g., for Implement, it is only done when, among other things, all public APIs are documented

    • There should be strict Work-In-Progress limit for each steps (including both in progess and done columns. The WIP should be set starting with the slowest step, and setting it to number of members responsible for that steps, + 50% buffer. Set the WIP for other steps to match the throughput of the slowest step (note: to do this, I need to have an estimate of the rate of the steps (days/person), and the number of team members on that task)

    • The daily stand-up is only used to addressed blocked issues

To Learn/Do Soon

  • Get a good book on Scrum / Agile / Lean / Extreme Programming etc. to understand the difference, and the underlying problems each is trying to solve.

To Revisit When Necessary

  • I might want to re-read specific sections of the book:

    • For details on how to specify / break down each step of the workflow

    • When I face problems using a Kanban approach

    • When I'm required to provide timeline estimates when using a Kanban approach

    • When trying to convince people (upwards and downwards) to adopt Kanban approach

    • For details on how to use Kanban in a large organization

Other Resources Referred To