Paul Cornell

More kanban resources:

• Kanban Systems: http://jamesshore.com/Blog/Kanban-Systems.html. "Typical Agile projects use time-boxed iterations. At the beginning of the iteration, the team meets and chooses stories from their backlog that can be done by the end of the iteration. Over the course of the iteration, they develop those stories, and at the end of the iteration, they ship them. Kanban systems are different. Instead of using time-boxed iterations, Kanban systems focus on a continuous flow of work. The team takes a story from the backlog, develops it, and ships it as soon as it is done. Then they take the next story from the backlog, develop it, and ship that story. Work is shipped as soon as it's ready, and the team only works on one story at a time....The primary work unit for the team is the "minimum marketable feature," or MMF. An MMF is the smallest feature that has value to the market....The team maintains a backlog of MMFs in a queue. This queue is strictly limited in size....If there's an emergency, a support request, or some other urgent need, there's an empty slot on the board marked 'Urgent.' The team can put an MMF in that slot at any time without having to go through the regular backlog queue. The team strives to finish urgent items quickly, and they try to keep the slot empty and available at all times. If the 'Urgent"'slot is full and another urgent item appears, it has to be added to the backlog queue....As with other Agile approaches, the team is expected to fix bugs before the MMF is done. If bugs are found afterwards, the fixes are scheduled with a new MMF. If a bug needs to be fixed immediately, the team uses the 'Urgent' slot."
• Kanban in Action: http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html. "Though we track all [change requests] CRs in Team Foundation Server [TFS]...the day-to-day work is tracked on a white board using Post-IT notes as kanban cards....Each morning the team meets for a standup around the kanban white board to discuss the work-in-progress and how to keep it moving....A red star indicates that the item is severely aged[;]...[t]his allows the 'late' item to be self -expedited without direct management intervention....Blocked CRs have pink sticky notes attached to indicated that there is an open issue in [TFS]...Yellow - customer-valued CR; Blue - customer-valued (and requested) bug (fix); Green - IT maintenance item...Orange - additional (or extra) bug; pink - issue....The kanban limit for the system is 20 cards, divided in to different stages in the process - systems analysis, development, test, build/merge, deployment. In addition, we allow for 3 extra bugs to be anywhere in the system....The kanban system also frees us from the constraints of time-boxed iterations. Even though we are making a release every two weeks, items in the system can take up to 60 days to move through depending on their size and complexity....And finally, the kanban system has freed us from the management overhead of running each iteration like a mini-project."
• Naked Planning Explained - Kanban in the Small: http://aaron.sanders.name/agile/naked-planning-explained-kanban-in-the-small. "The idea of the variable length Product Backlog with the need to reorganize priorities and estimate size was replaced with a fixed-length queue placed on a whiteboard for the Product Owner (Customer) to fill with Minimal Marketable Features (MMF), or what in Scrum would be User Stories....The length of the queue is seven, as this is believed...to be about the maximum amount of items any one person can hold in their head at a time....The customer is allowed to rearrange these 7 MMFs as often as is seen fit. When the team is ready to pull a new feature, it is whatever is currently at the top of the stack.....There is one expedite slot for the customer to override [Work In Progres] WIP, anything else has to wait for a slot to open....MMFs are dated when they are placed on the board, and when they are finished to derive the average time of a feature...The engineering team has 4 slots for WIP. This was determined because there are 8 engineers who pair all code....Stand-ups happen multiple times per day and are short. When the team switches pairs they ask if there’s any significant increase of information of note which is not on the board....Every Friday is a trade show of all released MMFs, and is a very jovial time in the office, a celebration of a job well-done."
• Managing the Pipeline: http://www.poppendieck.com/pipeline.htm. "Queuing theory gives us six rules for reducing software development cycle time: [1] Limit work to capacity [2] Even out the arrival of work [3] Minimize the number of Things-in-Process [4] Minimize the size of the Things-in-Process [5] Establish a regular cadence [6] Use pull scheduling....One way to estimate the capacity is to look at output....According to Little's law, there are two ways to improve response time: you can spend money to improve the Average Completion Rate, or you can apply intellectual fortitude to reduce the number of Things-in-Process....You will get much faster throughput and higher utilization if you develop ten services one at a time, rather than developing all ten at the same time....An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity....Pull scheduling is the best method to compensate for variation and limit work to capacity. At the beginning of an iteration, the team ‘pulls’ work from a prioritized queue. They pull only the amount of work that they have demonstrated they can complete in an iteration. When a team is first formed or the project is new, it may take a couple of iterations for the team to establish its ‘velocity’ (the amount of work it can complete in an iteration). But once the team hits its stride, it can reliably estimate how much work can be done in an iteration and that is the amount of work it pulls from the queue."
• Kanban Process Template for Team Foundation Server: http://www.codeplex.com/KanbanTFS. "A process template for Team Foundation Server that utilizes a Kanban approach. This approach is based on the original series of articles posted on the AgileManagement articles 'A Kanaban system for Sustainable Engineering:' http://www.agilemanagement.net/Articles/Papers/AKanbanSystemforSustainin.html. Also, based on experiences found on Lean Engineering blog: http://leansoftwareengineering.com/ and Eric Landes's blog: http://aspadvice.com/blogs/elandes."

