Lean and Kanban Software Development Digest

Work In Progress (WIP)

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.


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.


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!

The Race to Performant Application: Designing Time and Flow

Fact: Complexity causes 50% of product returns

Fast and easy-to-use applications are quite rare. Simplicity and Performance are two major properties of any killer software product. We, as software developers, should pay attention to these properties as non-functional requirements, but in real life we often tend to implement more features, more functions, more settings, more, more, more… The race is hard to win with this strategy along the whole way.

I must confess we’ve done almost the same to TargetProcess. We went on with providing more and more features and options. Definitely we tried to keep the application simple and fast, but these goals were secondary. We’ve stopped. And changed.

Now we are focusing on better performance and usability. We think that TargetProcess is a quite feature-rich application that fulfills most needs in agile project management. It is time to stop and find answers to the questions: “Where do people get stuck with our software?”, “What is complex and how it can be simplified?”, “How to make TargetProcess enjoyable to use?”, “How to make TargetProcess the most performant software in our niche?”. The questions are hard to answer and address quickly, but we are looking for the answers.

Steven C. Seow wrote an excellent book about principles that should be taken into consideration for any “performant” application Designing and Engineering Time: The Psychology of Time Perception in Software. I read it and want to share some interesting observations.

Hick–Hyman Law describes the time it takes for a person to make a decision as a result of the possible choices he or she has. Simply speaking, less functions — simpler and faster choice. It leads to several conclusions what we should do as software developers:

  • Minimize options. Obviously, if you have 50 elements on the screen, it takes time to choose which action is required. If you have 20, the UI is faster to work with.
  • Keep it simple. Well, it is a general principle for all the facets of agile software development.
  • Short system messages (10 words max). People don’t have time to read long messages. Delays kill usability.

Some concrete numbers from the book:

  • Response time of typical action in the application should be about 2 seconds.
  • If response time takes more than 5 seconds, it is required to show a progress indicator. User should know that system is working on the task.
  • If system response time is more than 7 seconds, people tend to leave web site or switch to another task. It breaks interaction flow.

Noticeable Performance Improvement

If you are going to improve performance, it should be faster by more than 20%. Otherwise most people will not see the difference (it was shown in some researches that performance difference is noticeable in a range between 10% and 18%). For example, if you are improving search function with 10 seconds response time, it is required to make response time at least 8 seconds (or less).


Flow is very important for good user experience.

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.

Our goal is to make the Flow possible. I think it is the hardest thing in software development.

Real software not only helps people to solve real problems. It enables The Flow.

When user opens an application and sees complex UI, it is frustrating for him. Application should match user experience and skills. Simple or Advantage modes, clean and simple UI (Hick–Hyman Law!), balanced options and functionality — this sounds familiar, but hard to develop.

Friday’s Digest #13 [Kanban, ASP.NET MVC, Ajax]

  • 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.

Friday’s Digest #12 [Design, Business, Kanban]

  • 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?

This is not a joke: Gantt charts in TargetProcess

It’s good to get questions from people who work with TargetProcess. Indeed, questions and feature requests are like a plancton for this product ocean. We thrive on them, and we take the power to move forward from our clients’ feedbacks. Some of the questions are worth to be blogged on, to initiate a discussion and get the right direction.

So, one of these questions is about Gantt charts, whether we’re going to implement them in TargetProcess or not. Notably, for the most part this question is asked just this way — are you going to implement Gantt charts? People forget to explain what are they looking for in Gantt charts and why do they need them whereas in reality it makes a huge difference if they want Gantt charts for dependencies on tasks level or if they want Gantt charts for Program-level planning, to get a “bird’s eye view” on what’s going on with all the projects, as they put it.

For those who want Gantt charts on tasks level, to manage dependencies and to nurture a gigantic critical path for the sake of nurturing it – the answer is always “no”. There can be no Gantt charts for tasks and dependencies since agile is not about tasks dependency and critical path management — it’s about flexibility and “temporary dependency”, if you want to call it this way. The most you can get about dependency on User Stories and Tasks Level in TargetProcess is indication of related User Stories with a custom field. We’re going to implement this in the next release.

User Story Name Depends On
As a user I want to Logout As a user I want to login
As an admin I want to delete users As an admin I want to view users list
As a user I want to purchase things As an admin I want to add thing into the catalogue

I will not be going into much detail with the reasons for this “no”, re-writing multiple articles on this topic, Google is always right at your fingertips 🙂 But I’ll just give you a link to a very comprehensive post.

The only way for Gantt charts to stay alive in TargetProcess is in high-level planning of Program-Projects, that’s what you might call a “what’s- going-on-in-the-forest” view. We already have these Gantt charts in plans. That’s how they will look:

High level Gantt chart

Originally, TargetProcess has been more focused on managing just one project. But as we get feedback from people, we see the need to implement more elaborate features for managing multiple projects on Program-Project level — those Gantt charts provide a quick scan look to all the projects.

Follow our roadmap for the Gantt charts. Your feedback is really important to us, so we encourage you to register at our Help Desk Portal and support forum and vote for Program level Gantt charts here.

Friday’s Digest #11 [Kanban, GTD, Economy]