May 31, 2009 / Lean and Kanban Software Development Digest

4 comments

Lean and Kanban software development adoption is growing. More and more companies setup Kanban Boards, limit WIP and eliminate Muda.

This collection of links will help you understand all that buzz around Lean/Kanban and decide whether it is worth trying. I've read all the articles and posts below, so this list is a truly selected thing ;).

Articles and Blog Posts

• Lean Software Development. Wikipedia summary about lean software development. It is a good start to digg into the topic (as usual).
• Kanban Development Oversimplified. Most likely the best article to start with Kanban. Very clear, very detailed. Good work!
• Kanban, Flow and Cadence. This blog post with many nice pictures describes three important properties of Lean: Kanban – Controlled Work, Flow – Effective Work, Cadence – Reliable Work.
• Scrum-ban. Interesting attempt to mix Scrum and Kanban, taking the best from both worlds. Kanban with iterations is possible.
• Beyond Scrum: Lean and Kanban for Game Developers. Article describes real Lean/Kanban implementation for game development industry. The section on how to improve The Flow (3 strategies: Time-boxing, Levelling workflow, Reduce waste) is especially good.
• Adventures In Lean. Series of posts about Lean approach with focus on real problems solving (handling bugs and emergency fixes in Kanban, setup pipeline, bottlenecks, etc.).
• Lean and Kanban. Several posts on the topics in this blog.

Presentations

• Kanban for Software Engineering . Detailed presentation about Lean and Kanban. Focuses on many problems and solutions in a software development process.
• Kanban: A Process Tool . Another good presentation that emphasizes the simplest rule in kanban: Limit the number of things in work to a fixed number. Maybe a good start indeed.
• Practical Experiences and Tools Applied to a Kanban Sustaining Engineering System . Fantastic presentation about Lean/Kanban implementation with real examples by Alisson Vale.
• Kanban vs. Scrum. Rich and lengthy presentation that compares Scrum and Kanban. A very good visualization (which is a key in Kanban :). Shows why Kanban fits better for multiple development teams working on the same project. I tend to share this opinion as well.
• A Kanban System for Sustaining Engineering on Software Systems . Very interesting presentation of Lean implementation at Corbis. As I know, it is one of the first successful attempts to run Kanban in a software shop. Must read.

Lean/Kanban Blogs

• Agile Management Blog. Lots of interesting posts from David J. Anderson (well known engine of Lean software development :)
• Richard Durnall Blog. Pull and Push systems, interviews, lean roots and principles. Nice reading with hand-drawn diagrams.
• Lean Software Engineering. Corey Ladas and Bernie Thompson are blogging about Lean, Scrumban and Kanban, Theory of Constraints, software development and other topics you did not even hear about.
• AvailAgility. Karl Scotland's posts are very interesting (and helpful) to read. Isn’t Kanban just a Task-board? Check the blog to get an answer.
• The Agile Executive. Many insights into Kanban and summaries from the first lean conference.
• Software Just in Time. Lean concepts and real lean applications posts by Alisson Vale.

Lean/Kanban People in Twitter

• David J. Anderson. Lean/Kanban software development pioneer.
• Corey Ladas. Product development methodologist. Author of Scrum-ban book.
• Henrik Kniberg. Optimize, debug & refactor IT companies. Author of Scrum vs. Kanban presentation (which is very good!)
• Karl Scotland. Agile Coach. He runs AvailAgility blog with great insights into Lean and Kanban.
• Rob Lally. Renaissance Technologist.
• Alisson Vale. Alisson implemented outstanding Kanban process in his company.

Tools

There are just several Kanban tools on the market. To be honest, I don't like TRICHORD UI. LeanKit: Kanban looks much better, but it can work for small teams only on my opinion. Anyway, it seems Kanban tools vendors' race just began.

If you know other tools that support Kanban, drop a comment and I'll happily include them into the list.

• LeanKit: Kanban. In beta so far, but looks quite neat. Maybe useful for small teams.
• TRICHORD. Desktop project management application with Kanban boards.
• Radtrack. Registration does not work, but I found the screenshot via Google. Looks like LeanKit so far.

Did I miss something interesting? Drop a comment!

Labels: agile, digest, kanban, lean, links digest

posted by Michael Dubakov @ 1:51 PM