See also:

• Software Development Productivity: http://www.poppendieck.com/pdfs/Software%20Development%20Productivity.pdf. "As the technology sector matures, it can no longer depend on increasing growth in the underlying technology to fuel productivity increases. The time has come for serious efforts to increase productivity through more efficient use of labor and more effective value propositions for customers....There are three basic approaches to productivity improvement: [1] Reduce product costs by eliminating investments in product features that customers do not find valuable. [2] Reduce indirect costs by streamlining processes and eliminating inefficiencies in development, delivery and support. [3] Increase revenue by adding more value to a product so customers will pay more for it....About two-thirds of the features of a typical software system are seldom or never used. Only twenty percent of the features are used frequently. Eliminating extra features that no one really wants represents the single largest opportunity for increasing software development productivity in most organizations....limit overproduction of features by developing features on an as-needed basis....Organizations which record year-on-year productivity improvements spend a lot of time focusing on streamlining key processes while increasing their reliability....In general, customers cannot be relied upon to tell a software development organization how to increase the value of its offerings. In fact, customers generally think of software as a tool that should adapt to their needs over time. This makes understanding customer value elusive not only during a software development project, but even after deployment....We are not likely to increase software’s value proposition unless we increase our understanding how customers might use our software to create value for themselves....focus on their key processes and map their value stream....The focus has been on predictable delivery of pre-defined scope rather than increased productivity. Not surprisingly, processes which did not value productivity did not deliver productivity increases; quite often they decreased productivity instead."
• Lean Programming: http://www.poppendieck.com/lean.htm. "...instead of following complex processes, using simple rules to communicate strategy is the best way to empower people to seize fleeting opportunities in rapidly changing markets....Ten simple rules: [1] Eliminate Waste [2] Minimize Inventory [3] Maximize Flow [4] Pull From Demand [5] Empower Workers [6] Meet Customer Requirements [7] Do it Right the First Time [8] Abolish Local Optimization [9] Partner With Suppliers [10] Create a Culture of Continuous Improvement....Eliminate anything which does not add value to the final product....Requirements and design documents must be kept to a minimum to maximize development flow....Instead of a 100 page detailed specification, write a 10 page set of rules and guidelines, and document only the exceptions....Keep requirements flexible as close to system delivery as possible.... It is always better to tell developers what needs to be done, not how to do it....The most effective way to accurately capture user requirements is found in the iterative approach to system development. By developing core features early and obtaining customer feedback in a focus-group demonstration of each iteration, a far more correct definition of customer requirements can be obtained....Write the tests first, and then write the code....Excellence means the ability to adapt to fast moving, rapidly changing environments."