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!

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

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.

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.

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.

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:

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.

I wrote previously about agile certification. I don’t like the idea. However, some new arguments arose recently.

For example. Peter Stevens wrote: “In a time when every office worker gets told ‘A Microsoft Office certification is good for your career,’ it is clear that certification is part of the game”.

It is not the case for companies applied agile software development. For example, at TargetProcess we do not pay almost any attention to official certificates. They all sucks. I personally interviewed many people having several Microsoft Certificates, but many of them were bad developers. They were coders, and that is something we are fighting against. It appeared that certification has nothing in common with developers skills. We hired several people with no certificates at all, and we hired several with certificates. There is no any relations between good developer and certificates they have.

Agile implementation changes company culture. Without this shift agile adoption will fail in the long term.

I do believe that there are many Certified Scrum Masters that did not get the Scrum process right. People are different. Someone may attend the course and work hard to improve his knowledge. Someone may attend the course and take SCM title with honor, thinking that he knows everything to implement Scrum in his company.

On my opinion that is one of the reasons why Scrum adoption fails in companies.

How To Certify Meta Process?

Software development process is a complex thing, that should be adopted to each company, environment, etc. Some best practices may not work in some conditions. It means we can’t include practices into certification test at all. What we can include is things that shape the process, things that focus on development process improvements, like retrospective meetings, communication empowerment, self-organization, emergency. But can you imagine how the questions sound like?

• Have you something in place that enables process evaluation and improvements?
• Do you have practices that power communication?
• Do you have practices that enable self-organization?

Guess what answers can we get on such general questions: “Yes, our top managers meets every year and discuss development process improvements”, “Yes, we have Outlook, it is great for communication!”, “Yes, team located in one room, so it is easy to shout out and assign particular task”. The result is obvious though.

What Type of Agile Certification May Work?

Agile certification may be developed in the future, but for the very strict set of conditions. For example, there may be quite good set of questions for the team under the following conditions:

• Team size: 4-6
• Project type: Typical web site
• Project complexity: Average
• Distributed Team: No
• Region: Europe
• Technology: Ruby

If someone creates questions based on the criteria above, that may work. All other attempts to certify teams using General tests will miserably fail in the long term.

Ants Colony

How ants search for food? They do not have cell phones, cars and mini-markets near the nest. They should have something simpler to communicate.

Here is how ants work:

1. Travel randomly  in search for food.
2. Take a piece of food and head straight back to the nest. On the way back to the nest lay down an odor trail.
3. Notify nestmates of the discovered food encouraging them to leave the nest. These newly recruited ants will follow the odor trail directly to the food source. In their turn, each ant will reinforce the odor trail until the food is gone.

Sounds simple? Take a look at this very nice ants colony model. Drop some food and enjoy the action.

Birds Flocks

Birds flocks are beautiful. You may think that the movement gets orchestrated by one savvy bird. But this is not the case. A bird glock is guided by three simple principles (every decent bird knows them):

1. Separation: steer to avoid stumbling upon local flockmates.
2. Alignment: steer towards the average heading of local flockmates.
3. Cohesion: steer to move towards the average position of local flockmates.

Simple? Yes, it is. Look at the picture on the right. It’s just amazing!

Game of Life

Game of Life was invented in 1970 by John Conway. It is a cellular automaton and simulates the birth, death, etc., of organisms based on certain rules:

1. Each cell with one or no neighbors dies, as if of loneliness.
2. Each cell with four or more neighbors dies, as if of overpopulation.
3. Each cell with two or three neighbors survives.
4. Each empty cell with three neighbors becomes populated.

Simple rules. But these rules lead to fantastic diversity of the forms. Different types of the forms have been discovered e.g.  still objects, oscillators, gliders, spaceships, etc. It is impossible to predict the state of a system after several thousands steps. Cellular automaton has properties of a complex system such as emergency and butterfly effect. Small changes in the stable structure (for example, adding one more living cell) may cause death of the whole cells population.

Moreover, it is possible to build a computer based on Life! It is possible to implement logic based on stable structures and execute simple calculations. The Game of Life is a Turing machine! How can someone suggest that such a simple system based on four rules has so much power?