May 22, 2009 / Friday's Digest #13 [Kanban, ASP.NET MVC, Ajax]

0 comments

• Goals for using Kanban David Anderson put a nice list of Kanban usage goals. "Goal 1. Improved performance through process improvements introduced with minimal resistance"
• How we do MVC and Our “Opinions” on the ASP.NET MVC . Very good posts about ASP.NET MVC challenges, tricks and solutions. Must read if you are starting serious project based on ASP.NET MVC.
• Tim Sporcic blog. I like this blog a lot. Tim has a talent to express his thoughts and most posts are very interesting and helpful. If you are using ExtJs, ajax and mvc pattern — just add the feed to your feed reader.
• jQuery vs. MooTools. Extensive comparison of two popular JavaScript frameworks. If you evaluating choices, don't miss this reading.

Labels: ajax, asp.net, digest, kanban, mvc

posted by Michael Dubakov @ 1:32 AM

May 9, 2009 / Friday's Digest #12 [Design, Business, Kanban]

0 comments

• In Defense of Eye Candy. Nice article. It discusses why aesthetics is important in a design: "when we talk about how emotions influence interactions, it’s closer to the truth to say things that are enjoyable will be easy to use and efficient." And another fantastic quote "how we 'think' cannot be separated from how we 'feel'".
• Discovery-driven Growth: The Only Plan Is to Learn as You Go. Quite lengthy, but interesting interview about business development in a current economy. Discovery-driven growth is a way to go.
• Kanban and Time-boxes. Does Kanban compatible with iterations and time-boxes?
• Wanted/Needed: UX Design for Collaboration 2.0. Designing collaboration software has some specifics. Can we create a framework that help with it?

Labels: design, digest, kanban

posted by Michael Dubakov @ 11:34 AM

May 1, 2009 / Friday's Digest #11 [Kanban, GTD, Economy]

0 comments

• Why Small Companies Will Win in This Economy. "Small is the new big. Sustainable is the new growth. Trust is the new competitive advantage."
• So, Now You're an Agilist... What's Next? Interesting presentation from Jurgen Appelo with attempt to bring complexity science into agile software development. And interesting debates thread between Jurgen, me and Glen Alleman.
• Feature Crews: kanban systems for software engineering in the large. We are using branch-by-story at TargetProcess and something similar to feature crew. I think the idea is very good.
• Getting Things Done Mind Map Diagram. GTD is quite interesting technique, I am trying it right now (and liking it so far). This mind map is really good quick intro to GTD.
• Things — task management software. Great GTD software for Mac users. Very clear concept with perfect implementation.

Labels: digest, economy, gtd, kanban

posted by Michael Dubakov @ 3:28 AM

Sep 9, 2008 / Reveal Agile Development Process Problems with Kanban Board

0 comments

In previous post I described Kanban and its application in agile software development. Kanban board is not just a way to communicate story state, it is a tool that can reveal some problems in the development process.

There are some simple patterns that are very intuitive and can be applied to any development process. You should look for gaps on the kanban board. If you have many stories in a column before the gap, you definitely have a problem in development process.

For example, we have several user stories in Implemented column, but none in In Testing column. It means that testers are unable to process user stories. They are overburdened, or unexperienced, or lazy, or travel to Bahamas, or anything else. Kanban board can't tell what the problem is, but it shows that it is exist.

The gap may unite several columns. For example, we have some user stories in In Progress state and some in Done state. It means developers are unable to feed testers with implemented user stories. Maybe we have too many testers or not enough developers. Again it is not clear, but the problem is there.

Last case is when we have user stories in all states except Done. It is more complex case and it depends on context. In the beginning of the iteration it is definitely OK to have Done column empty, but in the halfway you expect to have something done. Otherwise testers will be overburdened in the end, we'll drop some stories, or we'll complete them in a hurry with poor quality.

As you see it is a very simple but effective way to identify problems in agile software development process. Nice side effect of the pull system!

Labels: kanban, problems, pull system, software development

posted by Michael Dubakov @ 4:32 AM

Sep 8, 2008 / Kanban in Software Development

3 comments

Lean software development is becoming a new buzzword. More and more articles, books and discussions around lean and software development popped up last year. People are using new terms like Kaizen, Kanban, Muda, Pull System, etc. Well, this is great. New thinking about software development stimulates new ideas and new solutions to old problems.

