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

Oct 20, 2008 / Agile Development Future: Will Lean, Scrum and Extreme Programming evolve into one framework?

6 comments

People often ask questions like "What is the difference between Scrum/XP/Lean/Agile/You name it"? I don't see much difference between XP and Scrum on that matter. If you already have XP, most likely don't need to switch. Maybe adopt some Scrum specific practices for a better scalability like Scrum-of-Scrums. Almost all the other practices like daily meetings, iterations, roles separation, retrospectives, etc. exist in XP already.

In fact I am not sure if such separation brings benefits. It is better to spot what's going wrong in your development process during retrospective meetings and apply practices from any agile process (or create own solutions) to your specific problems. XP, Scrum or Lean give you a framework that helps to be adaptive and creative, whereas traditional processes give you a set of rules hindering any creative behavior.

Your team and your project IS special. Think and communicate to sharpen your development process.

I do understand why people are so enthusiastic about Scrum or XP. These processes provide tools and practices out of the box. You may just start doing it and see what happens. It is not the best way, since quite often agile adoption fails. People don't get the new way, they implement it without proper support and under the pressure. They maybe don't have a deep understanding how it should work. So it is expected that agile adoption might not be smooth for all.

Agile Development Future

I wish all agile methodologies evolve into one elegant, smart, simple framework. For me it is a natural trend and it should be something like Theory of Everything in physics. This framework should explain why agile processes work. It should based on natural laws of Complex Adaptive Systems. It should provide general guidance on agile adoption and a repository of possible practices that might be used to build your own development process. The framework should be simple and unobtrusive, since complex rules will not work for software development. The framework should empower creativity, communication, learning, feedback and self-organization. The framework should support nonlinearity, emergence and edge of chaos concepts.

Software development is young. Currently we are having transition from waterfall to agile. It is mainly based on practice rather than theory. Practice has proven that agile works better. However, there's almost no research explaining why. There are some blog posts and short explanations with reference to Complexity Theory. That is a right direction I think, but there's no depth behind these posts, they are quite superficial.

I expect we will have deeper understanding of the agile roots and why it works. This knowledge will simplify transition and help us to find better practices, patterns and solutions. I expect there will be a unified agile software development framework in the future.

So far Scrum and Lean are closest processes to this framework. Lean has a strong philosophy and nice background. It is general enough. Scrum is simpler and more understandable for mere mortals. XP has a set of best practices and heavier in general. All of them have strong and weak sides. But still I feel there's a deeper level and all modern processes are just a subset of some hypothetical (at the moment) unified agile software development framework.

Labels: agile, extreme programming, future, lean, scrum

posted by Michael Dubakov @ 3:25 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