Take a break and have fun with Life game simulation.

Simple Rules and Software Development

Is there any relation between simple rules and software development? Sure, there is. Software development process should be simple. Process complexity leads to mechanistic and dumb behavior.

1. Information exchange and collaboration vs. standard status reporting meetings.
2. Learning vs. stagnation.
3. Emergent behavior and creativity vs. Following rules, standards, instructions.

Agile methodologies are simple. Scrum is a very simple thing. It has just several rules, roles and artifacts. Well, it is a lot harder to really implement Scrum. It is hard because you need to break stereotypes and habits. Many people are resistant and don’t want to try new things. However, Scrum works. It works because of its simplicity, it lives in accordance with complex systems.

Scrum stimulates learning, feedback, communication and cooperation. Emergency is possible in Scrum.

Here is one sample of unnecessary complexity — too many hierarchy levels:

A potential problem, unlikely in small and medium organisations, is deep organisational structures. According to Peters and Waterman (1982)18, both Toyota and Roman Catholic Church have only five layers of management in comparison to Ford’s seventeen.

Do you by any chance happen to have a software development process description in a huge 100+ pages document? Are you still in business?

• Part 1. Agile Software Development and Complex Adaptive Systems: Intro
• Part 2. Software Development is Complex Adaptive System. No Doubt
• Part 3. Edge of Chaos and Hyper Productive Software Development Teams
• Part 4. Simple Rules, Complex Systems and Software Development

Are you familiar with zero defects mentality? It looks very good from the first sight. Zero defects… Let me think… Well, cool! I like it! I’d like to have zero defects in my projects.

So, what is zero defects mentality? Here is the quote from Lean Software Development an Agile Toolkit book:

“One of the fastest ways to kill motivation is what is called in the US Army a zero defects mentality. A zero defects mentality is an atmosphere that tolerates absolutely no mistakes; perfection is required down to the smallest detail. The army considers a zero defects mentality to be a serious leadership problem, because it kills the initiative necessary for success on a battlefield” — Mary & Tom Poppendieck

Obviously, zero defects mentality is not something that HOUSE M.D. likes Moreover, I think Dr. House hates zero defects mentality. It causes several unpleasant effects:

• Not enough courage to refactor complex, messy, buggy, but important piece of code.
• Can’t make important decision, instead make less risky, but wrong decision.
• Do everything to avoid responsibility, that leads to coward and stupid behavior.

“Zero defects” may sound good. But in reality you still have errors after production. Even in predictable and (quite) easily testable industries (hardware, automobile, etc.) there are problems with 100,000 power adapters that should be replaced (or hard drive problems, or engine problems, I bet you can continue the list).

How can we expect zero defects in software development? It is harder to test, harder to define in details, harder to predict. Software development is a complex adaptive system, we can’t predict all effects. Bugs in production is a normal thing, and by “normal” I mean we can’t bring them to zero. We can (and should) minimize them using all possible ways, but The Last Bug is a mirage.

There are several obvious strategies that may help:

• Test Driven Development. Nice side effect of TDD is a unit tests suite. You have tests for new code, and you have unit tests for old code. More tests — less bugs.
• Continuous integration. Instant feedback helps to identify problems early and fix them early. It saves time (and money) and reduces bugs in production.
• Automated regression functional tests suite. Unit tests are good, but you need something else. Functional tests emulates user behavior and find user interface errors, integration errors, etc. Needles to say you should have continuous integration in place to succeed with automated functional tests.
• Root cause analysis. There are several ways to fix a bug. You may just hack the code and apply a patch (please, don’t do it at home!). You may think deeper and fix the bug nicely. Also you may look into the root of the problem and fix it. Yes, it may take time, but you will prevent future bugs from this domain.
• High development skills. Ironically, high skills do not always reduce bugs rate in production. “Stars” may be strong in some areas (business layer), but may not polish things. It may lead to many small bugs, especially on UI.

Is it a good thing to have “Zero Defects” goal in the sprint? The answer is “Are you kidding me? Zero bugs? It’s a miracle!”