Push, Pull, Kanban

Kanban is a very popular buzzword in agile community and in this post I will try to combine various applications of Kanban for software development. In general, Kanban is a part of Pull System. Pull system determines whole supply chain. How many screwdrivers we should produce next month? Push system predicts the quantity based on history data and market parameters. For example, we predict that we need 10000 screwdrivers next year and will produce 10000 screwdrivers. Who cares if one half of the screwdrivers will be unsold till the end of the year? The plans for next year will be corrected, but unsold screwdrivers take store space and money. Pull system produces just required amount of screwdrivers. In ideal life we find a customer, produces what he needs and sell it. Anyway, Pull system reduces inventory.

Kanban is a sign or a signal in the development/supply chain. It activates some process. For example, you have small shop that sells screwdrivers, small warehouse and small plant. Imagine that each screwdriver has small kanban card on it. If a lucky houseowner purchased one screwdriver, the card returned to warehouse. It shows that one screwdriver should be delivered to the shop. The screwdriver delivered, but free kanban card returned to the plant. Plant management knows that one more screwdriver should be produced. They produce it and deliver to the warehouse. Thus customers' demands rule the whole cycle.

Product Kanban

How it can be applied to software development? I think there are several applications. One-year-long project plan is a push system. We expect to sell all these features in the next year delivery, but it may happen that customers will need (use) only one half of them. "Why the hell you add Blue Ray support? This is plain dead thing!" There situations where one-year-long plans works. If customers demand is defined and persistent, you may do that. It means that customers do not want to change anything in product scope next year. I don't know industries where it is true, but I asume they may exist.

Iterative development and product backlog is a pull system. If the item is in the backlog, it represents customer's demand. But customer is free to remove it anytime, thus changing the demand. This is a high level kanban (product kanban). If item exist in the backlog it is a signal that it should be implemented.

Release Kanban

During iteration development kanban rules Implementation/Testing activities. For example, testing team may take implemented user stories and start testing. The most popular way for this kanban is a simple whiteboard with several columns (Not Started, In Progress, Implemented, Tested). Each user story is a small sticky note. Initially all user stories are in Not Started column. When user story is done by developer, he put the sticky note to Implemented column. And that is the sign for testers.

You may think out different ways though. For example, when user story is implemented, loudspeaker in the testers room shouts "User Story As an Admin I want to moderate people comments implemented" each 5 minutes until somebody takes this story for testing. Another way is to take story card, crouch to testers room and put it into implemented user stories stack behind tester's back. You got the idea. Testers should be able to check what is available for testing anytime.

Kanban board may work for complex process without problems. Developers see what to take for implementation, testers see what to take for testing, technical writers see what to take for user guide update, customer see what is ready for check or release.

Software development differs from manufacturing significantly. The plant produces looks-alike screwdrivers. It can have robots and sharp process to produce stuff. We can't replace developers with robots. Each feature is unique, each user story is unique. We can't create detailed process, software development needs innovations, researches and a-ha! moments. Software development is a complex adaptive system that works on the edge of chaos and can't be ruled by complex procedures and instructions. Complex rules lead to dumb simplistic behavior, we can't apply such processes to software development.

It seems I went to far. OK, back to kanban. Signals in software kanban should be different. It is not enough to meet a tester and put black label (or card) into his hand when user story is ready. Tester should know what exactly user story is ready (only screwdrivers are the same!). The kanban card should contain at least user story name or ID. That is why in kanban board status coded by column/story combination.

Alternative is to use labels with different colors for each user story. For example, yellow label for implemented, orange label for testing. But each label should have user story ID (or name) on it. You may give labels to developers and testers and they will stick them to user story when required.

Maybe this method worse than usual board, but I just want to show you that there are different ways to kanban in software development and you may be creative to generate better ideas.

If you have distributed teams you will have to use web based kanban. I am not aware about online tools that provide kanban board. If you need just kanban board most likely you will have to create it in-house. There are tools with Task Board (including TargetProcess), but it is not the same. Task board shows task statuses and from tasks it is not clear when the user story is ready for testing. It can be used as a signaling system, but with less success.

A nice side effect is that Kanban board helps to identify problems in agile development process.

Labels: kanban, lean, pull system, push system, story board

posted by Michael Dubakov @ 6:17 AM